On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
> The next thing I tried was "/etc/rc.d/pf stop", which worked. Then I
> did "/etc/rc.d/pf start", which also worked. However, what I saw next
> surely indicated a bug in the pf layer somewhere -- "pfctl -s states"
> and "pfctl -s
On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
> Here's one piece of core.0.txt which makes no sense to me -- the "rate"
> column. I have a very hard time believing that was the interrupt rate
> of all the relevant devices at the time (way too high). Maybe this data
> becomes w
On Mon, May 02, 2011 at 06:58:54PM -0700, Jeremy Chadwick wrote:
> Status: Enabled for 76 days 06:49:10 Debug: Urgent
> The "pf uptime" shown above, by the way, matches system uptime.
> ps -axl
>
> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
> 0 42
I read those graphs differently: the problem doesn't arise slowly,
but rather seems to start suddenly at 13:00.
Right after 13:00, traffic on em0 drops, i.e. the firewall seems
to stop forwarding packets completely.
Yet, at the same time, the states start to increase, almost linearly
at about one
On Sun, Jan 16, 2011 at 01:41:22PM +0100, Paul Schenkeveld wrote:
> There is an ARP request which is replied to by the carp master (test).
> the ping to the carp address does not even appear on the sis4 interface
> of test1.
Everything looks fine, except for the fact that the ping (echo request)
The specific change in the OpenBSD tree was
Revision 1.494
Mon Jul 4 08:28:04 2005 UTC (2 years, 4 months ago) by markus
Branch: MAIN
Changes since 1.493: +3 -3 lines
restrict the tcp.finwait timeout (45s) to state combinations where we have
seen a FIN from both sides (whether ACKed or not) and u
On Tue, Nov 20, 2007 at 10:50:41AM +0100, Jan Srzednicki wrote:
> And the state becomes:
>
> self tcp MY_IP_HERE:12525 <- MY_IP_HERE:64829 ESTABLISHED:FIN_WAIT_2
>[390096685 + 66608] wscale 1 [3173294128 + 66608] wscale 1
>age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes,
On Mon, Nov 19, 2007 at 09:21:42PM +0100, Jan Srzednicki wrote:
> I'm positively sure it's precisely this value that timeouts this
> conection (which later on get state mismatches).
What does pfctl -vvss show for such a state entry, in particular the
right-most part of the first line ("ESTABLISHE
On Fri, Jul 21, 2006 at 10:57:28AM +0200, Michal Mertl wrote:
> The proxy in fact runs in parallel (according to "pfctl -s info" it did
> about 50 inserts and removal in the state table per second - some 10Mbit
> of traffic, probably mostly HTTP) and it is quite possible that your
> explanation is
On Fri, Jul 21, 2006 at 02:05:45AM +0200, Max Laier wrote:
> Which proxies are you using? The "pool_ticket: 1429 != 1430" messages you
> quote below indicate a synchronization problem within the app talking to pf
> via ioctl's. Tickets are used to ensure atomic commits for operations that
> r
On Wed, Jun 07, 2006 at 04:25:37PM -0700, Mark Morley wrote:
> 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 witho
On Fri, Mar 11, 2005 at 01:50:47PM +0100, Emanuel Strobl wrote:
> > Then I have another problem which may be a design problem.
> > I am multihomed and have several pass reply-to rules. So far things are
> > working fine but block return doesn't! Of course, the return gets over the
> > default rout
12 matches
Mail list logo
