[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: recent reliability issues (solved)
From:       Jason Patterson <jason () pattosoft ! com ! au>
Date:       2000-07-31 14:45:47
[Download RAW message or body]

>>But still, Solaris 8 should respect the fact that we have tcp_wscale_always
>>turned off, and thus should not use wscale. Which is what that patch fixed.
>
>Looking a the bug report, it appears that the bug only prevented
>tcp_wscale_always from working; i.e., the WSCALE option would not be used
>for connections where it was not necessary.

Fair enough.

>There is no way to prevent Solaris 8 from using WSCALE if you try to
>offer a larger > 64K window.

Obviously, that's a given.

>The fix sets the wscale option on more connections if tcp_wscale_always is
>set, and never on less.

Okay, but then how do you explain the 160k chopping problem going away
after patch 109472-01... In the past I _know_ that turning on wscale
and 256k windows _did_ cause a peer-hit truncation problem, which I now
know was presumably because ipfilter cannot handle wscale'd packets.

The only other reasonable explanation for how patch 109472-01 solved
the 160k problem is to blame it too on the SACK data corruption bug, but
that seems a bit too coincidental given my prior records about wscale,
plus the fact that we _know_ ipfilter cannot handle wscale. Still, I
guess its possible.

>>ndd -set /dev/tcp tcp_xmit_hiwat 65535
>>ndd -set /dev/tcp tcp_recv_hiwat 65535
>>ndd -set /dev/udp udp_xmit_hiwat 16384
>>ndd -set /dev/udp udp_recv_hiwat 16384
>>ndd -set /dev/tcp tcp_sack_permitted 2
>
>Ah, but Solaris rounds these values up to a multiple of the MTU; with
>the above sizes I get a 66608 window on rlogin (46*1448)

Hmmh... Again, good to know. This should really be noted in the TCP/IP
Answerbook, since I always just assumed Solaris would round DOWN because
these are the high watermarks (maximums).

It should also be noted in the tuning web page that I mentioned earlier.
Would you like to tell them, or shall I...??

PS: Thankyou greatly for pointing this out.

>Presumably this window would be offered with a scale of 1 and all
>sizes would come out a factor 2 too small (and this, I think, would
>just about work with ipfilter's default slack)

Well we've been using 65535 for years with ipfilter (going way back to
Solaris 2.5 I think, or perhaps even 2.4). But just to be on the safe
side, I've now lowered them to 64000 so that there's no chance of
accidentally using wscale and possibly confusing ipfilter.

Now knowing that wscale might break ipfilter, is there any way to totally
disable it in Solaris 8, given that tcp_wscale_always can only be used to
permanently turn it on, not off. I don't see a "tcp_wscale_permitted"
or anything, so there is nothing to stop someone from writing a clever
little dos-attack which tries to confuse systems running ipfilter...


JASON PATTERSON
 jason@pattosoft.com.au  http://www.pattosoft.com.au/jason

 Imagine that CRAY decides to make a personal computer. It contains 16
 Alpha based processors executing in parallel, has 800 megabytes of RAM,
 9 Gigabytes of disk storage, a resolution of 4096 x 4096 pixels, does
 24bit 3D graphics in realtime, relies entirely on voice recognition for
 input, fits in your shirt pocket and costs $300. What is the first
 question the computer community asks?

 "Is it DOS compatible?"

[prev in list] [next in list] [prev in thread] [next in thread]