Segment failed SYNCOOKIE?
Abdullah Ibn Hamad Al-Marri
almarrie at gmail.com
Mon May 28 22:10:34 UTC 2007
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/
More information about the freebsd-current
mailing list