5

I was looking at some random traffic in wireshark and came across this (using relative seq/ack numbers):

    1. myIP          -> 74.125.227.96  [SYN]        seq=0
    2. 74.125.227.96 -> myIP           [SYN/ACK]    seq=0     ack=1
    3. myIP          -> 74.125.227.96  [ACK]        seq=1     ack=1
    4. myIP          -> 74.125.227.96  [ACK]        seq=1     ack=1     len=14600
    5. 74.125.227.96 -> myIP           [ACK]        seq=1     ack=2921
    6. 74.125.227.96 -> myIP           [ACK]        seq=1     ack=5841
    7. myIP          -> 74.125.227.96  [ACK]        seq=14601 ack=1     len=8760
    8. 74.125.227.96 -> myIP           [ACK]        seq=1     ack=8761 
    9. myIP          -> 74.125.227.96  [ACK]        seq=23361 ack=1     len=4380
    etc...

I was using http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers as a resource and it seems like seq=previous ack and ack+=previous seq+len/flags (please correct me if I'm wrong). But what is going on from lines 4-7? Is the packet being fragmented or something? The seq/ack numbers are not seeming to add up for me so where am I going wrong?

Improve this question
0

2 Answers 2

Reset to default
4

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 libpcapNote 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

Improve this answer
0

Maybe fragmentation. Maybe another session to the server. Ports eq? Wireshark can select all packets in a tcp session from interface (by select in menu on rcm on packet)

Improve this answer
2
  • But what is the proper relationship between syn/ack values because my computation does not come out correctly?
    – Bhubhu Hbuhdbus
    Apr 17, 2012 at 9:31
  • Handshake on step 1,2,3 You send data, on step 4,7,9; seq=seq(-1)+len(-1): Remote host didnt send any, but recieve 3 packet with 2921 bytes, 5841 and 8761. 5,6,8 packet without payloads. This is ticket, what "I successfully recieve 2921 bytes" etc.
    – Konstantin
    Apr 17, 2012 at 10:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .