![]() I saw someone post on reddit the other day asking about sequence number interpretation in tcpdump output. If you’re a network troubleshooter using packet analysis, you’ve GOT to be comfortable doing sequence number analysis. This behavior makes TCP sequence number analysis a pain in the ass. Here’s what the data looks like captured on the sender and then arriving at the receiver after it has been segmented: This is one of several reasons it’s a good idea to capture traffic outside of the hosts involved in the connection whenever possible. So you don’t see the actual packets that are put on the wire unless you capture outside the sending host with a tap or span port. Here’s the kicker: Wireshark uses libpcap or winpcap to grab the data before it gets handed to the NIC. This offloads the task to the NIC and saves overhead on the host’s resources. TCP might hand the NIC 16k of data and the NIC will break it into MSS sized bites: 11 segments of 1460 bytes and one segment of the remaining 324 bytes. What this means is that the TCP stack sends a chunk of data for the NIC to break up into Maximum Segment Size (MSS) pieces to send on the network. Many operating systems and NIC drivers support TCP Segmentation Offload (TSO) aka Large Segment Offload (LSO) aka Generic Segment Offload (GSO). ![]() You look at the capture and see something like this:Ĭlearly these large packets exceeding the MTU must be part of the problem, right? Probably not. Let’s say you’re uploading some data to a server while capturing packets on your machine. There’s something you need to know about taking captures on the host that is sending data. ![]() When you look at the packets you see a bunch of them that are far larger than the 1500 byte MTU. ![]() So you’ve got a problem and you decide to fire up Wireshark and take a capture.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |