Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jul 2007 13:25:03 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        current@freebsd.org, Peter Wemm <peter@wemm.org>, Mike Silbersack <silby@silby.com>, freebsd-current@freebsd.org, net@freebsd.org
Subject:   Re: FreeBSD 7 TCP syncache fix: request for testers
Message-ID:  <46A7330F.6000204@freebsd.org>
In-Reply-To: <20070725093019.E83919@fledge.watson.org>
References:  <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> <20070725003706.U79872@odysseus.silby.com> <20070725093019.E83919@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
Andre




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46A7330F.6000204>