DragonFly kernel List (threaded) for 2008-04
Re: FairQ ALTQ for PF - Patch #2
On Monday 07 April 2008 20:42:08 Matthew Dillon wrote:
> :I concur. Keep state should be explicit. Furthermore, I don't expect
> :keep state not to work across reboots. That's why I then write keep
> :state flags S/SA. Something clearly need to be untangled here. Keep
> :state should keep state as good as possible, but not reject
> : connections.
> : simon
> I figured out another reason why linux boxes couldn't connect to
> I wasn't running keep state on incoming traffic, only outgoing.
> That means the keep state didn't have the initial SYN packet from an
> outside host making a connection into me. No initial SYN, no window
> scaling info.
> My current pickup check is not quite sufficient, either. I have to
> check that the SYN was observed in both directions. Seeing just
> one of the SYNs may not be enough. I'll have to re-read the window
> scaling rules.
> Max, or anyone... do you happen to remember whether window scaling
> is negotiated the same for both directions or whether each
> direction in a TCP connection can use a different scaling factor?
The latter, wouldn't make much sense if your peer could dictate a scaling
The wscale for the other direction is set here:
http://fxr.watson.org/fxr/source/net/pf/pf.c?v=DFBSD#L3810 ff. Note that
this is in the state tracking already, we are looking at the first packet
from src and TH_SYN is set (-> this is the SYN+ACK) from the peer.
dst.wscale was already set when the state was created:
http://fxr.watson.org/fxr/source/net/pf/pf.c?v=DFBSD#L2727 (where src is
the other end sending the initial SYN).
At least this is the way things behave when you have "flags S/SA".
/"\ Best regards, | email@example.com
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News