2.2.19 pre13 doesn't like retransmitted SYN ACK packets

[Zack Weinberg]

2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which
arrives after we've sent out the final ACK of the handshake.  For
example:

tcpdump: listening on eth0
15:15:15.075670 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www:
        S 1057306555:1057306555(0) win 32120
        <mss 1460,sackOK,timestamp 49252305 0,nop,wscale 0> (DF) [tos 0x10] 
15:15:15.156320 plan9.bell-labs.com.www > wolery.Stanford.EDU.1341:
        S 1042976132:1042976132(0) ack 1057306556 win 1460 <mss 1460>
15:15:15.156364 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www:
        . ack 1 win 32120 (DF) [tos 0x10] 
15:15:15.204186 plan9.bell-labs.com.www > wolery.Stanford.EDU.1341:
        S 1042976132:1042976132(0) ack 1057306556 win 1460 <mss 1460>
15:15:15.204232 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www:
        R 1057306556:1057306556(0) win 0

I do not know if this behavior is correct or not from the TCP spec.
It seems unlikely to me, given that duplicate packets are expected 
and ignored just about everywhere else.  As a practical matter, this
behavior makes it close to impossible to communicate with a host that
commonly sends duplicate SYN ACKs.  plan9.bell-labs.com is just such;
I estimate I get past the initial handshake one connection in twenty.

This kernel does not have SYN cookies compiled in.  rp_filter is 1,
all other TCP and IP tunables are at their defaults.

zw