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".
Related
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.
Two servers communicate via UDP. When a large packet is send, it is not received at the other end.
I added the following registry entries
But this has not solved the problem. Below is the wireshark info regarding the lost packet. The size of the lost packet is 2706
How can I make sure that the packets are fragmented. Should I enable or disable Fragmetnation. I was not able to find a registry entry for MTU for UDP.
I'm working on a server/client socket application that is using Linux TUN interface.
Server gets packets directly from TUN interface and pass them to clients and clients put received packets directly in the TUN interface.
<Server_TUN---><---Server---><---Clients---><---Client_TUN--->
Sometimes the packets from Server_TUN need to be fragmented in IP layer before transmitting to a client.
So at the server I read a packet from TUN, start fragmenting it in the IP layer and send them via socket to clients.
When the fragmentation logic was implemented, the solution did not work well.
After starting Wireshark on Client_TUN I noticed for all incoming fragmented packets I get TCP Checksum error.
At the given screenshot, frame number 154 is claimed to be reassembled in in 155.
But TCP checksum is claimed to be incorrect!
At server side, I keep tcp data intact and for the given example, while you see the reverse in Wireshark, I've split a packet with 1452 bytes (including IP header) and 30 bytes (Including IP header)
I've also checked the TCP checksum value at the server and its exactly is 0x935e and while I did not think that Checksum offloading matters for incoming packets, I checked offloading at the client and it was off.
$ sudo ethtool -k tun0 | grep ": on"
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
generic-segmentation-offload: on
generic-receive-offload: on
tx-vlan-offload: on
tx-vlan-stag-hw-insert: on
Despite that, because of the solution is not working now, I don't think its caused by offload effect.
Do you have any idea why TCP checksum could be incorrect for fragmented packets?
Hopefully I found the issue. It was my mistake. Some tcp data was missing when I was coping buffers. I was tracing on the indexes and lengths but because of the changes in data, checksum value was calculating differently in the client side.
I wanted to simulate a situation where when I send some packets say ping x.x.x.x, some of my packets outgoing from my Linux box should be dropped out and number of dropped packets should be then captured through Tx dropped packets in ifconfig tool.
I know some of option/rule that we can provide in iptables but not sure about them.
Can anybody let how to simulate packet drop and dropped packet capture in Linux?
netem provides functionality to simulate various network related situation like emulate wide area network, packet loss/drop/delay.
Please refer this excerpt for more information on packet drop as your have provided less requirements.
Also see SO answer
I am testing a network device driver's ability to cope with corrupted packets. The specific case I want to test is a when a large TCP packet is fragmented along the path because of smaller MTU in the way.
What most interests me about the IP Fragmentation of the large TCP packet is, is the protocol attribute of the IP Fragment packet set to TCP for each packet, or just the first fragment?
The protocol field will be set to TCP (6) for each fragment.
From RFC 791 - Internet Protocol
To fragment a long internet datagram,
an internet protocol module (for
example, in a gateway), creates two
new internet datagrams and copies the
contents of the internet header fields
from the long datagram into both new
internet headers. ... This procedure
can be generalized for an n-way split,
rather than the two-way split
described.
Protocol is part of the header and will consequently be copied into each of the fragments.
IP Fragmentation is a layer-3 activity, while the packet will be marked TCP, the intermediate fragments will not be usable by TCP. The TCP layer will have to wait for a re-assembly of the actual IP packet (unfragmented) before it can process it.
Wikipedia IP Fragmentation reference.
Path MTU-Discovery will usually update the source MTU and TCP packets (actually segments) will be sent with sizes limited to not cause fragmentation on the way