Hello, We tested a tcp accelation product and found that product could receive the large bulk packets from the server(ftp). (Client -- (WAN) -- Accelation -- FTP Server) When the product work as 'bypass mode', I could see around the '58xx' length packet received from the server. https://www.cloudshark.org/captures/4b2217e6d72e When the product work as 'Accelation mode', I could see around the '14xxx~6xxxx' length packets received from the server. https://www.cloudshark.org/captures/e45cc5ccba29 I 'd like to know how could receive that large bulk packets from the server. Thank you asked 19 May '17, 01:53  jaesung kim |
One Answer:
The large packets are probably the result of large receive offload, where the packets on the wire aren't large, but, when receiving packets, the NIC reassembles multiple TCP segments and hands a fake Ethernet/IP/TCP packet, containing data from multiple over-the-wire TCP segments, to the host. There might also be large send offload, where the host hands a single large chunk of data for a TCP connection to the NIC, in the form of a very large Ethernet/TCP/IP packet - and also hands that large packet to the packet capture mechanism, so that it shows up in tcpdump/Wireshark/etc. - and the NIC sends it out as multiple segments on the TCP connection. answered 21 May '17, 20:45  Guy Harris ♦♦ Hi Guy Harris, Thanks for your reply. The trace captured in Server(Window OS). Does wireshark capture the packet on the NIC level? And is it possible to use ECN/CWR option for the large offload packets? Thank you. Jaesung Kim (21 May '17, 21:21) jaesung kim
Wireshark uses libpcap on UN*X, and WinPcap on Windows, to capture traffic. Libpcap runs atop some OS-dependent mechanism in the OS; WinPcap runs atop NDIS on Windows. None of those mechanisms are guaranteed to capture packets at the level the NIC sees them; at least on Windows, NDIS will provide you with the packets that the NIC provides to you, which may have even reassembled in the fashion I mentioned.
The large offload packets are not sent on the network - they're either split into multiple TCP segments when they're sent or reassembled from multiple TCP segments when they're received; the notion of large offload packets is not part of the TCP protocol, so there's no reason, at the protocol layer, why packets split and sent over the network, or reassembled from packets received over the network, couldn't use that option. What the software on the machine, or the firmware in the NIC, that does the splitting-and-transmitting or receiving-and-reassembling, will see those flags in the TCP segments sent over the wire, or will look at those flags in the TCP segments received over the wire and set them in the fake packet it provides after reassembly, is another matter. Those flags probably have nothing to do with the segmentation offloading that causes the large packets. (21 May '17, 22:09) Guy Harris ♦♦ ECN/CWR have nothing to do with offloading and they are not used in your session, as your server does not advertise them, too. (21 May '17, 22:29) Christian_R |
I edited the trace link option to share mode.
From my analysis, When the product work as accelation mode, the client send the syn packet with 'ECN','CWR' flags. But i could not found any related reply from the 'Syn-Ack' packets.
Thank you. Jaesung Kim