[sllug-members]: Potential Suse 10.2 Bug in browsing

Robert Lewis rll at felton.felton.ca.us
Fri Dec 29 21:11:45 MST 2006


Allen Parker wrote:
> On 12/29/06, Stuart Jansen <sjansen at buscaluz.org> wrote:
>> On Fri, 2006-12-29 at 17:36 -0700, Allen Parker wrote:
>> > As a side note, I wouldn't blame SuSE's kernel or latest release, I
>> > know they've got a LOT of QA they do before they do RTM (release to
>> > market).
>>
>> That isn't very good reasoning. If you've been paying attention to LKML
>> then you know that a really nasty corner case file corrupt bug was
>> recently discovered and hopefully squashed. Linus did some digging and
>> the problem's been around since at least 2.6.5. On a similar note, one
>> of my co-workers discovered several LVM snapshots are broken on stock
>> SLES10. One would expect an important technology like LVM to be part of
>> the RTM process, yet these problems slipped by.
>
> You mean that LVM broke on one machine and one machine only, which
> happend to have the same major version #? I'm kind of wondering what
> LVM has to do with tcp though, could you clue me in?
>
>> When you're debugging a problem, don't throw away possibilities based on
>> blind faith. Prioritize, test and verify.
>
> When giving a user advice on where to start looking, use the KISS
> principle. If that user happens to be doing something fairly
> dangerous, like blaming gregkh (i'm sure you know who he is, since you
> read LKML) for a problem that is in all actuality probably user error
> in the first place, it's generally good form to warn them that they
> should be looking someplace else.
>
>> That said, a kernel bug wouldn't be the first thing I'd investigate. I'd
>> suspect a misconfigured network first. Maybe the box is misconfigured,
>> maybe a router is misconfigured, maybe an overzealous firewall is
>> getting in the way. It could be obvious like routing, or it could be
>> subtle like filtered ICMP.
>
> Did you even read the rest of my email?
>
>> Or it could be the kernel. Maybe a perfectly valid setting like TCP
>> cookies has been enabled without fully understanding the disadvantages.
>
> I doubt that a brand spanking new install would by default have
> syncookies turned on, and even if it did, where would the overload be
> coming from that would prevent new connections out? see below for
> lines 202-221 of
> linux-2.6.18-rc3/Documentation/networking/ip-sysctl.txt
>
>>
>> -- 
>> Stuart Jansen              e-mail/jabber: sjansen at buscaluz.org
>>                            google talk:   stuart.jansen at gmail.com
>>
>> "However beautiful the strategy, you should occasionally look at
>> the results." -- Winston Churchill
>>
>
> tcp_syncookies - BOOLEAN
>  Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
>  Send out syncookies when the syn backlog queue of a socket
>  overflows. This is to prevent against the common 'syn flood attack'
>  Default: FALSE
>
>  Note, that syncookies is fallback facility.
>  It MUST NOT be used to help highly loaded servers to stand
>  against legal connection rate. If you see synflood warnings
>  in your logs, but investigation shows that they occur
>  because of overload with legal connections, you should tune
>  another parameters until this warning disappear.
>  See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
>
>  syncookies seriously violate TCP protocol, do not allow
>  to use TCP extensions, can result in serious degradation
>  of some services (f.e. SMTP relaying), visible not by you,
>  but your clients and relays, contacting you. While you see
>  synflood warnings in logs not being really flooded, your server
>  is seriously misconfigured.
>
> PS: I generally don't like being flamed, so don't do it.
>
Just to be crystal clear. 
I have reloaded on the same identical machine plugged into the
same router the following:

SUSE 10.1       works
Kubuntu 6.1      works
SUSE 10.2       can not reach that one IP site.
XP                      works

I appreciate everyones attention, comments, suggestions etc.
We are in the middle of comparing the traces from wireshark
on a machine that works vrs one that doesn't.


More information about the sllug-members mailing list