where does the wireshark capture the packets in the linux kernel? If an output packet is captured by wireshark , will the packet be sent out definitely through corresponding interface?
In other words, could an output packet that captured by wireshark be dropped before it is sent out?
where does the wireshark capture the packets in the linux kernel?
On UN*Xes, it uses libpcap, which, on Linux, uses AF_PACKET sockets. (On Windows, it uses WinPcap, which is a driver plus a port of libpcap to use the driver.)
If an output packet is captured by wireshark , will the packet be sent out definitely through corresponding interface?
No. The networking stack hands the packet to the appropriate AF_PACKET sockets and to the driver; the driver might drop the packet (for example, if, on an Ethernet, it got multiple collisions and gave up) even though the packet was delivered to the AF_PACKET socket.
In other words, could an output packet that captured by wireshark be dropped before it is sent out?
Yes. See above.
Related
I'm setting up a traffic generator using pktgen-DPDK. What am having a hard time understanding is why DPDK plays a part when sending packets. From what I understand, when the receiver gets a packet and have their system configured to handle it using DPDK the NIC will send the packet to the app directly which then uses DPDK to do packet processing there (by passing inefficient Kernel network layers). So why do the transmitter also need to use DPDK for this? And how does it alter the packets that are being sent?
Here is an example to explain my thinking:
A transmitter is trying to send an image to receiver. The image is divided into small packets, which uses IP and TCP to get the packet from transmitter to receiver. After the packets have traveled over the internet, they finally get to the receiver. The receiver has configured their system to use DPDK, bypassing some Linux Kernel network layers. Through this the packet processing becomes faster.
Based on this example above, I don't see the point of using DPDK for sending packets or even how it would play a part in that. When we send packets, do we not simply use some protocols like TCP and IP to make sure the packet get where it needs to.
What is wrong with the example I'm giving and how could you rephrase it to be correctly?
I have an application that creates, listens on and writes to a tap interface. The software will read(tun_fd,...) and perform some action on that data, and it will return data to the system as UDP packets via write(tun_fd,...).
I assign an IP to the interface, 10.10.10.10\24 so that a socket application can bind to it and so that the kernel will pass any packets for the virtual subnet to the tap interface.
The software generate frames with IP/UDP packets with the destination IP being that assigned to the interface, and a source IP existing in the same subnet. The source and dest mac address match that of the tap device. Those frames are written back to the kernel with write(tun_fd,...).
If I open said tap interface in wireshark I will see my frames/packets as I expect to, properly formatted, expected ports, expected macs and IPs. But if I try to read those packets with netcat -lvu 0.0.0.0 ${MY_UDP_PORT} I don't see anything.
Is this expected behavior?
Update 1
INADDR_ANY is a red herring. I have the problem even when explicitly binding to an interface / port as in this pseudo code:
#> # make_tap_gen is a fake program that creates a tap interface and pushes UDP packets to 10.10.10.10#1234
#> ./make_tap_gen tun0
#> ip addr add dev tun0 10.10.10.10/24
#> netcat -lvu 10.10.10.10 1234
Update 2
I modified my code to be able to switch to a tun as opposed to a tap and I experience the same issue (well formatted packets in Wireshark but no data in socket applications).
Update 3
In the kernel documentation for tuntap it says
Let's say that you configured IPv6 on the tap0, then whenever
the kernel sends an IPv6 packet to tap0, it is passed to the application
(VTun for example). The application encrypts, compresses and sends it to
the other side over TCP or UDP. The application on the other side decompresses
and decrypts the data received and writes the packet to the TAP device,
the kernel handles the packet like it came from real physical device.
This implies to me that a write(tun_fd,...) where the packet was properly formatted and destined for an IP assigned to some interface on the system should be received by any application listening to 0.0.0.0:${MY_UDP_PORT}
Yes, data written into the tuntap device via write(tun_fd...) should get passed to the kernel protocol stack and distributed to listening sockets with matching packet information just like the frame had arrived over a wire attached to a physical ethernet device.
It requires that the packets be properly formed (IP checksum is good, UDP checksum is good or 0). It requires that the kernel know how to handle the packet (is there an interface on the system with a matching destination IP?). If it's a tap device it may also require that your application is properly ARP'ing (although this might not be necessary for a 'received' packet from the perspective of a socket application listening to an address assigned to the tap device).
In my case the problem was silly. While I had turned on UDP checksum verification in wireshark I forgot to turn on IP header verification. An extra byteswap was breaking that checksum. After fixing that I was immediately able to see packets written into the TAP device in a socket application listening on the address assigned to that interface.
I am an embedded software developer who has any experience with TCPIP on connected devices. Also, I am not a software protocol expert, so I am a bit confusing about TCPIP protocol stack + responsiblities of its various phy layers.
First of all, I have experiences with such protocols like UART, SPI, CAN, USB... As you know, the phy layer directly affects you while selecting the protocol you used at the software level. For example, if you use usb and you build a software protocol on it, you do not occasionally deal with some details like checking corrupted frame in your sofware protocol, because phy layer of it guarantees this operation. CAN also has some CAN Controller facilities like crc and bit stuffing so, it is really reliable. But the situation is not the same for simple peripherals like UART/USART. Let's say you are using a bluetooth module to upgrade your firmware, you need to be aware of almost everything that can occur while communicating like delays, corrupted frames, payload validating etc.
Briefly, i am trying to understand the exact role of newtork interfaces come included in MCUs, that are interfaced with RJ45 phy sockets directly. In another words, imagine that I wrote a server application on my pc. Also i configured and ran an application in my development board which has an RJ45 socket and it runs as a client. Also imagine they established a connection over TCP. So, what will be the situation at the client side, when i send a 32 bytes of data to the socket from the server side? What will I see at the lowest level of MCU that is an RxCompleteInterrupt()? Are the data I sent and some other stuffs appended to the TCP packet guaranteed to be delivered by the eth controller in the MCU and ethernet controller of my PC? OR am i responsible (or the stack i used) check all the things necessary to validate whether the frame is valid or not?
I tried to be as clear as it would be. Please if you have experience, then try to write clean comments. I am not a TCPIP expert, maybe I used some wrong terminology, please focus the main concept of the question.
Thanks folks.
If you don't have any prior experience with the TCP/IP protocol suite, I would strongly suggest you to have a look at this IBM Redbook, more specifically at chapters 2, 3 and 4.
This being said:
So, what will be the situation at the client side, when i send a 32
bytes of data to the socket from the server side? What will I see at
the lowest level of MCU that is an RxCompleteInterrupt()?
You should have received an Ethernet frame in your buffer. This Ethernet frame should contain an IP packet. This IP packet should contain a TCP packet, which payload should consist in your 32 bytes of data. But there will be several exchanges between the client and the server prior to your data to be received, because of TCP being a connection-oriented protocol, i.e. several Ethernet frames will be sent/received.
Are the data I sent and some other stuffs appended to the TCP packet
guaranteed to be delivered by the eth controller in the MCU and
ethernet controller of my PC? OR am i responsible (or the stack i
used) check all the things necessary to validate whether the frame
is valid or not?
The TCP packet will ultimately be delivered, but there there are not warranties that your Ethernet frames and IP packets will be delivered, and will arrive in the right order. This is precisely the job of TCP, as a connection-oriented protocol, than to do what is needed so that the data you are sending as a TCP payload will ultimately be delivered. Your MCU hardware should be the one responsible for validating the Ethernet frames, but the TCP/IP stack running on the MCU is responsible for validating IP and TCP packets and the proper delivery of the data being sent/received over TCP.
You can experiment with TCP on a Linux PC using netcat, and capture the exchange using Wireshark or tcpdump.
Create a 'response' file containing 32 bytes:
echo 0123456789ABCDEFGHIJKL > response.txt
Start Wireshark, and filter on lo interface using filter tcp port 1234
Start a TCP server listening on TCP port 1234, which will send the content of response.txt upon receiving a connection from the client:
netcat -l 1234 < response.txt
In another console/shell, connect to the server listening on tcp/1234, and display what was received:
netcat localhost 1234
0123456789ABCDEFGHIJKL
On Wireshark, you should see the following Wireshark Network Capture, and be able to expand all frames/packets of the full exchange using the IBM Redbook as a reference.
Your 32 bytes of data will be in the payload section of a TCP packet sent by the server.
Is it possible to push all packets received at NIC to the TCP/IP stack even if their ethernet address doesn't match my ethernet address? In other words I want to process all incoming packets at my NIC.
Can anyone mention a possible scenario for changing network interface driver code?how could I check the operation of driver code?
In the typical system, this already happens. That is, all you have to do is put the interface into promiscuous mode. The driver then sends all packets it receives to the TCP/IP stack. Check any ordinary network driver, you'll see that in processing received packets, there is no comparison of the MAC (or ethernet) address with the device's MAC address.
Simplifying considerably:
What normally happens is that when you don't have promiscuous mode enabled, the driver configures the device such that it filters on a specific MAC address, only delivering frames that have a matching address or a broadcast address (or occasionally a multicast address, which may or may not also be filtered). When you enable promiscuous mode, the driver simply tells the device not to filter on MAC address but to deliver all frames. The driver then will receive all frames and deliver them to the stack. In linux, this typically happens through a call to netif_receive_skb() or a variant thereof.
The TCP/IP stack itself doesn't care about the MAC address. It will instead look for packets that have an IP address matching one of its own. Any packets received that don't have an IP address belonging to this box are simply discarded -- unless there's a user-mode program trying to receive raw packets (such as tcpdump). [In the latter case, it's still discarded after being delivered to tcpdump.]
If it matches on the IP address, it's then passed up the stack to TCP or UDP [etc] -- where it could also be discarded if it doesn't correspond to a session / port that anything on the box cares about.
But typically packets destined for a MAC address not matching one assigned to this device will not be packets that this machine cares about. Hence, promiscuous mode is usually only enabled for debugging, troubleshooting, forensics (i.e. tcpdump, wireshark, etc). The rest of the time, it's a waste of processing resources since the packets will just be discarded.
Actually, I have two related questions.
I'm capturing filtered network traffic by libpcap on Debian. Then I need to replay this traffic on Win2k3 server. Sometimes I capture packets, both TCP and UDP, much larger than 1500 bytes (default MTU size for Ethernet). E.g., 2000+ bytes. I did no specific changes to MTU size on that Linux. So question #1:
What's the reason for these packets much larger than default MTU? Jumbo frames? This Wikipedia article states that "network interface cards capable of jumbo frames require explicit configuration to use jumbo frames", but I'm not aware about any such configuration. Also ifconfig shows me "MTU:1500". Can it be somehow related with "interrupt-combining" technique (or "interrupt coalescing" as in this article)? Can I supress such packets?
Then, question #2:
How can I send such packets by pcap_sendpacket on Windows? I receive error message "send error: PacketSendPacket failed" only for packets larger than 1500 bytes. Seems I cannot use jumbo frames because I'm sending data to directly connected custom "net tap" like pci card and I'm not sure I can configure its NIC. What else? Should I fragment these packets according to the protocol rules?
EDIT:
Checked fragmentation by NIC as Guy Harris suggested:
~# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off
The same for eth1 and br0 - network bridge between eth0 and eth1 which I'm sniffing.
And I still receive large UDP packets.
Your network adapter is probably doing TCP segmentation/desegmentation offloading and IP fragmentation/reassembly offloading, so:
UDP packets being sent by your machine that are larger than will fit in a single Ethernet frame are being handed to the network adapter without being fragmented, with the network adapter doing the fragmentation, and those are also handed to libpcap before being fragmented;
UDP fragments being received by your network adapter that are larger than will fit in a single Ethernet frame are being reassembled by the network adapter before being handed to the host, and are being handed to libpcap after being reassembled;
chunks of TCP stream data being sent by your machine that are too big to fit in a single Ethernet frame are being handed to the network adapter, with the network adapter breaking the chunks up into smaller TCP segments, and the full chunk is being handed to libpcap;
TCP segments received by your network adapter are being reassembled into larger chunks of TCP data and the chunks are being handed to the host and then to libpcap;
so what libpcap is seeing are not Ethernet packets and are not limited to the Ethernet frame size.
(I.e., Nikolai Fetissov was probably correct; what you're receiving might look like Ethernet frames, but that's because the network adapter and driver make them look that way. They are, in fact, not Ethernet frames transmitted on or received from the Ethernet.)
You can only suppress them by turning off whatever form of segmentation/desegmentation/fragmentation/reassembly is being done on your network adapter using the ethtool command; turn off options such as TCP Segementation Offload, UDP Fragmentation Offload, General Segmentation Offload, Large Receive Offload, and Generic Receive Offload.
Once you've disabled those options, you should no longer have those large packets, and thus you should be able to replay them with no problem. There is no easy way to replay the reassembled/un-fragmented-or-segmented packets you've captured so far - you'd have to write your own code to fragment them, and there's no guarantee that they'd be re-fragmented/re-segmented in the same way that they were originally fragmented/segmented on the wire.
¿Are you using the wireshark to capture?
It's important beacause by default wireshark reassemble fragmented ip datagrams (and stores them in a pcap file as reassembled MTU-higger single packages without fragmentation).
To disable:
Edit->preferences->Protocols->ipV4-> and uncheck "Reassemble fragmented IPv4 datagrams".