views:

314

answers:

1

I've checked the tcpdump man page and thought I understood the example provided there. But the one that I am getting is something I'm not able to understand completely.

ORIGINAL: Simulator Output

LINE 1: 20:01:13.442111 IP 10.0.0.1.12345 > 10.0.0.2.54321: S 1234:1234(0) win 65535
LINE 2: 20:01:13.471705 IP 10.0.0.2.54321 > 10.0.0.1.12345: S 4321:4321(0) ack 1235 win 65535
LINE 3: 20:01:13.497389 IP 10.0.0.1.14640 > 10.0.0.2.12756: . ack 4322 win 65535
LINE 4: 20:01:13.497422 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 1235:2682(1447) win 65535
LINE 5: 20:01:14.023273 IP 10.0.0.2.12756 > 10.0.0.1.14640: . ack 5768 win 65535

This is what I understand:

LINE 1: 1 sends 2 0 bytes starting with SEQ number 1234
LINE 2: 2 sends 1 0 bytes starting with SEQ number 4321 and an ACK = (1's SEQ + 1) i.e. 1235
LINE 3: 1 sends 2 0 bytes with an ACK = (2's SEQ + 1) i.e. 4322
LINE 4: 1 sends 2 1447 bytes starting with SEQ number 1235 until 2682 (1447 bytes in total)
LINE 5: 2 sends 1 0 bytes with an ACK = 5768? What is this number? Isn't it supposed to be 2683?

Maybe I am missing something too obvious. Can someone point it out please?

EDIT 1: Simulator output (grepped one connection info)

20:01:13.442111 IP 10.0.0.1.12345 > 10.0.0.2.54321: S 1234:1234(0) win 65535
20:01:13.471705 IP 10.0.0.2.54321 > 10.0.0.1.12345: S 4321:4321(0) ack 1235 win 65535
20:01:13.497422 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 1235:2682(1447) win 65535
20:01:14.573322 IP 10.0.0.2.54321 > 10.0.0.1.12345: . ack 5981 win 65535
20:01:14.593870 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 4129:5576(1447) win 65535
20:01:14.639457 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 7023:8470(1447) win 65535
20:01:14.639606 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 9917:10640(723) win 65535
20:01:14.660971 IP 10.0.0.2.54321 > 10.0.0.1.12345: . ack 11769 win 65535
20:01:14.693847 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 12087:13534(1447) win 65535
20:01:14.726564 IP 10.0.0.2.54321 > 10.0.0.1.12345: . ack 15964 win 65535

Question: The ACK still seems to be different. It is 5981 instead of 2683.

EDIT 2: Real TCP output

22:20:14.492625 IP 72.14.204.99.80 > 10.0.2.15.59745: S 255616001:255616001(0) ack 1727704513 win 65535 <mss 1460>
22:20:14.495606 IP 10.0.2.15.59745 > 72.14.204.99.80: . ack 255616002 win 5840
22:20:14.501015 IP 10.0.2.15.59745 > 72.14.204.99.80: P 1727704513:1727705327(814) ack 255616002 win 5840
22:20:14.501746 IP 72.14.204.99.80 > 10.0.2.15.59745: . ack 1727705327 win 65535
22:20:14.562197 IP 72.14.204.99.80 > 10.0.2.15.59745: P 255616002:255616102(100) ack 1727705327 win 65535
22:20:14.562298 IP 10.0.2.15.59745 > 72.14.204.99.80: . ack 255616102 win 5840
22:20:14.630749 IP 10.0.2.15.59745 > 72.14.204.99.80: P 1727705327:1727706096(769) ack 255616102 win 5840
22:20:14.631228 IP 72.14.204.99.80 > 10.0.2.15.59745: . ack 1727706096 win 65535
22:20:14.692324 IP 72.14.204.99.80 > 10.0.2.15.59745: P 255616102:255616338(236) ack 1727706096 win 65535
22:20:14.692361 IP 10.0.2.15.59745 > 72.14.204.99.80: . ack 255616338 win 6432

Question: I tried as per your suggestion and grep'ed one connection's output. But this time, why is the ACK the way it is instead of SEQ+1?

+1  A: 

check from the port number, It seems that LINE1, LINE2 and LINE5 belong to one session while LINE2 and LINE4 is in another session.

Instead using tcpdump for packet analysis, I highly suggest you to capture packets with tcpdump, and analyze the result with wireshark tool.

EDIT: For the simulator stream, it mess up. Since the 10.0.0.1 -> 10.0.0.2's packets's sequence numbers is not completely, so I think maybe there some packet did not be captured and the timing is not show the real status. so you can ignore it.

For the real stream, it is okay. For syn packet, ack reply = seq +1; for content sending, ack = seq + len. The stream actually show this to us.

arsane
Any explanation as to why you think they might be different connections? I'm using a simulator to produce this output and am using only on TCP output. Also, we can observe the TCP handshake process in LINES 1-3. What do you think?
Legend
@Legend, a connection is limited to port pairs; your tcdpump out may have relation to your simulator's implementation of network. Better to tcpdump a real tcp for learning to get the rid of the simulator's behavior.
arsane
Thanks for the explanation. Just added two parts: EDIT 1 and EDIT 2. In the first one, I grepped a few lines for a single connection. In Edit 2, I have copied the real tcp output that I got... Any explanation for the real tcp behavior?
Legend
I did not know that ack = seq+len for content sending. Thank you for the clarification...
Legend