Re: FairQ ALTQ for PF - Patch #2

[Max Laier <max@xxxxxxxxxxxxxx>]

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.
> :
> :cheers
> :  simon
>
>     I figured out another reason why linux boxes couldn't connect to
> me.
>
>     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 
factor.

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,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News