https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
Robert Schulze changed:
What|Removed |Added
Resolution|--- |FIXED
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #17 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kp
Date: Sat Apr 8 09:49:21 UTC 2017
New revision: 316641
URL: https://svnweb.freebsd.org/changeset/base/316641
Log:
MFC r316355
pf: Fix leak of p
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #16 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kp
Date: Sat Apr 8 09:48:21 UTC 2017
New revision: 316640
URL: https://svnweb.freebsd.org/changeset/base/316640
Log:
MFC r316355
pf: Fix leak of p
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #15 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kp
Date: Sat Apr 1 12:22:34 UTC 2017
New revision: 316355
URL: https://svnweb.freebsd.org/changeset/base/316355
Log:
pf: Fix leak of pf_state_keys
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #14 from Max ---
--- sys/netpfil/pf/pf.c.orig2017-03-30 09:54:22.05649 +
+++ sys/netpfil/pf/pf.c 2017-03-30 09:55:10.735221000 +
@@ -3508,7 +3508,7 @@
(counter_u64_fetch(r->states_cur) >= r->max_state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #13 from Robert Schulze ---
By the way: could someone please attach a patch based on the assumptions you
made?
regards,
Robert Schulze
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #12 from Robert Schulze ---
Since the affected machine is critical and cannot be rebooted without care, I
cannot confirm the fix right now. My primary intention was to report the
misbehaviour.
If a planned reboot takes place, I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #11 from Max ---
(In reply to Kristof Provost from comment #10)
I've done basic tests. It works. I can post some counters here. Perhaps we
should test it without rdr/nat rule.
By the way, "pfctl -Fi" (flush info) does not clea
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
Robert Schulze changed:
What|Removed |Added
Severity|Affects Only Me |Affects Some People
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #9 from Max ---
It seems that I'm right. The problem has gone. Hope that someone more
experienced will review this fix.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #8 from Max ---
I think the problem is in pf_create_state():
/* check maximums */
if (r->max_states &&
(counter_u64_fetch(r->states_cur) >= r->max_states)) {
counter_u64_add(V_pf_stat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #7 from Max ---
A bit more info...
Before reaching the limit:
Status: Enabled for 0 days 04:08:59 Debug: Urgent
State Table Total Rate
current entries 120
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #6 from Robert Schulze ---
(In reply to Max from comment #5)
Thank you for your efforts.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-pf@free
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #5 from Max ---
Well, I can reproduce the problem.
I have 3 hosts with 10.3 release (generic kernel). "Server", "client" and
"firewall".
Complete pf.conf of "firewall" host:
set skip on {lo, em2}
table persist { 192.168.0.10,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #4 from Robert Schulze ---
(In reply to Max from comment #3)
Those old-aged src track entries are only on rdr rule:
# pfctl -vsS | grep -A1 $client
$client -> $www_host ( states 4, connections 0, rate 0.0/0s )
age 02:39:54,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #3 from Max ---
(In reply to Robert Schulze from comment #2)
I'm unable to reproduce the described behaviour on 10.3 release with generic
kernel and your rules. It works just fine. Maybe the problem is related to
filter rule's
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
--- Comment #2 from Robert Schulze ---
There are no pf-related kernel messages.
# pfctl -st | grep src.track
src.track 0s
So source tracking entries should expire, as soon there are no more referenced
states. The "expi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
Max changed:
What|Removed |Added
CC||maxi...@als.nnov.ru
--- Comment #1 from Max
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-pf@FreeBSD.org
--
You are
20 matches
Mail list logo
