Robert Watson wrote: > On Wed, 25 Jul 2007, Mike Silbersack wrote: > >> On Fri, 20 Jul 2007, Peter Wemm wrote: >> >>> TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10<ACK>; >>> syncache_expand: Segment failed SYNCOOKIE authentication, segment >>> rejected (probably spoofed) >>> [...] >>> >>> How on earth can localhost be spoofing itself? This is getting quite >>> absurd. :-( >> >> Any extra ACK that arrives is probably being processed by the >> syncookie code is my guess. So, I think that the problem is probably >> anywhere except in the syncookie code. I guess it is a late ACK for a connection that is being shut down. Once the tcpcb of the connection is gone any further segments will hit the syncache and cause such an error message. The real problem seems to be in the connection shutdown sequence that either somehow prematurely completes or emits spurious packets after completion. >>> I'll give your patch a shot and see if it improves things at all. >> >> It won't, not for this case. :( >> >> But I'll get it committed ASAP, because it fixes other cases. Unless, >> that is, things IRL keep interrupting me. > > FYI, I received an informal report a few days ago that the SYN cache was > ignoring RSTs, and kept transmitting SYN/ACK's even though a RST had > been sent. This was during some local network testing where a host > sends SYN packets out to a large number of other hosts, then quickly > resets the connections after getting SYN/ACK's. Given that your > previous work suggests that the syncache timer never fires at all, I'm > not quite sure what to make of this report, but once your patches are in > I can ask them to rerun it on one of my hosts and see. Not all RST lead to the termination of the syncache entry. It'd be helpful to know which log messages the local network test generated. There are two possibilities: "Our SYN|ACK was rejected, connection attempt aborted by remote endpoint", or "Spurious RST, segment rejected". Only the former causes the termination of the syncache entry. I fear the distinction between these two cases is over- engineered and they should be collapsed together. -- AndreReceived on Wed Jul 25 2007 - 09:24:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:15 UTC