Re: Segment failed SYNCOOKIE?

Abdullah Ibn Hamad Al-Marri wrote:
> On 5/28/07, Andre Oppermann <andre_at_freebsd.org> wrote:
>> Abdullah Ibn Hamad Al-Marri wrote:
>> > On 5/26/07, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:
>> >
>> >> Anyone have ideas on how to cure
>> >>
>> >> May 25 16:20:03 node13 kernel: TCP: [192.168.0.15]:53815 to
>> >> [192.168.0.13]:50992 tcpflags 0x11<FIN,ACK>; syncache_expand:
>> >> Segment failed SYNCOOKIE authentication
>> >>
>> >> The hardware and kernel on 192.168.0.15 and 192.168.0.13
>> >> are identical.
>> >>
>> >> --
>> >> Steve
>> >
>> > 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat May 26 04:25:29 GMT 2007
>> >
>> > I got the same problem and my sever paniced today.
>>
>> Please provide the panic message and if available a backtrace for the
>> panic.  We have to track down the exact cause of it (which may not
>> necessarily be the syncache).
>>
>> > TCP: [70.162.96.41]:54686 to [IP removed for security reasons]:59999
>> > tcpflags 0x18<PUSH,ACK>; syncache_expand: Segment failed SYNCOOKIE
>> > authentication
>>
>> Logging of TCP segment validation failure has recently been enabled
>> to aid debugging of TCP (interoperability) issues.
>>
>> This particular message means that a SYN was received on a listen
>> socket but no matching syncache entry was found.  The second test
>> for a syncookie also failed.  Normally this means a spoofed packet
>> or port scan is hitting your machine.  To make this certain you should
>> answer a couple of questions:  a) What daemon is running on your port
>> 59999?  b) Do you know [70.162.96.41] and does it have any business
>> in contacting your daemon on 59999?
>>
>> I agree that the log message should be made more clear to avoid
>> unnecessary confusion.  Nothing is broken and syncache is doing its
>> job just fine.
>>
>> -- 
>> Andre
> 
> Hello Andre,
> 
> Thanks for looking into this issue.

You're always welcome.

> The server IP isn't known by anyone, just me and my friend, and yes I
> know 70.162.96.41 which is his IP in a Linux box which runs distro
> Ubuntu.

Please obtain the exact version number of the Linux kernel that is
running on your friends box on 70.162.96.41.  This will help me to
track down the source of the problem and which OS gets it wrong.

> I run sshd in 59999, and we were both connected to it, then it died.

The connection or sshd itself?

> This is a server, so I removed the debug options to not slow it down.

We have to track down the cause of the panic and it would really
help if you could find a way to reproduce it.  To see the real source
of the panic you need a kernel with these options present:

options		KDB		# Enable kernel debugger support.
options		DDB		# Support DDB.

With these options you drop into the kernel debugger when a panic
happens.  Once there you have to type "trace" to get a backtrace.
Either transcribe it by hand or take a picture with a digicam and
make it available for download somewhere (please don't send it by
email, picture attachments are filtered).  A serial console would
be even better as you can simply copy-paste it from another machine.
After transcribing the backtrace you can type "reset" to reboot.

> If you think port scan could crash 7.0-CURRENT, Can you run nmap and
> test it 7.0-CURRENT?

A port scan should not be able to crash FreeBSD.

> Do you think disabeling syncache would prevent my box against the same
> panic again?

Syncache can't be disabled.  Only syncookies can be disabled but that
won't really help as you simple get a different error.

A few hours ago I've committed a reworked tcp_input() SYN processing
section that'll either fix you issue or expose a more detailed error
message.

-- 
Andre