Messages in this thread | | | From | "Zack Weinberg" <> | Date | Thu, 15 Mar 2001 09:31:16 -0800 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |