I am currently working on making test scripts for regression testing of FreeBSD's TCP/IP stack using Google's packetdrill. However, there is a slight problem which I am having involving sequence numbers. This is a small segment from one of the test scripts which verifies whether Early Retransmit works properly -
// Three way handshake
0.100 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7>
0.100 > S. 0:0(0) ack 1 <...>
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
// Our application writes 2920 bytes
0.200 write(4, ..., 2920) = 2920
0.200 > P. 1:2921(2920) ack 1
0.300 < . 1:1(0) ack 1 win 257 <sack 1461:2921,nop,nop>
0.325 > . 1:1461(1460) ack 1 // delayed Early Retransmit at RTT/4 = 25ms
0.425 < . 1:1(0) ack 2921 win 257
0.500 close(4) = 0
0.500 > F. 2921:2921(0) ack 1
0.600 < F. 1:1(0) ack 2922 win 257
0.601 > . 2922:2922(0) ack 2
Although the test is easy to understand, but what I am not able to figure out is that why along with PUSH are we again sending an acknowledgement number 1, because while in the three-way handshake, the other side already did send an ACK starting with sequence number 1. Shouldn't this be the correct line -
0.200 > P. 1:2921(2920) ack 2
0.300 < . 2:2(0) ack 1 win 257 <sack 1461:2921,nop,nop>
It can also be seen that at 0.425 seconds the other side again sends an ACK with the same sequence number of 1:1.
The full test script can be found here.
I could have posted the question in the packetdrill's mailing list, but I think this is a problem with my fundamentals.
For a quick reference ~
- The starting decimals denote absolute timings in seconds.
<
and>
denote direction of packets,<
for receiving and>
for injecting.- S denotes SYN
- P denotes PUSH
- F denotes FIN
- . denotes ACK
- sack denotes Selective Acknowledgement.
accept()
,close()
andwrite()
are the appropriate system calls.