Date: Fri, 12 Jul 2013 14:18:08 +0200 From: Andre Oppermann <andre@freebsd.org> To: Fabian Keil <freebsd-listen@fabiankeil.de> Cc: freebsd-current@freebsd.org Subject: Re: Improved SYN Cookies: Looking for testers Message-ID: <51DFF400.6070504@freebsd.org> In-Reply-To: <20130712125640.6d194bd2@fabiankeil.de> References: <51DA68B8.6070201@freebsd.org> <20130710151821.5a8cf38a@fabiankeil.de> <51DE6E86.6080707@freebsd.org> <20130712125640.6d194bd2@fabiankeil.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12.07.2013 12:56, Fabian Keil wrote: > Andre Oppermann <andre@freebsd.org> wrote: > >> On 10.07.2013 15:18, Fabian Keil wrote: >>> Andre Oppermann <andre@freebsd.org> wrote: >>> >>>> We have a SYN cookie implementation for quite some time now but it >>>> has some limitations with current realities for window scaling and >>>> SACK encoding the in the few available bits. > [...] >>>> http://people.freebsd.org/~andre/syncookie-20130708.diff >>> >>> I've been using the patch for a couple of days and didn't notice any >>> issues so far. Privoxy's regression tests continue to work as expected >>> as well. >> >> Thanks for testing and reporting back. >> >> Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1 >> as well to bypass the syn cache entirely? > > I haven't noticed any issues with net.inet.tcp.syncookies_only=1. Excellent. >> It will give a bit of debug log output which is it telling you mostly about >> rounding to the next nearest index value. You can send the output privately >> to me to spot unexpected outliers, if any. > > One unexpected outlier seems to be: Both errors are normal and a sign of lazy application behavior, not a TCP error. > Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 27 bytes of data after socket was closed, sending RST and removing tcpcb This error is not uncommon and happens when the server side has closed the socket (and sent FIN) while the client side is still trying to send data. As the server has closed the socket we can't the deliver the data anymore and respond with a reset to let the client know. It typically happens with web servers and short keep-alive timeouts. > Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) This is the same situation after the previous line but after the inpcb was cleared. Now a second, final (because of the FIN), in-flight packet from the client arrives at the listen socket because the original inpcb is gone now. Since there isn't a matching SYN cache entry it falls back to check for a syn cookie which obviously fails. Having a FIN segment reach syncache is unusual but not wrong. In theory one could send a SYN, receive the SYN-ACK and respond with ACK-FIN in one packet if it carried all data to be sent and the application did a socket write shutdown already. > Client and server are running on the same system. > > As I don't usually use net.inet.tcp.log_debug and haven't been able to intentionally > reproduce the issue (but have seen it a few times), I'm not sure yet if the behaviour > is actually related to the SYN cookie changes at all. It's "normal" behavior and not related to the SYN cookie changes. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51DFF400.6070504>