Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Jan 2006 09:45:51 +0100
From:      Daniel Hartmeier <daniel@benzedrine.cx>
To:        Attila Nagy <bra@fsn.hu>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Is RFC1323 support flawed? (only with pf enabled)
Message-ID:  <20060103084551.GF17829@insomnia.benzedrine.cx>
In-Reply-To: <43B96824.20608@fsn.hu>
References:  <43B96824.20608@fsn.hu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 02, 2006 at 06:51:32PM +0100, Attila Nagy wrote:

> Any ideas?

RFC1323 support includes TCP window scaling (wscale), which affects pf
stateful filtering. There have been bugs with that in the past, but the
code in 6.x should contain all fixes for them. Maybe you found a new
one.

When you say "a simple pass only ruleset", do you mean a ruleset
consisting of a single "pass all" rule (i.e. not creating state), or one
that includes "pass keep state" (and possibly "scrub") rules?

If the latter, there's one possible user mistake that could result in
the effects you're seeing. If you filter statefully, but create state
not on the initial SYN packet of each TCP connection, but a subsequent
one, pf doesn't note the relevant wscale factors (seen only during the
first two packets of the handshake), which can have precisely this
effect, stalling connections after a while (when one peer starts to
actually use large windows, making use of its negotiated wscale factor).
It's also possible that this would occur more often with specific OS
peers, as the OS (and TCP settings, like receive buffer size) influence
the wscale factors being used.

To rule this out, make sure you either don't create state at all, or
create state on the first SYN when you do (look for any "pass" rules
which don't also include "keep state"). pfctl -vss prints the wscale
factors being honoured by pf for each state.

If that's not it, can you enable pf debug logging (pfctl -xm), note
pfctl -si output, then reproduce a failing connection, then run
pfctl -si again, compare the output (looking for any counters increasing
the obvious ones), and checking /var/log/messages for any lines from pf?

Daniel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060103084551.GF17829>