On 12.07.2013 12:56, Fabian Keil wrote:
Andre Oppermann <an...@freebsd.org> wrote:
On 10.07.2013 15:18, Fabian Keil wrote:
Andre Oppermann <an...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
