RE: pf buggy on 6.1-STABLE?
- From: "Dmitry Andrianov" <dimas@xxxxxxxxxxx>
- Date: Thu, 8 Jun 2006 11:40:03 +0400
Hi.
I'm not sure it is related to your case but... I have seen a situation
when application used for load-testing web server running on MS Windows
box failed establishing HTTP connections to the server . Investigation
identified that this is due to the fact that Windows relatively quickly
reuses source TCP port numbers for these outbound connections. I'm not
sure if Microsoft violates TCP standard with that or not. The fact is
that pf keeps "closed" entries in the state table for 90 second and it
still remembers old source port when Windows send SYN from it trying to
establish new connection. As result, pf considers that packet invalid
and drops it.
You can check pfctl -s info . In my case the state-mismatch counter was
increasing with for every falied connection.
In any case, output of that tool can be very useful to you - if you see
one of counters for dropped packet increasing, you will have an idea
why.
Regards,
Dmitry Andrianov
PS: my problem was solved adding following lines to pf.conf:
# set short timeout for TCP closed state because Windows tends to reuse
# the same outgoing port very quickly and pf starts refusing new
connections
# because of invalid state
# (This occurs when load testing DMZ server from LAN)
set timeout { tcp.closed 15 }
-----Original Message-----
From: owner-freebsd-pf@xxxxxxxxxxx [mailto:owner-freebsd-pf@xxxxxxxxxxx]
On Behalf Of Mark Morley
Sent: Thursday, June 08, 2006 3:26 AM
To: freebsd-pf@xxxxxxxxxxx; freebsd-stable@xxxxxxxxxxx
Subject: pf buggy on 6.1-STABLE?
Hi folks,
Wondering if this rings any bells for anyone:
After upgrading a handful of web servers from FreeBSD 4.11 with ipfw to
6.1-STABLE with pf, customers started reporting that occasionally their
server side scripts would fail to connect to the SQL servers (which are
still 4.11 and are attached via a separate dedicated gigabit network).
A test page that makes 10,000 rapid SQL connections which connected 100%
of the time before, now will usually see anywhere from one or two failed
connections to a dozen or so (per 10,000)
After trying many other things first, we finally found that 'pf' seems
to be the culprit.
Disabling pf with pfctl -d allows 100% of all connections to work, and
as soon as we enable it we see connection failures again.
I've tried changing the pf rule set in different ways, with and without
scrubbing, with and without queues, even to the point where I have a
single rule that just allows everything. It doesn't seem to matter what
the rules actually are, just whether or not pf is enabled.
I recompiled the kernel with pf disabled and ipfw enabled, and it works
fine with 100% successful connections. We have no funky compiler
options or anything like that.
Any thoughts?
Mark
--
Mark Morley
Owner / Administrator
Islandnet.com
_______________________________________________
freebsd-pf@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@xxxxxxxxxxx"
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: reading process memory
- Next by Date: Re: reading process memory
- Previous by thread: Re: pf buggy on 6.1-STABLE?
- Next by thread: panic: Fatal trap 12: page fault while in kernel mode (current process = 4254 (perl5.8.8))
- Index(es):
Relevant Pages
|
