syn/ack sequence number confusion

Solution 1:

TCP Sequence Numbering

There are a couple of things to remember when decoding TCP traces...

1. TCP sequence numbers are directional (i.e. if someone sends me a payload, I don't increase my sequence number based on bytes that I received)
2. TCP sequence numbers point to the head of the payload of a packet

However, those points alone don't account for the missing ACKs for seq numbers 5841-14600 between packets 6 and 7. My best guess (and that's all I can really do at this point) is that you might have dropped ACK packets somewhere in between the NIC and wireshark. You can tell when this happens if you see messages like this (from a linux xterm or ssh session)...

19431 packets captured
38863 packets received by filter
572 packets dropped by kernel  <----------------
7 packets dropped by interface <----------------

Solutions to wireshark packet drops

• Reduce the size of packets that wireshark looks at (100 bytes per packet is normally more than enough)
• Disable DNS lookups and live capture scrolling (disk buffer capture is most efficient)

• In linux you can fix these drops by adjusting buffers on the NIC and between the kernel and libpcap^{Note 1}...

  ethtool -G eth0 rx 768

  sysctl -w net.core.netdev_max_backlog=30000

• If you're in windows it helps to give wireshark more buffer space (the -B CLI option) when you call it...

Note 1. YMMV, buffer settings are specific to your system... play with them until you don't see packets dropped messages