: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".
:
:\ /  Max Laier                          | ICQ #67774661

    Got it.   Oooh, that's nasty.  It's confirming that the SYN is for
    the other direction by testing the seqlo variable, which is non-zero
    on the direction that already got the SYN, and zero on the direction
    that hasn't.  That code comment deserves to be expanded a bit :-)

    Here's a new patch, changing the one SYN detect flag into two flags
    and setting them in the proper places.  'pfctl -s state -v -v' now
    reports three possible states:  'indeterminate', 'incomplete', and
    'good'. 

	fetch http://apollo.backplane.com/DFlyMisc/pickups02.patch

    I did some quick testing and all three states appear to work properly,
    so if someone forgets to 'keep state' in both directions the state
    output will say 'incomplete' instead of 'good'.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>