On 12/17/2007 03:32:39 AM, Henrik Johansen wrote:
[Karl O. Pinc] wrote:
On 12/14/2007 02:17:22 AM, Henrik Johansen wrote:
Hi list,
We are experiencing a steady flow of BAD state error messages that
I cannot explain.
I continue to have problems with (Microsoft) hosts that
violate the 2MSL TCP rule (STD7, RFC793, page 27
"Knowing When to Keep Quiet")....
It would, *urp*, be nice if pf had a way to
specify the MSL in the scrub directive to
work around the brokenness.
[...]
I don't think that this is my problem however. Most BAD state
messages are generated by ACK packets, not SYN packets.
I just saw the 1 minute (rather, 59 second) time period and
started coding to see if the rest matched. Ah well.
AFAIK, when a client violates the 2MSL rule should I not see the
initial
SYN blocked by PF (since it would create a state mismatch, hence a BAD
state log entry) ?
Yes. (I'm not clear about what I'm looking at when I look at
bad state log entries. I couldn't find documentation
and decided not to turn my brain on.)
As a side note, have you tried scaling down the tcp.closed parameter
for
PF ? I have seen numerous references that this might help against 2MSL
violations ...
Duh. That's exactly the sort of thing I need. I
can't believe I've not explored that option. Thanks!
I'll need to examine my traffic to see whether
I need to mess with tcp.closed, interval, or tcp.finwait.
(I know in one case it's RST packets that are the trouble
so tcp.closed/interval would do the trick for that.)
What am I missing? Based on google searching
RSTs (fixed with tcp.closed)
more likely associated with 2MSL violations than
FINs (tcp.finwait). Why is this? Do perverse
TCP stack programmers prefer RSTs?
I've not thought this through, but it seems
to me that there are two general cases when
RSTs are received: when the receiving system
returns to LISTEN (receiving system in
un-synchronized state, RST received while in
SYN-SENT or SYN-RECEIVED), and otherwise.
If the 2MSL violators are violating 2MSL
only for those connections that never reached
the ESTABLISHED state (I _think_ I remember this
from my tcpdump analysis) then would it make
sense for pf to have a separate timeout for
these sorts of resets? A tcp.aborted timeout
for when RSTs are received before the tcp.established
state is reached?
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
P.S.
I also don't get the tcp.opening state. As
pf.conf(5) is written I can't tell what sends
pf out of tcp.first into tcp.opening.
After reading the udp.single entry I thought
it was something like:
"tcp.opening The state if the
source host sends more than one packet before
the destination host ever sends a packet."
But that does not make sense if pf is always supposed to
be in one of the listed tcp states. So, I suspect
it's something like:
"tcp.opening The state before the destination host
sends it's first packet after the SYN/ACK tcp handshake
packet."
Or alternately:
"tcp.opening The state before the destination host
sends it's first packet with a data payload."
Why wouldn't it be:
"tcp.opening The state after the first packet but
before the 3-way tcp handshake has been completed."
Perhaps not the last because pf does not know the
handshake got through until the destination sends
it's first packet with a data payload?
