[Bug 250363] [tcp] data in syn_ack should be ignored

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Feb 17 14:49:01 UTC 2021


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250363

--- Comment #4 from Michael Tuexen <tuexen at freebsd.org> ---
Here is a script which shows what should happen according to RFC 793 and what
happens on FreeBSD main. I just tested the script:

 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0.000 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
+0.000 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
+0.000 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+0.000 > S    0:0(0)             win 65535 <mss 1460,nop,wscale 6,sackOK,TS val
100 ecr 0>
+0.050 < S.   0:512(512) ack   1 win 65535 <mss 1460,sackOK,eol,eol>
#ifdef RFC793
+0.000 >  .   1:1(0)     ack   1 win 65535
+0.000 >  .   1:1(0)     ack 513 win 65188
#endif
#ifdef FreeBSD
+0.000 >  .   1:1(0)     ack 513 win 65188
#endif
+0.000 recv(3, ..., 1024, 0) = 512
+0.000 close(3) = 0
+0.000 > F.   1:1(0)     ack 513 win 65535
+0.000 < F. 513:513(0)   ack   2 win 65535
+0.000 >  .   2:2(0)     ack 514 win 65535

I actually prefer the FreeBSD way of handling this and would consider it a
weakness of the specification to require the sending of two acks back-to-back
where the second ack updates the first. The peer has to handle it, since the
first ack can always get lost...

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the freebsd-transport mailing list