:>     It's got to be something PF (packet filter) is doing.  I was using
:> a Cisco with the T1.  I'm using a DFly box running PF with the DSL
:> line. I'm trying to track it down.
:
:This is usually a symptom of creating state on a TCP packet other than the 
:initial SYN.  Make sure you add "flags S/SA" to all your tcp keep state 
:rules.  There is plenty on this in the FAQs and lists (freebsd-pf@ and 
:the OpenBSD pf list) for more detailed reference.
:
:-- 
:/"\  Best regards,                      | mlaier@freebsd.org
:\ /  Max Laier                          | ICQ #67774661

    I kinda half understand that.  Are you saying that because creating
    state on other then the initial syn has no information on the window
    scale (which is only handled in the SYN and SYN+ACK), that it will
    blow up?

    Here are two questions:

    (1) I'm using keep state, not synproxy.  Is PF still attempting to do
	window sequence space comparisons and dropping packets if they do
	not match?  If it is, do you know where in the code that is
	(I've been staring at it a while trying to find just such a 
	comparison but not having a whole lot of luck).

    (2) If I restart PF, and do not create state for pre-existing connections,
	won't that blow up the classification of those connections?

	In particular, if there are a lot of flows going through the router
	and it drops some of its state, won't those flows wind up being
	left out of the state code from that point on?  They would not be
	identifiable to the fairq code, then, which would be a fairly
	significant problem.

    What I would like to do, if (1) is true, is modify PF to flag that the
    state was created without a SYN, and have it automatically ignore 
    sequence space comparisons for that case.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>