Re: Segment failed SYNCOOKIE?

On 5/28/07, Andre Oppermann <andre_at_freebsd.org> wrote:
> 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'll ask him when he comes online

>
> > I run sshd in 59999, and we were both connected to it, then it died.
>
> The connection or sshd itself?
sshd accepts connections on port 59999 to avoid ssh attempt sin default port.

>
> > 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.

This is a server I manage via sshd, no phiscal access to it, so how
can I catch the panic trace? log as su and keep my connection alive?
if I can get the panic, I'll be able to copy & paste it easily via the
kssh client.


>
> > 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

I'll csup and compile the kernel with

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

Per your request once my box comes onlines. :)

-- 
Regards,

-Abdullah Ibn Hamad Al-Marri
Arab Portal
http://www.WeArab.Net/