When a L2 packet has the same source and destination MAC address does it go out of the stack of the host to the switch and come back to the same interface ? Or is the L2 packet with the same source and destination MAC moved from the TX ring of the host to the RX ring and the above layer picks it up ?
If it goes to the switch, if at all it is legitimate, shouldn't the switch drop the packet as it could mean an attack ?
Typically, it depends on the switch. In general a switch in the network will not forward a packet out of port on which it was received, whether it was destined for the same MAC address or not.
Related
I made an ethernet PCB passthrough circuit board that has an input connector, the correct magnetics to isolate the signal on both ends, and an output connector. I'd like to test my board by sending data into it and measure the packets on the output to make sure nothing is being lost.
I have Wireshark on my computer but I'm not sure how to inject a certain number of packets into the input or how measure it on the output to look for lost packets. I can connect on both ends to laptops but there is no IP address on my board, it's just hardware.
I have my NIC in promiscuous mode, set within my driver. I'm running a hardwired connection between three machines on the same subnet (sending unicast UDP messages).
endM2Init (&pDrvCtrl->geiEndObj, M2_ifType_ethernet_csmacd,
pDrvCtrl->geiAddr, ETHER_ADDR_LEN, pDrvCtrl->geiMaxMtu, 100000000,
IFF_NOTRAILERS | IFF_SIMPLEX | IFF_MULTICAST | IFF_BROADCAST | IFF_PROMISC);
When I verify the destination address within the packet header, the only packets that are actually being sniffed out are typically broadcast messages (the source address is correct, but I can't sniff out unicast packets).
If I direct a packet to the machine doing the sniffing, I can still see the unicast packet without any issues.
At first I assumed this was because my local switch was managing the packets. I used the web-interface for my specific switch and enabled port mirroring (Ex: Source port 1, Destination port 7). This, however, yielded the same results. From my understanding, port mirroring on the switch sends everything destined to port 1 also to port 7.
I then tried a direct connection from machine A to machine B, while still sending the unicast packets to, the now disconnected, machine C to see if machine B would see any changes in packet sniffing. This once again, yielded the same results.
If machine A and machine B are directly connected, does it make sense to expect machine B to sniff out packets that are destined to an address not even in the loop? I appreciate any and all comments/answers regarding this topic.
I made a tcpdump and captured packets, the configured MTU is 2140. I am analysing pcap files using Wireshark.
According to the configured MTU the expected maximum size of the packets should be 2154 (2140 bytes +14 ethernet header bytes). But I see packets of size greater than 2154 (ex 9010 bytes), On analyzing I found that these packets are generated on the machine where I made tcpdump (let's say A) and have the destination to another machine (let's say B). I expect a packet to be fragmented before it is sent to another host. I found some explanations online that says tcpdump captures packets before NIC breakdown, though this seems to be a valid explanation but it seems to contradict in my case because on machine A, I received packets of size greater than 2154 from B. Any thoughts, on why machine A is sending and receiving packets greater than configured MTU.
What you are seeing is most likely the result of TCP Segment Reassembly Offloading. This is a feature available on some network cards with matching drivers.
The idea is that the reassembly of many of the TCP segments is handled in the NIC itself. This turns out to be pretty effective in reducing overhead on the CPU/OS side since the network driver need only handle, perhaps, 1 "packet" out of 10, seeing just one large packet, rather than receiving and reassembling all 10.
You can read more about it here.
Updated answer
If your packet is UDP
This behaviour is normal. but there is not much you can do to see the individual packets on the end machines. The UDP packet is broken down into MTU compliant packets and reassembled at the Link layer, usually by specific hardware. This is too low to to be captured by Wireshark/pcap.
If you want to capture the individual broken down packets, you have to do this on an intermediate machine/network card, for example a gateway between the two hosts, because the original UDP packet is not reassembled until it reaches its final destination. Note : this gateway can be virtual.
See notes.shichao.io/tcpv1/ch10
Leaving this here in case someone with the same problem comes...
If your packet is TCP :
It sounds like Wireshark is reassembling packets for you. This is often the default for TCP streams. You can change this by richt-click on a stream -> Protocol Preferences -> Allow subdissectors to reassemble TCP.
i'm trying to do the following:
a) Set Contiki in Promiscuous Mode.
b) Then retrieve all UDP and RPL packets send, not only to current node but also between two other nodes within communication range.
I have the following code:
NETSTACK_RADIO.set_value(RADIO_PARAM_RX_MODE, 0);
simple_udp_register(&unicast_connection, 3001,
NULL, 3000, receiver);
where receiver is an appropriate callback function. I am able to collect UDP packets send to the current node, but still unable to receive packets send between other nodes in my communication range.
Setting the RADIO_PARAM_RX_MODE only controls which packets the radio driver filters out. There are multiple layers in an OS network stack, of which the radio driver is only the first one. The next ones are RDC and MAC, which still filter out packets addressed to other nodes, and there is no API to disable that.
The solution is to either modify the MAC to disable dropping of packets not addressed to the local mode or write your own simple MAC. The latter is what the Sensniff (Contiki packet sniffer) does - see its README and source code. By the way, if you just want to log all received packets, just use Sensniff!
I have multiple readers on a single system which bind to a single address (IP:port ex. 239.0.0.1:1234). Another computer on group sends a UDP multicast packet to this group and readers should receive it. I used GLib 2.0 networking stack, g_socket_bind with allow_reuse set to true.
When there is a single reader (single socket binded to that address) or up to three readers everything is ok and readers will receive packets correctly. But when the number of readers increases to four or above, the packet loss occurs and linearly increases with number of readers on system.
If socket is a UDP socket, then allow_reuse determines whether or not other UDP sockets can be bound to the same address at the same time. In particular, you can have several UDP sockets bound to the same address, and they will all receive all of the multicast and broadcast packets sent to that address.
As stated in GIO Reference Manual, when allow_reuse set true, all readers should read all of data but it doesn't happen as the stated above.
Anybody knows what the problem is? Is there a kernel related problem?
All your sockets need to join the multicast group. If you're just relying on the bind to effect that, you are into undefined behaviour.