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, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News
