acknowledgement number in tcp header

[peter360]

Here are a sequence of tcp packets I captured using tcpdump:

10:47:27.784044 IP (tos 0x0, ttl 63, id 33239, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.100.154.51509 > 10.0.0.4.80: S, cksum 0x6f22 (correct), 4274988216:4274988216(0) win 5840 <mss 1460,sackOK,timestamp 4892015 0,nop,wscale 7>
10:47:27.784123 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 10.0.0.4.80 > 192.168.100.154.51509: S, cksum 0x8d61 (correct), [red]4063425615:4063425615(0)[/red] ack 4274988217 win 5792 <mss 1460,sackOK,timestamp 2846577073 4892015,nop,wscale 7>
10:47:27.785567 IP (tos 0x0, ttl 63, id 33240, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.100.154.51509 > 10.0.0.4.80: ., cksum 0xd29e (correct), [red]ack 1[/red] win 46 <nop,nop,timestamp 4892016 2846577073>

I thought the third line should say "ack 4063425616", but it says "ack 1". Looks like the client is ignoring the sequence number in the syn-ack packet returned from the server. Can someone explain to me why this happens? Is it a common practice in tcp implementations? It seems like both windows and linux clients exhibit this behavior.

 

[peter360]

I figured this out myself. The ack number reported by tcpdump is not the same as the one in the tcp packet. To see the real ack number you need to use tcpdump -S. By default tcpdump shows "relative" sequence/ack numbers because they are easier to read presumably.