On 2007/02/14 12:11, Darren Spruell wrote: > > Yeah, when I went through it scrub rules had nothing to do with it. > All state, period. (Note that in -current the default is now to > implicitly build rules with both 'keep state' and 'S/SA' without > having to specify; default stateful behavior makes these boo-boos less > likely.)
> When I had the same problem, it was very erratic and seemed isolated > to a Linux box at first too. I don't know if there's something in the > TCP stack that reacts more adversely to this, but my fix in that case > was a refactoring of my state model. YMMV. New linux kernels (and Windows) set the window size such that wscale>0 by default (if you want to test this from an OpenBSD box, increase net.inet.tcp.recvspace). As tcpdump will show you, the wscale value is *only* in SYN packets. This is multiplied by the window size in the TCP headers of subsequent packets to find the actual window size (see RFC1323 paragraph 1.1 on 'window size limit' and paragraph 2). If the state was created from a packet other than the SYN, it won't have wscale information (if it was collected, it's shown in pfctl -ss -v). Without this the range of permitted sequence numbers is incorrect and state failures can occur (especially in those cases where the unscaled window size, shown by 'win' in tcpdump, works out to a small value). (People who are intentionally using stateless filtering will have to adjust their ruleset when they upgrade to 4.1; from the mailing list posts about it, the number of people who will be affected negatively by this change is much smaller than the number who will be affected positively).
