[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-net
mailing list