Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections
Thanks, Andreas!
Kristof, will you handle that? If you are busy, I can try to refresh
my memory.
On Mon, Feb 18, 2019 at 06:30:32PM +0100, Andreas Longwitz wrote:
A> Hello,
A>
A> > Ok, thanks, I will commit the patch shortly. I do not see a point in
waiting
A> > for two more weeks, sure report me if anything goes wrong.
A>
A> your patch for counter(9) on i386 definitely solves my problem discussed
A> in this thread.
A>
A> Because fetching a counter is a rather expansive function we should use
A> counter_u64_fetch() in pf_state_expires() only when necessary. A "rdr
A> pass" rule should not cause more effort than separate "rdr" and "pass"
A> rules. For rules with adaptive timeout values the call of
A> counter_u64_fetch() should be accepted, but otherwise not.
A>
A> For a small gain in performance especially for "rdr pass" rules I
A> suggest something like
A>
A> --- pf.c.orig 2019-02-18 17:49:22.944751000 +0100
A> +++ pf.c2019-02-18 17:55:07.396163000 +0100
A> @@ -1558,7 +1558,7 @@
A> if (!timeout)
A> timeout = V_pf_default_rule.timeout[state->timeout];
A> start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START];
A> - if (start) {
A> + if (start && state->rule.ptr != &V_pf_default_rule) {
A> end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END];
A> states = counter_u64_fetch(state->rule.ptr->states_cur);
A> } else {
A>
A> --
A> Andreas
A>
--
Gleb Smirnoff
___
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections
On Tue, Nov 13, 2018 at 10:01:14PM +0100, Andreas Longwitz wrote: A> OK, in the meantime I did some more research and I am now quite sure the A> problem with the bogus pf_default_rule->states_cur counter is not a A> problem in pf. I am convinced it is a problem in counter(9) on i386 A> server. The critical code is the machine instruction cmpxchg8b used in A> /sys/i386/include/counter.h. A> A> From intel instruction set reference manual: A> Zhis instruction can be used with a LOCK prefix allow the instruction to A> be executed atomically. A> A> We have two other sources in kernel using cmpxchg8b: A> /sys/i386/include/atomic.h and A> /sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S A single CPU instruction is atomic by definition, with regards to the CPU. A preemption can not happen in a middle of instruction. What the "lock" prefix does is memory locking to avoid unlocked parallel access to the same address by different CPUs. What is special about counter(9) is that %fs:%esi always points to a per-CPU address, because %fs is unique for every CPU and is constant, so no other CPU may write to this address, so lock prefix isn't needed. Of course a true SMP i386 isn't a well tested arch, so I won't assert that counter(9) doesn't have bugs on this arch. However, I don't see lock prefix necessary here. -- Gleb Smirnoff ___ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
[Differential] [Requested Changes To] D1944: PF and VIMAGE fixes
glebius requested changes to this revision. glebius added a comment. This revision now requires changes to proceed. Thanks a lot, Nikos. I've fixed the problem of sleeping in UMA on kldunload. It was out the scope of the patch. I also committed the first part of the patch - mutexes initialization. Nikos, can you please svn update and then arc update, so that updated patch is posted here? REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, kristof, gnn, rodrigc, glebius Cc: julian, robak, freebsd-virtualization, freebsd-pf, freebsd-net ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
[Differential] [Commented On] D1944: PF and VIMAGE fixes
glebius added a comment. Recently Nikos has asked questions on kernel debugging. So, I guess, he is working. REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, glebius, rodrigc, kristof, gnn Cc: robak, freebsd-virtualization, freebsd-pf, freebsd-net ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
[Differential] [Updated] D1944: PF and VIMAGE fixes
glebius added a comment. Nikos, acking that I see the patches. Right now I'm waiting for pf to stablize after recent patches to fragment handling. Kristof is working on the known problem. Meanwhile you can finish your patch moving from "almost there" to "there" :) If you got any questions about pf or FreeBSD kernel interfaces, feel free to ask me via email. REVISION DETAIL https://reviews.freebsd.org/D1944 To: nvass-gmx.com, gnn, bz, zec, trociny, rodrigc, glebius Cc: freebsd-virtualization, freebsd-pf, freebsd-net ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: PF in FreeBSD 10.0 Blocking Some SSH
On Mon, Jan 27, 2014 at 10:22:30PM -0500, Robert Simmons wrote:
R> > On Sun, Jan 26, 2014 at 06:19:34PM -0500, Robert Simmons wrote:
R> > R> Over the course of a few hours there are a handful of SSH packets that
R> > R> are being blocked both in and out. This does not seem to affect the
R> > R> SSH session, and all the blocked packets have certain flags set [FP.],
R> > R> [R.], [P.], [.], [F.]. The following is my ruleset abbreviated to the
R> > R> rules that apply to this problem:
R> > R>
R> > R> ext_if = "en0"
R> > R> allowed = "{ 192.168.1.10 }"
R> > R> std_tcp_in = "{ ssh }"
R> > R> block in log
R> > R> block out log (user)
R> > R> pass in quick on $ext_if proto tcp from $allowed to ($ext_if) port
R> > R> $std_tcp_in keep state
R> > R>
R> > R> Why are those packets being blocked?
R> >
R> > Do I understand you correct that the ssh sessions work well, but you
R> > see blocked packets in the pflog?
R>
R> Yes, this is correct. I have not seen this in the logs since
R> yesterday, so it may have been a network issue.
That could be stray retransmits of data that already been received
and acknowledged. pf keeps track of sequence numbers in tcp connections
flowing through it.
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: PF in FreeBSD 10.0 Blocking Some SSH
Robert,
On Sun, Jan 26, 2014 at 06:19:34PM -0500, Robert Simmons wrote:
R> Over the course of a few hours there are a handful of SSH packets that
R> are being blocked both in and out. This does not seem to affect the
R> SSH session, and all the blocked packets have certain flags set [FP.],
R> [R.], [P.], [.], [F.]. The following is my ruleset abbreviated to the
R> rules that apply to this problem:
R>
R> ext_if = "en0"
R> allowed = "{ 192.168.1.10 }"
R> std_tcp_in = "{ ssh }"
R> block in log
R> block out log (user)
R> pass in quick on $ext_if proto tcp from $allowed to ($ext_if) port
R> $std_tcp_in keep state
R>
R> Why are those packets being blocked?
Do I understand you correct that the ssh sessions work well, but you
see blocked packets in the pflog?
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Network severely unstable 10.0-PRERELEASE
On Thu, Jan 02, 2014 at 08:16:21AM +1300, Berend de Boer wrote: B> Gleb> Can you please try attached patch? I hope it'll fix the B> Gleb> panic. B> B> Have been running this without the rule change, to see if it doesn't B> introduce any adverse effects. So far so good. When I'm back from B> holiday (this Saturday), I'll enable the bad keyword. Good! Waiting for your feedback. Thanks! -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Network severely unstable 10.0-PRERELEASE
Berend, On Mon, Dec 30, 2013 at 03:48:07PM +1300, Berend de Boer wrote: B> >>>>> "Gleb" == Gleb Smirnoff writes: B> B> Gleb> Can you share a vmcore from paniced FreeBSD 10 system and B> Gleb> kernel binary? B> B> My kernel config attached, freshly compiled from 10-STABLE, svn B> revision 260055. Can you please try attached patch? I hope it'll fix the panic. No idea on how good will your rule work, however. -- Totus tuus, Glebius. Index: sys/netpfil/pf/pf_lb.c === --- sys/netpfil/pf/pf_lb.c (revision 260055) +++ sys/netpfil/pf/pf_lb.c (working copy) @@ -663,6 +663,7 @@ notrans: uma_zfree(V_pf_state_key_z, *nkp); uma_zfree(V_pf_state_key_z, *skp); *skp = *nkp = NULL; + *sn = NULL; return (NULL); } ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Network severely unstable 10.0-PRERELEASE
On Fri, Dec 27, 2013 at 01:55:31PM +1300, Berend de Boer wrote: B> >>>>> "Gleb" == Gleb Smirnoff writes: B> B> Gleb> Can you share a vmcore from paniced FreeBSD 10 system and B> Gleb> kernel binary? B> B> Yes, what kernel options do I need to compile in to get you this? http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html#kerneldebug-obtain -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Network severely unstable 10.0-PRERELEASE
Berend, On Thu, Dec 26, 2013 at 08:32:53AM +1300, Berend de Boer wrote: B> Gleb> Does the system panic the same way as described in B> Gleb> misc/182141) on 10.0? B> B> Indeed, no change. Purely a kernel issue. Repeatable since FreeBSD B> 9.x, across 10.x, across 32-bit and 64-bit. B> B> There's a related issue: B> B> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182557 B> B> Let me know if you need anything else from me. B> B> I've just grabbed the latest FreeBSD 10 sources, and recompiling now. B> B> Next Monday I'm able to enable the bug triggering keyword again (not B> now, all the family is here and wants a stable network :-) ). Can you share a vmcore from paniced FreeBSD 10 system and kernel binary? -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Network severely unstable 10.0-PRERELEASE
On Thu, Dec 26, 2013 at 02:17:38PM +0400, Gleb Smirnoff wrote: T> On Thu, Dec 26, 2013 at 08:32:53AM +1300, Berend de Boer wrote: T> B> Gleb> Does the system panic the same way as described in T> B> Gleb> misc/182141) on 10.0? T> B> T> B> Indeed, no change. Purely a kernel issue. Repeatable since FreeBSD T> B> 9.x, across 10.x, across 32-bit and 64-bit. T> B> T> B> There's a related issue: T> B> T> B> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182557 T> B> T> B> Let me know if you need anything else from me. T> B> T> B> I've just grabbed the latest FreeBSD 10 sources, and recompiling now. T> B> T> B> Next Monday I'm able to enable the bug triggering keyword again (not T> B> now, all the family is here and wants a stable network :-) ). T> T> What is the bug triggering keyword? Can you please provide a minimal T> configuration that reproduced the bug? Already see it in the kern/182557. Thanks! -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Network severely unstable 10.0-PRERELEASE
On Thu, Dec 26, 2013 at 08:32:53AM +1300, Berend de Boer wrote: B> Gleb> Does the system panic the same way as described in B> Gleb> misc/182141) on 10.0? B> B> Indeed, no change. Purely a kernel issue. Repeatable since FreeBSD B> 9.x, across 10.x, across 32-bit and 64-bit. B> B> There's a related issue: B> B> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182557 B> B> Let me know if you need anything else from me. B> B> I've just grabbed the latest FreeBSD 10 sources, and recompiling now. B> B> Next Monday I'm able to enable the bug triggering keyword again (not B> now, all the family is here and wants a stable network :-) ). What is the bug triggering keyword? Can you please provide a minimal configuration that reproduced the bug? -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Network severely unstable 10.0-PRERELEASE
On Mon, Dec 23, 2013 at 07:56:02AM +1300, Berend de Boer wrote: B> pf has not worked well for me after version 8. Certain rules crash the B> kernel B> (http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/182141). Avoiding B> these rules gave me something that at least kept the system alive on a B> 10-CURRENT. Does the system panic the same way as described in misc/182141) on 10.0? If it does, I'm willing to debug that. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [patch] Source entries removing is awfully slow.
Kajetan, On Thu, Dec 05, 2013 at 11:07:39AM +0100, Kajetan Staszkiewicz wrote: K> > K> To have the most clean and simple code it would make the most sense to K> > use the K> aforementioned pfioc_universal_kill for both DIOCKILLSTATES and K> > K> DIOCKILLSRCNODES. But that would be a change of kernel api which I K> > assume can K> not take place inside major release, so translation of K> > structures is currently K> the way to go. Please correct me if I am wrong. K> > K> > It is okay to add new API. K> K> I was rather thinking about leaving DIOCKILLSTATES and DIOCKILLSRCNODES ioctls K> in place but change the structure passed to them to pfioc_universal_killer. So K> changint the existing API. That can't be merged. K> > So in head we will add new API/ABI, then remove obsoleted one. We will K> > merge only addition to stable/10, not removal. K> > K> > The ABI constraints for stable branches are the following. Newer kernel K> > must work with older utilxities. So, 10.1 kernel will work with pfctl from K> > 10.0, since old ioctls are still supported. K> K> Is recompiling older utilities allowed? Please note that I need to add K> ps(n?)k_table to (pfioc_src_nod|stat)e_kill and psnk_killed_states to K> psnk_src_node_kill anyway. If not, then we must consider that this patch could K> get only into head, and only with struct pfioc_universal_kill. I see no reason K> to clean up the old parser without adding the new syntax with new parameters. Recompiling old utilites is allowed. So, the plan, that would work sounds like that: 1) Add new ioctl number and new structure. Rewrite pfctl to handle it. 2) Remove old ioctls and structures. 3) Merge 1). What we achieve: 10.1 kernel understands 10.1 pfctl ans has new functionality. 10.1 kernel understands 10.0 pfctl. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [patch] Source entries removing is awfully slow.
Kajetan,
On Wed, Dec 04, 2013 at 03:29:21PM +0100, Kajetan Staszkiewicz wrote:
K> Dnia poniedziałek, 2 grudnia 2013 o 17:39:27 Gleb Smirnoff napisał(a):
K>
K> > I won't object on any interface that is consistent and resides in the
K> > '-K' and '-k' namespace. As said before, I am against utilizing new
K> > letters for options to avoid clashing with pfctl syntax in OpenBSD.
K>
K> I have a nice commandline parser working, but I got blocked by one problem.
As
K> the parser is quite big and most options are common for -K and -k, the
parser
K> is just one function for both operation modes (and a similar thing for the
K> loops going over IP addresses found by given host names). Unfortunately
K> DIOCKILLSTATES and DIOCKILLSRCNODES are using separate structures.
K>
K> Whatever the parser reads, it puts the result in the following structure
K> (defined only inside pfctl, not kernel):
K>
K> struct pfioc_universal_kill {
K> sa_family_t puk_af;
K> int puk_proto;
K> struct pf_rule_addr puk_src;
K> struct pf_rule_addr puk_dst;
K> struct pf_rule_addr puk_rdr;
K> struct pf_state_cmp puk_pfcmp;
K> charpuk_ifname[IFNAMSIZ];
K> charpuk_label[PF_RULE_LABEL_SIZE];
K> charpuk_table[PF_TABLE_NAME_SIZE];
K> u_int puk_killed_states;
K> u_int puk_killed_src_nodes;
K> };
K>
K> Which later gets translated for every ioctl to pfioc_src_node_kill or
K> pfioc_state_kill.
K>
K> To have the most clean and simple code it would make the most sense to use
the
K> aforementioned pfioc_universal_kill for both DIOCKILLSTATES and
K> DIOCKILLSRCNODES. But that would be a change of kernel api which I assume
can
K> not take place inside major release, so translation of structures is
currently
K> the way to go. Please correct me if I am wrong.
It is okay to add new API.
So in head we will add new API/ABI, then remove obsoleted one. We will merge
only addition to stable/10, not removal.
The ABI constraints for stable branches are the following. Newer kernel must
work with older utilities. So, 10.1 kernel will work with pfctl from 10.0, since
old ioctls are still supported.
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: icmp-type echoreq not matching resulting ttl exceeded
Ian, On Fri, Nov 29, 2013 at 02:28:27PM +0200, Ian FREISLICH wrote: I> At some point this stopped working. I was able to use traceroute -I I> This rule let the echo request out and the resulting TTL exceeded I> was matched and allowed back in. I> I> pass out inet proto icmp from to any icmp-type echoreq I> I> I've had to change the rule to the following to keep traceroute going: I> I> pass out inet proto icmp from to any This is probably related to r257223. Baptiste, any ideas? Ian, is it possible to reproduce this on a single host? What pf.conf and traceroute command are required? -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [patch] Source entries removing is awfully slow.
Kajetan,
On Mon, Dec 02, 2013 at 05:28:57PM +0100, Kajetan Staszkiewicz wrote:
K> > On Sun, Dec 01, 2013 at 08:05:54PM +0100, Kajetan Staszkiewicz wrote:
K> > K> > Ok. Let's summurize what we need to:
K> > K> >
K> > K> > 1) Switch kill|reset, that affects both -K and -k.
K> > K> > 2) Add option to -K that would kill states.
K> > K> > 3) Add option to -K and -k to specify that argument is a table.
K> > K> > 4) Try not to add new global option keys.
K> > K> >
K> > K> > What we got:
K> > K> >
K> > K> > 1) -k supports specifying that argument is label or id. This is done
K> > via K> > multiple -k specifiers:
K> > K> >
K> > K> >pfctl -k id -k 4823e8450003
K> > K> >
K> > K> > 2) -K and -k can be specified twice, meaning -k source -K destination.
K> > K> >
K> > K> > So, 1) and 2) make order of multiple arguments important.
K> > K> >
K> > K> > The main problem is that we need to keep working current syntax, which
K> > I K> > find ugly. The biggest problem is that order of arguments matters.
K> > This is K> > really a bad habbit.
K> > K> >
K> > K> > What about if we come with something order-agnostic as alternative to
K> > K> > current syntax? And put all enhanced state/srcnode killing/resetting
K> > into K> > this new syntax, w/o touching current syntax. The current syntax
K> > will be K> > mark as obsoleted in manual page. We might even want to
K> > implement all K> > these new features in a new utility. Not sure there is
K> > a reason to do, so K> > but is possible.
K> > K>
K> > K> I believe it is possible to extend the current syntax without breaking
K> > K> compatibility. Have a look:
K> > K> - A list of -K string1 -K string2... is provided.
K> > K> - Magic keywords are: label, id, table, rdrhost, kill ("states",
K> > K> "rststates").
K> > K> - If there is a magic keyword at any position, the next position is a
K> > value for K> the keyword.
K> > K> - If there is a string, which is not a magic keyword, at any position,
K> > it is K> src host or dst host, depending on position (first is src, next
K> > is dst). K> - Of course not all keywords apply both to -K and -k (e.g
K> > state's rdrhost is K> src_node's dst).
K> > K>
K> > K> This is:
K> > K> - Compatible with the current syntax.
K> > K> - Extends the syntax to my needs.
K> > K> - By coincidence extedns the syntax for matching by multiple keywords +
K> > src/dst K> at once. Kernel should already handle that, pfctl.c needs to
K> > be changed. K>
K> > K> It can be extended with more magic keywords: srchost, dsthost. This
K> > would make K> order of tuples (-K keyword -K value) fully obsolete.
K> > K>
K> > K> How do you find the idea?
K> >
K> > Well, that would work. I just dislike the current syntax order dependant:
K> >
K> > '-K foo -K bar' isn't equal to '-K bar -K foo'
K> >
K> > But compatibility issue can overweight saneness.
K>
K> Do we have an agreement then? Shall I start developing this?
I won't object on any interface that is consistent and resides in the
'-K' and '-k' namespace. As said before, I am against utilizing new
letters for options to avoid clashing with pfctl syntax in OpenBSD.
Thank you.
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: VIMAGE + PF crashes - possible solutions
On Wed, Oct 16, 2013 at 09:16:43AM +0200, Martin Matuska wrote:
M> Hi, I have encountered the same mtag panic Craig had with VIMAGE + PF
M> and have reported this in a PR 182964:
M> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182964
M>
M> Here are two possible solutions I would like to discuss, both make the
M> panic go away:
M>
M> 1.) de-virtualize the variable as Marco suggested, this solution is a
M> more intrusive change to pf.c
M> http://people.freebsd.org/~mm/patches/pf_mtag.patch
M>
M> 2.) add vnet context to struct m_tag, this is less intrusive to pf.c and
M> the uma zone remains virtualized:
M> http://people.freebsd.org/~mm/patches/pf_mtag.2.patch
M>
M> Which of the approaches should we take or is this to be solved in a
M> completely different way?
As I already said, both patches look incorrect. The correct way
is to separate things we want to be global, and things that we want
to be V. Then, put the latter on SYSINIT_VNET().
There is work in progress on that by Nikos. Unfortunately, he is now
very busy with real life and his hacking is on hiatus. You can find
his WIP patches in attachments. Although they aren't finished, the
way is correct.
I also checked in some of his code into projects/pf:
http://svnweb.freebsd.org/base?view=revision&revision=251993
--
Totus tuus, Glebius.
Index: sys/net/pfvar.h
===
--- sys/net/pfvar.h (revision 251294)
+++ sys/net/pfvar.h (working copy)
@@ -901,7 +901,6 @@
struct pf_ruleset *, struct pf_pdesc *, int);
extern pflog_packet_t *pflog_packet_ptr;
-#define V_pf_end_threads VNET(pf_end_threads)
#endif /* _KERNEL */
#define PFSYNC_FLAG_SRCNODE 0x04
Index: sys/netpfil/pf/pf.c
===
--- sys/netpfil/pf/pf.c (revision 251294)
+++ sys/netpfil/pf/pf.c (working copy)
@@ -300,8 +300,6 @@
int in4_cksum(struct mbuf *m, u_int8_t nxt, int off, int len);
-VNET_DECLARE(int, pf_end_threads);
-
VNET_DEFINE(struct pf_limit, pf_limits[PF_LIMIT_MAX]);
#define PACKET_LOOPED(pd) ((pd)->pf_mtag && \
@@ -359,15 +357,13 @@
SYSCTL_NODE(_net, OID_AUTO, pf, CTLFLAG_RW, 0, "pf(4)");
-VNET_DEFINE(u_long, pf_hashsize);
-#define V_pf_hashsize VNET(pf_hashsize)
-SYSCTL_VNET_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN,
-&VNET_NAME(pf_hashsize), 0, "Size of pf(4) states hashtable");
+u_long pf_hashsize;
+SYSCTL_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN,
+&pf_hashsize, 0, "Size of pf(4) states hashtable");
-VNET_DEFINE(u_long, pf_srchashsize);
-#define V_pf_srchashsize VNET(pf_srchashsize)
-SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN,
-&VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable");
+u_long pf_srchashsize;
+SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN,
+&pf_srchashsize, 0, "Size of pf(4) source nodes hashtable");
VNET_DEFINE(void *, pf_swi_cookie);
@@ -698,12 +694,12 @@
struct pf_srchash *sh;
u_int i;
- TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &V_pf_hashsize);
- if (V_pf_hashsize == 0 || !powerof2(V_pf_hashsize))
- V_pf_hashsize = PF_HASHSIZ;
- TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &V_pf_srchashsize);
- if (V_pf_srchashsize == 0 || !powerof2(V_pf_srchashsize))
- V_pf_srchashsize = PF_HASHSIZ / 4;
+ TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &pf_hashsize);
+ if (pf_hashsize == 0 || !powerof2(pf_hashsize))
+ pf_hashsize = PF_HASHSIZ;
+ TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &pf_srchashsize);
+ if (pf_srchashsize == 0 || !powerof2(pf_srchashsize))
+ pf_srchashsize = PF_HASHSIZ / 4;
V_pf_hashseed = arc4random();
@@ -717,11 +713,11 @@
V_pf_state_key_z = uma_zcreate("pf state keys",
sizeof(struct pf_state_key), pf_state_key_ctor, NULL, NULL, NULL,
UMA_ALIGN_PTR, 0);
- V_pf_keyhash = malloc(V_pf_hashsize * sizeof(struct pf_keyhash),
+ V_pf_keyhash = malloc(pf_hashsize * sizeof(struct pf_keyhash),
M_PFHASH, M_WAITOK | M_ZERO);
- V_pf_idhash = malloc(V_pf_hashsize * sizeof(struct pf_idhash),
+ V_pf_idhash = malloc(pf_hashsize * sizeof(struct pf_idhash),
M_PFHASH, M_WAITOK | M_ZERO);
- V_pf_hashmask = V_pf_hashsize - 1;
+ V_pf_hashmask = pf_hashsize - 1;
for (i = 0, kh = V_pf_keyhash, ih = V_pf_idhash; i <= V_pf_hashmask;
i++, kh++, ih++) {
mtx_init(&kh->lock, "pf_keyhash", NULL, MTX_DEF);
@@ -735,9 +731,9 @@
V_pf_limits[PF_LIMIT_SRC_NODES].zone = V_pf_sources_z;
uma_zone_set_max(V_pf_sources_z, PFSNODE_HIWAT);
uma_zone_set_warning(V_pf_sources_z, "PF source nodes limit reached");
- V_pf_srchash = malloc(V_pf_srchashsize * sizeof(struct pf_srchash),
+ V_pf_srchash = malloc(pf_srchashsize * sizeof(struct pf_srchash),
M_PFHASH, M_WAITOK|M_ZERO);
- V_pf_srchashmask = V_pf_srchashsize - 1;
+ V_pf_srchashmask = pf_srchashsize - 1;
for (i = 0, sh = V_pf_srchash; i <= V_pf_srchashmask; i++, sh++)
mtx_init(&sh->lock, "pf_srchash"
Re: De-virtualize V_pf_mtag_z to eliminate kernel panics.
Craig, right now Nikos Vassiliadis is working on vimaging the pf properly. I'd leave decision on whether pf mtag zone should be V or not to him. He is now a bit busy with real life, so patching pf is on hiatus. I hope he will continue soon. P.S. The patch in the first mail isn't correct, as Marko explained. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: pftop/10.x
On Wed, Jun 26, 2013 at 11:40:16AM +0200, Fleuriot Damien wrote: F> > It isn't compilable on 10.x, so I guess you are running binary F> > compiled on 9.x. F> > F> > I have a WIP to make it compilable, which ended in rewriting it for a F> > bit more than a half. :) I need someone to finish the WIP and we F> > will probably supply a different distfile for 10.x. F> F> F> FreeBSD nas.my.gd 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r251489: Mon Jun 24 11:57:55 UTC 2013 F> F> # pkg info | grep pf F> pftop-0.7_1Utility for real-time display of statistics for pf F> F> Built just today on -CURRENT , works like a charm. Whoa! Thanks go to Fabian Keil! http://svnweb.freebsd.org/ports?view=revision&revision=318433 -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: pftop/10.x
On Wed, Jun 26, 2013 at 01:42:45PM +0600, Eugene M. Zheganin wrote: E> Why I'm getting this ? E> E> [emz@taiga:/<1>log/squid]# pftop E> pftop: DIOCGETSTATUS: Permission denied E> > Error Reading status (DIOCGETSTATUS): Permission denied E> E> (I'm kinda root). E> E> This is harmless (never used pftop, was just curious about it), but E> still worth fixing. It isn't compilable on 10.x, so I guess you are running binary compiled on 9.x. I have a WIP to make it compilable, which ended in rewriting it for a bit more than a half. :) I need someone to finish the WIP and we will probably supply a different distfile for 10.x. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: PF bugs
Peter, On Sat, Jun 22, 2013 at 02:59:57PM +0200, Peter N. M. Hansteen wrote: P> > Ok. I wish PF on FreeBSD and OpenBSD were in sync. P> P> With the differences in release schedules (OpenBSD releases N.m+1 P> every six months, while the FreeBSD cycles typically take longer) a P> total sync is unlikely, but it would save some of us a bit of P> maintenance work if FreeBSD finally made the jump to post-OpenBSD 4.7 P> syntax and various 4.5 and onwards goodies like match, pflow and a few P> other. The number of people who run both OpenBSD and FreeBSD is signficantly less then number of people who just run FreeBSD and routinely upgrade it from version to version. I understand that having different syntax is a PITA for those who run both BSDs, sorry for that. But changing syntax in FreeBSD would be PITA for a vast majority of people. That's why many FreeBSD developers are against changing syntax. P> Also, the new queueing subsystem that's now likely to be in OpenBSD P> 5.5 (to be released May 1st 2014) is likely to be a major feature that P> I think FreeBSD will want to include as soon as doable. While OpenBSD changes struct ifqueue if_snd in the ifnet to if_snd[nqueues], FreeBSD moves in the direction of killing the queue. The queue has showed itself as the major bottleneck for high speed interfaces, and now in FreeBSD all gigabit and 10gig NIC drivers bypass the ifqueue, it is left only for compatibility. That's why we don't plan to move back to queues. >From my viewpoint the best send scheduling method in the modern world is utilize multiqueueing that NICs provide. Most high end NICs now do. We just need some hardware abstraction layer upon that. Right now Andre Oppermann is planning a major work on the TX side of NIC drivers, and I'm pretty sure, he will consider traffic prioritisation. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Was Re: PF bugs now PF reporting utility
Cameron, On Sun, Jun 23, 2013 at 04:22:54PM +1000, Cameron Simpson wrote: C> On 23Jun2013 00:55, Nikos Vassiliadis wrote: C> | Things are just different for quite a while now and they are growing C> | even more differently. C> C> Just a small related thing: are underlying things compatible? Specificly I am C> wondering can I CARP and pfsync between FreeBSD and OpenBSD? Newer OpenBSD utilises additional field in CARP PDU, that isn't filled, neither analyzed by FreeBSD. After quick reading of OpenBSD CARP code, it seems that it should interoperate fine with older CARP from OpenBSD, and thus with CARP in FreeBSD. Note that in FreeBSD 10 the way CARP is configured has changed a lot, but the wire protocol is the same. Regarding pfsync. It is wire compatible with the version of the last import from OpenBSD. And last time I looked into OpenBSD (a year ago), it was still wire compatible. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: de-virtualize pf sysctls
On Sun, Jun 16, 2013 at 01:13:55PM +0200, Nikos Vassiliadis wrote: N> >>> Please review this patch. These two variables are RO-tunables and N> >>> cannot be changed at runtime. As such, it is not useful to N> >>> virtualize them. N> > N> > This looks correct to me. Also, it looks like V_pf_hashmask and N> > V_pf_srchashmask can be de-virtualized then. N> N> Yes, taken care of on this version. I am not sure if I placed N> properly pf_hashmask and pf_srchashmask in pfvar.h. N> N> Please review, thanks. Thanks, Nikos. I committed the patch to the branch projects/pf/head. Can you please check out this branch and generate further pf+vimage related diffs against it? Once we finish and stabilize it, I will merge the branch to head. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: pf + vimage patch
On Thu, Jun 06, 2013 at 03:24:10PM +0300, Mikolaj Golub wrote: M> > >> -VNET_DEFINE(u_long, pf_srchashsize); M> > >> -#defineV_pf_srchashsizeVNET(pf_srchashsize) M> > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, M> > >> -&VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); M> > >> +u_long pf_srchashsize; M> > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, M> > >> +&pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); M> > >> M> > > M> > > Why do you have to devirtualize these variables? Are per vnet M> > > hashtables sizes not useful or do they cause issues? M> > M> > Per VNET variables are not useful for pf_hashsize and pf_srchashsize M> > since these values are RO and cannot be modified at runtime. M> M> Indeed. I missed RDTUN flag. M> M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? M> M> I don't think Gleb will be happy with this. Some time ago he removed M> some vimage related stuff to prevent crashing on module unload (see M> r229849). Actually your patch looks like a partial revert of that M> commit. So I think you need to think about this issue from start. At M> least it should not crash non-vimage kernel and there should be M> understanding how to fix it for vimage kernel. Your approach with M> keeping only one purge thread might make it simpler. True. It is very much appreciated that you are working on vimage + pf, but breaking module unload isn't an option. When hacking on a part of kernel, having a possibility to avoid a reboot after each compile is very important. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Wed, Nov 21, 2012 at 03:44:13PM +0100, Ermal Lu?i wrote: E> Cherry-picking would be when tehre is reasonable similarities. E> Also another argument to do this would be simplicity on locking as well as E> i told you when you started the changes. You were wrong. OpenBSD doesn't move towards SMP model. Locking more recent pf is not simplier, but the opposite. E> Though i am open to work together on this to merge the new syntax thorugh a E> whole bulk merge rather than cherry-pick. How many bugs have you closed after the previous bulk import? Why should we expect anything good from new import if the previous one was a PITA? And still I don't see any answer on the question: what exact features or perfomance improvements are we going to obtain from "the new pf"? E> You already have 'broken' some functionality as if-bound in FreeBSD 10.x so Is there any PR filed on that? I didn't even receive a mail about that. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
Mark, On Tue, Nov 20, 2012 at 03:43:17PM +0100, Mark Martinec wrote: M> For one thing, I'm desperately awaiting NAT64 support (the 'af-to' M> translation rule in newer pf (5.1?), committed on 2011-10). Backport this exact feature to FreeBSD and send patch. M> Other: packet normalization (scrub) has been reworked and simplified, M> and is now a rulset option. Considering that scrub is currently broken M> (9.1, see list of PF bugs in FreeBSD), along with several other M> bugs that need fixing, it seems the (scarce) manpower would better M> be spent in moving on, than keeping the already leaky (buggy) pf M> afloat. Yes, scrub improvements can be cherry picked and added to FreeBSD, too. But if you think that bulk import of new version would close all current bugs without opening new problems, then you are mistaking. Last bulk import introduced much more bugs than it closed. And this statement isn't a accusation towards the person who did the import. This is just a generic rule. If you take 100k lines of code that were developed for another operating system kernel and without thourough reviewing it just make it compile and link with another kernel, then you are about to miss many rough edges that will show up later, when the code would be utilized. Thus, cherry-picking is preferred over bulk imports. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/173659: PF fatal trap on 9.1 (taskq fatal trap on pf_test_rule)
The following reply was made to PR kern/173659; it has been noted by GNATS. From: Gleb Smirnoff To: bug-follo...@freebsd.org Cc: Subject: Re: kern/173659: PF fatal trap on 9.1 (taskq fatal trap on pf_test_rule) Date: Mon, 19 Nov 2012 14:13:23 +0400 Since Patricks mail server bounces my mail, try to communicate via GNATS. - Forwarded message from Gleb Smirnoff - Date: Sun, 18 Nov 2012 01:59:58 +0400 From: Gleb Smirnoff To: Patrick Tracanelli Subject: Re: kern/173659: PF fatal trap on 9.1 (taskq fatal trap on pf_test_rule) User-Agent: Mutt/1.5.21 (2010-09-15) Patrick, couple of questions on the problem report: 1) Do you have ability to test FreeBSD 10 in the same conditions? pf in 10 differs much from 9. 2) Can you please send me pf rulesets? 3) Can you please provide the below info from the crash dump: P> #7 0x81525888 in pf_addrcpy (dst=0xfe0013942918, src=0x10, P> af=2 '\002') at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:522 P> #8 0x8152fdbf in pf_test_rule (rm=0xff80002e5848, P> sm=0xff80002e5840, direction=1, kif=0xfe0004c9e000, P> m=0xfe0004febd00, off=20, h=0xfe0013331010, P> pd=0xff80002e5780, am=0xff80002e5850, rsm=0xff80002e5838, P> ifq=0x0, inp=0x0) P> at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:3900 P> #9 0x815c in pf_test (dir=1, ifp=Variable "ifp" is not available. P> ) P> at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6884 P> #10 0x8153a9eb in pf_check_in (arg=Variable "arg" is not available. P> ) P> at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:4131 (kgdb) frame 8 (kgdb) info locals -- Totus tuus, Glebius. - End forwarded message - -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: pf synproxy slowdown
On Fri, Nov 09, 2012 at 05:40:16AM +, Anders N. wrote: A> Hi. I've got a server running pf that has been displaying some odd (at least to me) behavior. A> A> I use the "synproxy state"[1] option quite a few times in my config without any ill effects that I've noticed until now. I realized it was on every open port except for ssh, so I added it to my ssh line: A> A> pass in on $ext_if proto tcp from any to $IP port 22 flags S/SA synproxy state A> A> After doing so, scp/sftp/rsync have all slowed down to a crawl! I get ~1/4th the speed I usually do from the server with it enabled there. Remove it, speed goes back to normal. I'm using synproxy state with some other other services that send large amounts of data very quickly (http, torrents, etc) and none of them exhibit this slowdown, so I'm wondering why scp is so slow with it. Here's the rest of my pf.conf, if it matters: This is because synproxy module doesn't know which TCP extensions does the backend TCP stack supports, thus announces none to the remote peer. Connection created via synproxy rule will not support neither window scaling, nor SACK, nor timestamps. Obviously, this results in bad performance. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: svn commit: r240646 - head/sys/contrib/altq/altq
Ermal, On Wed, Sep 19, 2012 at 09:42:47PM +0200, Ermal Lu?i wrote: E> > On Tue, Sep 18, 2012 at 06:02:06PM +0200, Ermal Lu?i wrote: E> > E> The issue is that this hides the problem per se. E> > E> > What had hidden problem per se, was the following code: E> > E> > PF_UNLOCK(); E> > error = altq_add(a2); E> > PF_LOCK(); E> > E> > That's what we have in stable/9. E> > E> > E> The ioctl and pfctl loading of ruleset is not ready for handling failures here! E> > E> > They do. Error from altq_add() is returned by pf_ioctl() as response E> > to DIOCADDALTQ command. The code in pfctl, which does DIOCADDALTQ also E> > is handling errors. E> E> The issue is that you will fail a ruleset loading now that before E> could not fail. Before you could just race with some other thread modifing ALTQ, for example ifnet departure/attachment event, which would lead to panic. E> You need to teach pfctl that is ok if ALTQ ruleset load fails now, no? E> E> I think the most important thing in ruleset loading is the rules than E> comes ALTQ. E> Since ALTQ failure is tolerable and the risk from that faling is low! E> Its better to do a best effort loading of ruleset E> and just report where it failed? Configuring rulesets also does a lot of malloc(9) that can fail. Thus, if ALTQ configuration failed due to malloc(9) failure, then probably ruleset loading would fail, too. Usually, if system is low on kernel memory, most things won't work at all. So this isn't a case that should be optimized right now. If ruleset configuration would be refactored to a state when first all malloc()s are issued with M_WAITOK flag and only then rules lock is acquired, then we can get back to achieving same functionality for ALTQ. E> You just committed a 'questionable' patch for default block, just for E> security, though E> break that contract by making security depend on unpredictable behaviour! If you ponder this a second longer then you'll see, that default to block policy actually makes security depend less on unpredictable behavior: if anything goes wrong during boot, then a box is closed. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: svn commit: r240646 - head/sys/contrib/altq/altq
Ermal, On Tue, Sep 18, 2012 at 06:02:06PM +0200, Ermal Lu?i wrote: E> The issue is that this hides the problem per se. What had hidden problem per se, was the following code: PF_UNLOCK(); error = altq_add(a2); PF_LOCK(); That's what we have in stable/9. E> The ioctl and pfctl loading of ruleset is not ready for handling failures here! They do. Error from altq_add() is returned by pf_ioctl() as response to DIOCADDALTQ command. The code in pfctl, which does DIOCADDALTQ also is handling errors. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Patch for adding "options PF_DEFAULT_TO_DROP" to kernel configuration file
On Thu, Sep 13, 2012 at 11:26:48PM +0200, Olivier Cochard-Labb? wrote: O> Hi, O> here is a little patch (tested on FreeBSD 9.1-RC1) that add a new O> option to the kernel configuration file: O> options PF_DEFAULT_TO_DROP O> O> Without this option, with an empty pf.conf: All traffic are permit. O> With this option enabled, with an empty pf.conf: All traffic are O> dropped by default. O> O> If the attached file is removed, you can found the patch here: O> http://www.freebsd.org/cgi/query-pr.cgi?pr=171622 I'd appreciate if you re-submit your patch with: - update to the fresh head/, where pf has been moved to netpfil/pf - mentioning new option in pf(4) -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [HEADS UP] merging projects/pf into head
On Wed, Sep 12, 2012 at 12:41:54PM +0200, Ian FREISLICH wrote: I> Gleb Smirnoff wrote: I> > [announce goes both to net@ and pf@, but any discussion should I> >go on on p...@freebsd.org only, please] I> > I> > As you already may now, last half a year I've been working on I> > making pf SMP-scalable and faster in general. More info can be I> > found here: I> I> I've had your code running in production for the last few days. I> Sadly, HEAD is a little unstable and the system panics after about I> 1 hour of use. I> I> Fatal trap 12: page fault while in kernel mode I> cpuid = 9; apic id = 09 I> fault virtual address = 0x28 I> fault code = supervisor read data, page not present I> instruction pointer = 0x20:0x802d9ff1 I> stack pointer = 0x28:0xff84626540b0 I> frame pointer = 0x28:0xff8462654110 I> code segment= base 0x0, limit 0xf, type 0x1b I> = DPL 0, pres 1, long 1, def32 0, gran 1 I> processor eflags= interrupt enabled, resume, IOPL = 0 I> current process = 11 (irq257: bce1) I> trap number = 12 I> panic: page fault I> cpuid = 9 I> KDB: stack backtrace: I> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a I> panic() at panic+0x1ce I> trap_fatal() at trap_fatal+0x290 I> trap_pfault() at trap_pfault+0x210 I> trap() at trap+0x2b4 I> calltrap() at calltrap+0x8 I> --- trap 0xc, rip = 0x802d9ff1, rsp = 0xff84626540b0, rbp = 0xff I> 8462654110 --- I> pf_anchor_node_RB_NEXT() at pf_anchor_node_RB_NEXT+0x1 I> pf_test_rule() at pf_test_rule+0x4d7 I> pf_test() at pf_test+0x2b28 I> pf_check_in() at pf_check_in+0x26 I> pfil_run_hooks() at pfil_run_hooks+0x9e I> ip_fastforward() at ip_fastforward+0x1b9 I> ether_demux() at ether_demux+0x17e I> ether_nh_input() at ether_nh_input+0x24b I> netisr_dispatch_src() at netisr_dispatch_src+0x212 I> ether_demux() at ether_demux+0x6c I> ether_nh_input() at ether_nh_input+0x24b I> netisr_dispatch_src() at netisr_dispatch_src+0x212 I> bce_intr() at bce_intr+0x47a Panicing in the ruleset parsing is strange. Do you have modifications to the ruleset at run time? I> The crashdump is useless however: Strange that dump is bad. Is pf compiled into kernel or loaded? However, try to look at traces of other threads in this dump. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [CFT] SMP-friendly pf
On Tue, Sep 11, 2012 at 04:21:14PM +0400, Gleb Smirnoff wrote: T> 1) Install pfvar.h: T> T> cat /usr/src/sys/contrib/pf/net/pfvar.h > /usr/include/pfvar.h Typo. Should've been: cat /usr/src/sys/contrib/pf/net/pfvar.h > /usr/include/net/pfvar.h -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [CFT] SMP-friendly pf
On Tue, Sep 11, 2012 at 02:22:39PM +0300, Oguz Yilmaz wrote: O> Ok. We go thru head. O> We compiled the kernel and boot into 10.0 O> FreeBSD 10.0-CURRENT #0 r240350 O> O> # pfctl -sr O> No ALTQ support in kernel O> ALTQ related functions disabled O> pfctl: DIOCGETRULES: Permission denied O> ]# pfctl -si O> No ALTQ support in kernel O> ALTQ related functions disabled O> pfctl: DIOCGETSTATUS: Permission denied O> O> This Permission Denied issues should be old pfctl. O> O> Now, how can we compile pfctl and snmp_pf without make world? You really should go with make world, because no one guarantees that head/ branch would work with mismatching world and kernel. However answer for your question is: 1) Install pfvar.h: cat /usr/src/sys/contrib/pf/net/pfvar.h > /usr/include/pfvar.h 2) Rebuild and reinstall pfctl and snmp_pf cd /usr/src/sbin/pfctl make clean make make install cd /usr/src/usr.sbin/bsnmpd/modules/snmp_pf make clean make make install But I'd recommend doing full buildworld and keep your kernel and userland in sync. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
kern/124364: [pf] [panic] Kernel panic with pf + bridge
The following reply was made to PR kern/124364; it has been noted by GNATS. From: Gleb Smirnoff To: Vladimir Shapkin Cc: bug-follo...@freebsd.org Subject: kern/124364: [pf] [panic] Kernel panic with pf + bridge Date: Tue, 11 Sep 2012 14:51:06 +0400 Vladimir, have you tried to reproduce the problem on newer versions of FreeBSD? -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
kern/122014: [pf] [panic] FreeBSD 6.2 panic in pf
The following reply was made to PR kern/122014; it has been noted by GNATS. From: Gleb Smirnoff To: "Alexander V. Shulikov" Cc: bug-follo...@freebsd.org Subject: kern/122014: [pf] [panic] FreeBSD 6.2 panic in pf Date: Tue, 11 Sep 2012 14:49:22 +0400 Alexander, can the problem be reproduced on newer FreeBSD releases? -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [CFT] SMP-friendly pf
On Tue, Sep 11, 2012 at 12:18:23PM +0300, Oguz Yilmaz wrote: O> Hi Gleb, O> O> Is it required to build world? What is the shortest way to test? Yes, Ian answer is correct: kernel, pfctl and snmp_pf. Since you reply to an old email thread, let me note that the projects/pf branch had been merged to head. So you don't need to checkout the projects/pf anymore, just upgrade to fresh head. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [HEADS UP] merging projects/pf into head
On Fri, Sep 07, 2012 at 09:32:25AM -0700, Mark Atkinson wrote: M> On 09/05/2012 11:36, Gleb Smirnoff wrote: M> > What's bad with "getting stuck" with old syntax? I personally don't M> > have any problems with it. I have had problems with performance, M> > however. M> M> Just as an aside is there a decent set of stable web docs for M> FreeBSD's current syntax? I'm constantly burned when I try to looks M> something up (because it isn't working like I expect) and all I find M> is the new, sexy syntax with all it's quick 'match' operators and M> their ilk. I usually look at man pf.conf when I have problems with syntax. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [HEADS UP] merging projects/pf into head
Ermal, On Fri, Sep 07, 2012 at 10:02:47AM +0200, Ermal Lu?i wrote: E> > I won't keep OpenBSD-pf and FreeBSD-pf in parallel in FreeBSD. The OpenBSD-pf E> > port have proved to be poorly maintained. After last import that was made E> > by you, at least the following regressions were introduced: E> > E> > - enabling pfsync immediately panics E> > - kldunload pf.ko immediately panics E> > E> Going to personal attacks shows your willing to discuss as civilized person. E> Though that does not mean anything in the sense that bugs are there to E> be found by testers. Subtle and difficult to catch bugs are to be found by testers. Bugs that show up immediately after a subsystem had been started, shouldn't make their way to SVN. If I even agree with you that immediate crash on enabling pfsync should had been found not by you, but by a random FreeBSD-CURRENT user, then the next question would be: who is responsible to fix it? Let's look... A random user hits the panic and submits kern/159029. Who did fix that? Why not you? And here I am not picking at a certain exclusive bug that you missed. The bulk import of pf-4.5 was followed by dozens of bug fixes, most of which were done by bz@, pluknet@ and me. E> If you have not found out yet, testers for something that people take E> for granted as firewalls are scarce in general. Mistake. There are some people, who run my branch prior to its merge to head. More people then I expected. E> Something that has been learnt from history is that people want E> software X to be compatible with software Y from where it came from. E> They are not interested on X to use the same rules but hey its E> different from Y because of Z. From what I see, there is a another rule in FreeBSD. FreeBSD-N should be compatible not with OpenBSD-M, but with FreeBSD-(N-1). And idea to bring new syntax is breaking this rule. Haven't this been discussed before importing pf-4.5? E> > Hey, these aren't a difficult to catch bugs, that require special setup E> > or weeks of catching a race condition. This is basic functionality, and panics E> > are evidence that code wasn't tested properly. Okay, we all ain't saints, and E> > people do errors. But why wasn't you promptly fixing these errors? You just E> > dropped many Kb of code into SVN (via bz@) and then disappeared. Have you closed E> > at least on PR in GNATS? E> E> AFAIK i fixed any reported panics on freebsd-pf list. False. During the 9.0-RELEASE release cycle, linimon@ had thoroughly assigned all new pf bugs to freebsd-pf@ list. You took none of them. E> I did not even go the PR route because i had other plans which E> $DAYLIFE/WORK still have not allowed to pursue. E> Furthermore, there is nothing guaranteeing that you will not do the E> same, or have the same bugs in different fashion, i.e. VIMAGE/VNET?!. E> Just because you are doing work right now and are the only one behind E> these changes, AFAIK, does not mean its a long term partnership E> or that you will provide better SLA on this part. Agreed. I may go away from pf in future. But in this case I won't pretend that I'm still its maintainer and block other people willing to work. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [HEADS UP] merging projects/pf into head
Ermal, On Wed, Sep 05, 2012 at 10:09:23PM +0200, Ermal Lu?i wrote: E> Its good to see results on your work and is good moving forward. E> Claiming better behavior, under DoS or other comparison without showing any data E> or technical reason is a bit over this RFC. Benchmark by authors are always biased, thus I didn't boast about results. Much better if benchmarking is performed by someone else. If you insist here is some data: 1) Casting UDP flood of 400k states in this simple setup: [box A] -> [pf] -> [blackhole] On my particular box, head pf can forward 520 kpps and anything above is lost. SMP-pf can do 980 kpps. If we increase number of states, results would be more dramatic. If we make load bidirectional (which is the case in 99%) results would be more dramatic. Increasing number of rx/tx threads (more NICs, or more smart NICs) as well as increasing number of CPUs would make results even more dramatic. 2) DoSes Results are just empirical. At my job, when running old pf and encountering DoS attack, we usually notice that by bad web sites responsibility, customers complaining, etc. The box under attack is very unresponsive via ssh. With new SMP-pf a DoS may come in and if it doesn't consume entire bandwidth it can be noticed only post-factum when looking at monitoring plots. I'd appreciate if you perform benchmarking and testing. As said above, results from author are usually biased, but results from opponents more interesting. E> > 1) Move pf out of contrib. E> I do not see a reason behind this, any particular reason? It is no longer contributed source, but source developed by the FreeBSD project. E> > 2) Refactor the pfvar.h into pf.h and pf_var.h. Provide stable E> > kernel<->pfctl ABI. And probably other clean up tasks. E> Just this reason is a bit contradictory with 1) above! E> Let alone what does this mean to the user?! Nothing? E> They are after syntax stability, not breaking their machines on E> upgrade, ABI is nothing to them. Do you understand that "absense of stable ABI" == "breaking machines after upgrade"? Right now, the structures supplied via ioctl() include many fields that aren't related to API, but are internal kernel. Any internal kernel change breaks ABI. If new API structures are introduced, then we can do a lot of hacking on pf in 11.0-CURRENT with ability to safely merge changes to 10.0-STABLE. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [HEADS UP] merging projects/pf into head
Ermal, On Wed, Sep 05, 2012 at 10:02:17PM +0200, Ermal Lu?i wrote: E> as already shared with you the opinion the new 're-arrangement' of E> data structure together with new syntax E> is more helpful to SMP in general, so complementary to this work. E> As the person who has done most of the work on last import of pf form E> OpenBSD, so you E> can say knowledgeable about the internals of it, will still recommend E> the new syntax. E> - No more multiple rulesets is the single biggest reason. The new or old syntax is completely orthogonal to SMP. The SMP scalability is all about the storage, not about rulesets. I have looked into newer OpenBSD and their new pf modifies rulesets from the forwarding path more then pf-4.5 did, thus it is not "more helpful to SMP in general", but the opposite. E> > Bulk imports are no longer possible (unless one wants to ruin all my work). E> > We have had some pain with bulk imports. The last one, for example, have E> > broken pfsync completely. E> > E> > First, imports were made with focus on minimizing diff to OpenBSD. Code was E> > made compilable on FreeBSD and somehow working. But the operating systems have E> > diverged very much sincle last 15 years, and thus quality porting requires more E> > than just make it compile. For example, OpenBSD runs network stack under splnet(9). E> > They can run ip_output() anywhere in the network stack (except of ip_output() E> > itself, heh). We can't since that would make lock order reversals. This was just E> > one example, but believe me, there are much more. All this peculiarity were worked E> > out correctly in my branch. So, this branch is not about SMP scalability only, E> > this is a better port of pf to FreeBSD. E> > E> E> This is more a issue of FreeBSD rather than OpenBSD perse. E> pf(4) has survived with code sharing so far quite well and i have seen E> nothing in your project branch that does a better job to this. I'd prefer not survival for the pf, but robustness and performance :) Let me number the most important things in my project branch that do better job: - safely decoupled stack when sending generated packets: pf_send_tcp(), pf_send_icmp() - safely decoupled stack when sending pfsync(4) deferrals - safely removed the "pfugidhack" - provided correct locking in pf_route(), pf_route6() - offloaded the "flush" functionality to a taskqueue - removed unsafe lock dropping before malloc(9), or unsafe entering malloc(M_WAITOK) with locks held - removed unsafe lock dropping before copyin(9)/copyout(9) E> > Second, the imported code (what we have now in head) is polluted with zillions of E> > ifdefs and is difficultly readable even by the person who wrote it. Any other E> > developer runs away in fear when he faces that. This ends up with no one willing E> > to fix open problem reports. We have now 53 PR assigned to freebsd-pf@. They are E> > rotting and no one takes them. Most of these PRs can't be forwarded to OpenBSD, E> > since they are specific to our port (yep, port has problems - see above paragraph). E> > E> This is not an argument but just whining. E> Too much code in FreeBSD has that. "Too much code in FreeBSD has that" isn't an excuse either an argument. E> > >From my point of view the state of pf in FreeBSD is (was) a dead end. We don't E> > modify it, since it isn't ours, but we hope that new bulk import would fix problems. E> > E> > I hope that new state of pf in FreeBSD would attract more developers to it. I E> > have nothing against with cherry-picking new features from OpenBSD (but E> > taking into account new multithreaded design). I have nothing against completely E> > new features. I'd appreciate any attempt to reduce number of PRs assigned to E> > freebsd-pf@. E> > E> > T> Currently the common "pf-ecosystem" that we've always more-or-less E> > T> shared with OpenBSD seems to be crumbling. If we are going to continue E> > T> along our own "branch" of pf, with old syntax and SMP support, and who E> > T> knows what else in the future, should we consider renaming it to avoid E> > T> having two similar-but-not-identical firewalls with the same name ? E> > E> > May be it is worth renaming, I have nothing against this. But I don't E> > think it is already time to rename right now. Now the only rewritten part E> > is keys/states storage, all other code is shared with OpenBSD, however E> > touched a lot. E> E> I would suggest this, and always would be for this, E> since too much expected internal behavior has changed internally with E> what i have seen on your project branch. E> E> People can test the renamed version and have an option to roll back to E> the previous one. E> After all you are saying that its not pf yourself. I won't keep OpenBSD-pf and FreeBSD-pf in parallel in FreeBSD. The OpenBSD-pf port have proved to be poorly maintained. After last import that was made by you, at least the following regressions were introduced: - enabling pfsync immediately panics - kldunlo
Re: [HEADS UP] merging projects/pf into head
Thomas, On Wed, Sep 05, 2012 at 04:28:23PM +0200, Thomas Steen Rasmussen wrote: T> Your work seems very exciting from a performance standpoint, and it T> is certainty something I am looking forward to. Please don't take the T> following as a critique of your important work :) T> T> In your orignal announcement you confirmed my fears that this work T> will make our pf divert a lot from OpenBSDs pf, making bulk code-imports T> impossible in the future. As you know we are stuck on the old pf-syntax, T> how will we ever get to the new pf-syntax if your work goes into HEAD ? What's bad with "getting stuck" with old syntax? I personally don't have any problems with it. I have had problems with performance, however. Here you are advocating to a thesis that new => good, older => bad. If we believe this thesis, and focus on keeping up to date with OpenBSD, then we will spend zillions of manhours porting newer and newer and newer pf to FreeBSD, but we will always get the old one, because OpenBSD will be at least one minor revision ahead of us. This race can never be won. Samba will never become Windows :) However, if someone eagers to see new syntax in FreeBSD, I have nothing against this. Just sit down and port it. Yes, porting will require some time to understand code and quality port it to FreeBSD. Bulk imports are no longer possible (unless one wants to ruin all my work). We have had some pain with bulk imports. The last one, for example, have broken pfsync completely. First, imports were made with focus on minimizing diff to OpenBSD. Code was made compilable on FreeBSD and somehow working. But the operating systems have diverged very much sincle last 15 years, and thus quality porting requires more than just make it compile. For example, OpenBSD runs network stack under splnet(9). They can run ip_output() anywhere in the network stack (except of ip_output() itself, heh). We can't since that would make lock order reversals. This was just one example, but believe me, there are much more. All this peculiarity were worked out correctly in my branch. So, this branch is not about SMP scalability only, this is a better port of pf to FreeBSD. Second, the imported code (what we have now in head) is polluted with zillions of ifdefs and is difficultly readable even by the person who wrote it. Any other developer runs away in fear when he faces that. This ends up with no one willing to fix open problem reports. We have now 53 PR assigned to freebsd-pf@. They are rotting and no one takes them. Most of these PRs can't be forwarded to OpenBSD, since they are specific to our port (yep, port has problems - see above paragraph). >From my point of view the state of pf in FreeBSD is (was) a dead end. We don't modify it, since it isn't ours, but we hope that new bulk import would fix problems. I hope that new state of pf in FreeBSD would attract more developers to it. I have nothing against with cherry-picking new features from OpenBSD (but taking into account new multithreaded design). I have nothing against completely new features. I'd appreciate any attempt to reduce number of PRs assigned to freebsd-pf@. T> Currently the common "pf-ecosystem" that we've always more-or-less T> shared with OpenBSD seems to be crumbling. If we are going to continue T> along our own "branch" of pf, with old syntax and SMP support, and who T> knows what else in the future, should we consider renaming it to avoid T> having two similar-but-not-identical firewalls with the same name ? May be it is worth renaming, I have nothing against this. But I don't think it is already time to rename right now. Now the only rewritten part is keys/states storage, all other code is shared with OpenBSD, however touched a lot. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
[HEADS UP] merging projects/pf into head
Hi! [announce goes both to net@ and pf@, but any discussion should go on on p...@freebsd.org only, please] As you already may now, last half a year I've been working on making pf SMP-scalable and faster in general. More info can be found here: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html Since that announce in June, I've been running experimental code for more than 2 months in production on several routers. Also, some brave people volunteered to be beta-testers and also run the experimental branch in last couple of months. Code proved to be stable enough. The new code performs better in production: less CPU load, less jitter, more responsive system under high load. It performs better under synthetic benchmarks like random generated UDP flood. It performs much better when DoS comes in. Thus, I plan to merge projects/pf/head to head this weekend, and this is a HEADS UP email! You have been warned. :) What I'd like to do next: 1) Move pf out of contrib. 2) Refactor the pfvar.h into pf.h and pf_var.h. Provide stable kernel<->pfctl ABI. And probably other clean up tasks. ... 3) ... too far to build any plans, yet. :) -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [CFT] SMP-friendly pf
Hello, again. On Fri, Jun 08, 2012 at 10:17:37AM +0400, Gleb Smirnoff wrote: T> Three and a half months ago I've started on a project "SMP-friendly pf", T> which recently have entered alpha stage. As you see from the subject of this T> mail, this is call for testing. I'm bit disappointed that my announce get so little response. Anyway, here are some results from running in production. This time on a busy router, that got a noticable load during busiest hours. It has complex ruleset with almost 400 rules, 21 vlan(4) interfaces running on top of lagg(4) and serves about 30 subnets of different size. Some subnets are behind NAT, and some or simple routed. The router usually got somewhere between 20k to 60k states and 120k pf searches per second, with peaks up to 140k searches. It has 4 cores and runs igb(4) NICs. After migrating to experimental pf branch on, the CPU load during busiest hours has dropped significantly: http://people.freebsd.org/~glebius/pflock/pflock-migration.png A more recent pic (taken right now): http://people.freebsd.org/~glebius/pflock/pflock-migration2.png Each high peak is a working day (in Russia in June we have had a 6 day week followed by 3 day week). The thin red peak is buildworld+buildkernel, and after it the box was rebooted and since runs with SMP-friendly pf. As you may notice, after migration the working day peaks are much lower than before. Traffic volume is the same, I've checked this :) I hope these results would encourage someone to participate in early testing. :) -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [CFT] SMP-friendly pf
On Sat, Jun 09, 2012 at 03:14:42AM -0400, Chris Buechler wrote: C> > As you already probably know, or some may be don't yet know, the pf(4) C> > subsystem in FreeBSD is currently working under a single mutex. This mutex C> > is acquired right at the beginning of any packet processing, and is dropped C> > at the end. While one thread is in pf(4) all other threads are blocked on C> > that mutex. C> > C> > Meanwhile modern computers are getting more and more cores, and modern C> > network cards getting more MSI interrupts, each serviced by a separate kernel C> > thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :), is C> > getting a point of hard contention. C> > C> > Three and a half months ago I've started on a project "SMP-friendly pf", C> > which recently have entered alpha stage. As you see from the subject of this C> > mail, this is call for testing. C> > C> > Willing to test? C> C> Absolutely. Are there any particular areas specifically that you would C> like some testing focus on? Obviously testing everything is needed to C> ensure nothing is broken, and I'm definitely interested in doing some C> performance comparisons on SMP and non-SMP hardware. But not sure what C> areas you've already focused on, and what areas you feel need more C> testing focus than others, if any. I'm currently running it with quite simple rulesets with couple of rdr rules and that's all. - Testing with more complex rulesets is interesting. - Situations with rapidly changing rulesets or appearing and disappearing interfaces, or table entries are potentially dangerous once pf is no longer under one lock. - routing rules, uid/gid rules Performance increase could be probably noticed only at large state tables, probably > 100k, on box with several cores and several NICs, or with a NIC that runs multiple threads (igb(4) for example). -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: [CFT] SMP-friendly pf
Ermal, On Fri, Jun 08, 2012 at 12:39:43PM +0200, Ermal Lu?i wrote: E> On Fri, Jun 8, 2012 at 8:17 AM, Gleb Smirnoff wrote: E> As i already asked in private wihtout a documentation/schema E> describing how you protect the various elements in pf(4) this is very E> hard to review. As I already replied, one should read commit logs as well as some details there are in the email you were replying to. E> - What do you do to allow correctness on statistics? Nothing. Statistics are not precise in the SMP-friendly pf. This is an issue for all counters in our networking stack - counters on ifnets, in ipfw, many others. Using atomic operations to keep them precise is too expensive. We need some solution to make cheap and precise counters. I think this should pcpu data. I already did made some tests proving the effectiveness of this approach. However, to get this to a commitable state I need help from some seniour kernel developers. Anyway cheap+precise counters should be discussed in separate thread. E> - What do you with tables protection, are they under same lock as rules...? Yes, and this was mentioned in the mail you are replying to. E> - How is if-bound versus floating states maintained? Nothing changed for them. Should there be something tricky? E> - What is protecting scrub ruleset? E> - What is protecting nat ruleset? Same lock as rules. I suppose that is quite clear from my mail. E> - How you solved synproxy ? Is it scalable? You know how I solved it, you even commented on that commit: http://lists.freebsd.org/pipermail/svn-src-projects/2012-April/005056.html Can you please explain your concerns on scalability of the approach taken? E> - Do you think you have introduced possiblity of security issues with E> taskqueues you introduce? Can you please explain what security issues do you see in taskqueue? E> There are many how? in this implementation that are difficult to see E> without you telling! I am open to questions. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
[CFT] SMP-friendly pf
Hello, networkers! [net@ in Cc, but further discussion should go on pf@] As you already probably know, or some may be don't yet know, the pf(4) subsystem in FreeBSD is currently working under a single mutex. This mutex is acquired right at the beginning of any packet processing, and is dropped at the end. While one thread is in pf(4) all other threads are blocked on that mutex. Meanwhile modern computers are getting more and more cores, and modern network cards getting more MSI interrupts, each serviced by a separate kernel thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :), is getting a point of hard contention. Three and a half months ago I've started on a project "SMP-friendly pf", which recently have entered alpha stage. As you see from the subject of this mail, this is call for testing. Willing to test? The code lives in projects/pf/head branch in the SVN, and can be checked out with: svn checkout http://svn.freebsd.org/base/projects/pf/head pflock , where argument "pflock" is just directory name for checked out sources. Then you need to build world and kernel from that branch and install them. The branch projects/pf/head gets head merged to it quite often, so if you run head world with a revision equal (or at least close) to last merge, then you don't need to install world, however rebuilding pfctl and snmp_pf from that branch is necessary. If you are about to run this alpha pf on any important box, then you definitely need to establish safety measures: have a second box running stable/9 or head as carp(4) backup, ready to kick in, in case if new pf panics. pfsync(4) connection should also be established between new and backup boxes. pfsync(4) in the new code is wire compatible with stable/9 or head. I'm already running it on routers with 100k - 200k state entries, and forwarding 20k - 40k pps. If you are brave, you should try, too :) Good luck and report any problems to me! Interested in details? From the very beginning of the project it was clear, that code is going to diverge significantly from original OpenBSD code. OpenBSD has always developed pf without taking into account that code can ever get multithreaded, thus quite a lot needed to be changed. Thus, I've started with removing the "#ifdef __FreeBSD__" from the code, and later I didn't hesitate even a fraction of second if I wanted to toss some code. The pros is that now code is much more readable and understandible then in head, the cons is that diff between us and OpenBSD is huge, although amount of shared code is huge, too. So, later on only manual merging of features from OpenBSD is possible and bulk imports of entire pf into FreeBSD are no longer possible. The locking scheme is the following: - There is an rwlock(9) that protects rules and all kind of data that isn't modified by forwarding threads. Forwarding threads reader lock it, ioctl() and other reconfiguring events write lock it. - The states and key states storage had moved from RB-trees to hashes, with separate mutexes per hash slot. This should give us decent parallelism when forwarding packets. - Source nodes storage moved to hash with per-slot locking. - pfsync(4) got separate mutex. - fragment reassembly got separate mutex. Apart from the above key changes, many other optimisations and fixes done. The entire diff is 22k lines large. You can view the projects history here: http://svnweb.freebsd.org/base/projects/pf/head/?view=log (the beginning is on page 2 now, at r232042) I had tried to make informative commit messages. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
On Tue, Apr 17, 2012 at 04:32:31PM +, Bjoern A. Zeeb wrote: B> > On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote: B> > E> The only problem i might see is when running more than one firewall B> > E> together but still there are other issues when you do that at pfil(9) B> > E> level. B> > B> > Well, playing with two firewalls was never safe and clear, there always B> > be edge cases in such setups. B> B> A lot of people have used ipfw to filter L2 MAC addresses etc and pf for everything else in the past. So certainly is not an edge case. Enabling two firewalls isn't an edge case, but when two firewalls enabled there are numerouse possibilities to do evil misconfigurations. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
On Tue, Apr 17, 2012 at 12:46:08PM +0400, Gleb Smirnoff wrote: T> We can make the assignment like: T> T> if (ifp->if_flags & IFF_LOOPBACK) T> m->m_flags |= M_SKIP_FIREWALL; I've tested this plus MTAG_PERSISTENT on pf tags, and it looks like this works. At least for the "fastroute" case, which was defnitely not working before. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
Replying on only on paragrapg, everything else agreed. On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote: E> The only problem i might see is when running more than one firewall E> together but still there are other issues when you do that at pfil(9) E> level. Well, playing with two firewalls was never safe and clear, there always be edge cases in such setups. E> Also, if_simloop is not meant for packet leaving the host so that E> should be safe no? Shouldn't live, but it still enters pfil(9) and there one or other firewall can again bounce it in any direction. Probable M_SKIP_FIREWALL is good idea. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
On Tue, Apr 17, 2012 at 10:38:31AM +0200, Ermal Lu?i wrote:
E> 2012/4/17 Gleb Smirnoff :
E> > On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote:
E> > E> 2012/4/16 Gleb Smirnoff :
E> > E> > On Sun, Apr 15, 2012 at 12:00:21PM +, Gleb Smirnoff wrote:
E> > E> > T> On Sun, Apr 15, 2012 at 11:10:03AM +, Gleb Smirnoff wrote:
E> > E> > T> T> I have a vague suspicion on what is happening. Your
description of
E> > E> > T> T> the problem looks like if a packet processing in the kernel
has entered
E> > E> > T> T> an endless loop.
E> > E> > T> T>
E> > E> > T> T> Looking at pf_route() I see such possibility. From OpenBSD
we have
E> > E> > T> T> this protection against endless looping:
E> > E> > T> T>
E> > E> > T> T> if ((*m)->m_pkthdr.pf.routed++ > 3) {
E> > E> > T> T> m0 = *m;
E> > E> > T> T> *m = NULL;
E> > E> > T> T> goto bad;
E> > E> > T> T> }
E> > E> > T> T>
E> > E> > T> T> In our code this transforms to:
E> > E> > T> T>
E> > E> > T> T> if (pd->pf_mtag->routed++ > 3) {
E> > E> > T> T> m0 = *m;
E> > E> > T> T> *m = NULL;
E> > E> > T> T> goto bad;
E> > E> > T> T> }
E> > E> > T> T>
E> > E> > T> T> The root difference between storing the tag on mbuf and on
pfdesc
E> > E> > T> T> is that we lose pfdesc, and thus the tag, when we enter
pf_test()
E> > E> > T> T> recursively. And pf_route() does this recursion:
E> > E> > T> T>
E> > E> > T> T> if (oifp != ifp) {
E> > E> > T> T> if (pf_test(PF_OUT, ifp, &m0, NULL) !=
PF_PASS) {
E> > E> > T> T> goto bad;
E> > E> > T> T>
E> > E> > T>
E> > E> > T> On second look I see that my suspicion may not be true. In the
E> > E> > T> beginning of pf_test() we do pf_get_mtag() which preserves already
E> > E> > T> present tag if there is one.
E> > E> >
E> > E> > Further investigation showed that problem exist when route applied
E> > E> > ends in lo0, and packet passes to if_simloop(). There all mtags are
E> > E> > stripped from the mbuf, including the pf mtag. Then packet is again
E> > E> > processed by ip_input() again entering pf(4), if it again matches
E> > E> > a routing rule, then we got an endless loop.
E> > E> >
E> > E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
E> > E>
E> > E> That seems like the best fix for this case.
E> >
E> > In this case crash or freeze is fixed, but still packet is dropped. Example
E> > of such rule:
E> >
E> > pass in on igb0 fastroute proto tcp from any to $localip
E> >
E> > Anyway, dropping packets is much better than crashing.
E> >
E>
E> Actually after some coffee :) i think its better marking the packet
E> with M_SKIP_FIREWALL since
E> it has already taken its decision on this packet.
E>
E> The simloop consumers seem to be just facilities of how things work
E> from what i can see.
E>
E> So just delivering the packet by sending skipping the firewalls seems
E> more sensibile!
E>
E> Though the persistent case for the tags should be revisited since it
E> may fix some other issues with pf(4) tags, and some others.
We can make the assignment like:
if (ifp->if_flags & IFF_LOOPBACK)
m->m_flags |= M_SKIP_FIREWALL;
Because only loopback interface is special: processing its ifp->if_output()
leads to re-entering ip_input().
I'm afraid that if we mark all pf-routed packets as M_SKIP_FIREWALL, that
can lead to a case when packet is routed by pf processing on input hook, and
then it skips processing the output hook, and that can lead to state
not being updated and session stuck.
Still, I think that pf tag deserves MTAG_PERSISTENT. That would keep us
in-line with OpenBSD, since they store pf information right in the pkthdr,
and I don't think that they erase it anywhere until mbuf is freed.
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote:
E> 2012/4/16 Gleb Smirnoff :
E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
E> > T> On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
E> > T> T> I have a vague suspicion on what is happening. Your description
of
E> > T> T> the problem looks like if a packet processing in the kernel has
entered
E> > T> T> an endless loop.
E> > T> T>
E> > T> T> Looking at pf_route() I see such possibility. From OpenBSD we
have
E> > T> T> this protection against endless looping:
E> > T> T>
E> > T> T> if ((*m)->m_pkthdr.pf.routed++ > 3) {
E> > T> T> m0 = *m;
E> > T> T> *m = NULL;
E> > T> T> goto bad;
E> > T> T> }
E> > T> T>
E> > T> T> In our code this transforms to:
E> > T> T>
E> > T> T> if (pd->pf_mtag->routed++ > 3) {
E> > T> T> m0 = *m;
E> > T> T> *m = NULL;
E> > T> T> goto bad;
E> > T> T> }
E> > T> T>
E> > T> T> The root difference between storing the tag on mbuf and on pfdesc
E> > T> T> is that we lose pfdesc, and thus the tag, when we enter pf_test()
E> > T> T> recursively. And pf_route() does this recursion:
E> > T> T>
E> > T> T> if (oifp != ifp) {
E> > T> T> if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
E> > T> T> goto bad;
E> > T> T>
E> > T>
E> > T> On second look I see that my suspicion may not be true. In the
E> > T> beginning of pf_test() we do pf_get_mtag() which preserves already
E> > T> present tag if there is one.
E> >
E> > Further investigation showed that problem exist when route applied
E> > ends in lo0, and packet passes to if_simloop(). There all mtags are
E> > stripped from the mbuf, including the pf mtag. Then packet is again
E> > processed by ip_input() again entering pf(4), if it again matches
E> > a routing rule, then we got an endless loop.
E> >
E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
E>
E> That seems like the best fix for this case.
In this case crash or freeze is fixed, but still packet is dropped. Example
of such rule:
pass in on igb0 fastroute proto tcp from any to $localip
Anyway, dropping packets is much better than crashing.
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
On Sun, Apr 15, 2012 at 12:00:21PM +, Gleb Smirnoff wrote:
T> On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
T> T>I have a vague suspicion on what is happening. Your description of
T> T> the problem looks like if a packet processing in the kernel has entered
T> T> an endless loop.
T> T>
T> T>Looking at pf_route() I see such possibility. From OpenBSD we have
T> T> this protection against endless looping:
T> T>
T> T> if ((*m)->m_pkthdr.pf.routed++ > 3) {
T> T> m0 = *m;
T> T> *m = NULL;
T> T> goto bad;
T> T> }
T> T>
T> T> In our code this transforms to:
T> T>
T> T> if (pd->pf_mtag->routed++ > 3) {
T> T> m0 = *m;
T> T> *m = NULL;
T> T> goto bad;
T> T> }
T> T>
T> T> The root difference between storing the tag on mbuf and on pfdesc
T> T> is that we lose pfdesc, and thus the tag, when we enter pf_test()
T> T> recursively. And pf_route() does this recursion:
T> T>
T> T> if (oifp != ifp) {
T> T> if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
T> T> goto bad;
T> T>
T>
T> On second look I see that my suspicion may not be true. In the
T> beginning of pf_test() we do pf_get_mtag() which preserves already
T> present tag if there is one.
Further investigation showed that problem exist when route applied
ends in lo0, and packet passes to if_simloop(). There all mtags are
stripped from the mbuf, including the pf mtag. Then packet is again
processed by ip_input() again entering pf(4), if it again matches
a routing rule, then we got an endless loop.
We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
The following reply was made to PR kern/164402; it has been noted by GNATS.
From: Gleb Smirnoff
To: freebsd-pf@FreeBSD.org
Cc: bug-follo...@freebsd.org
Subject: Re: kern/164402: [pf] pf crashes with a particular set of rules when
first matching packet arrives
Date: Sun, 15 Apr 2012 15:51:24 +0400
On Sun, Apr 15, 2012 at 11:10:03AM +, Gleb Smirnoff wrote:
T>I have a vague suspicion on what is happening. Your description of
T> the problem looks like if a packet processing in the kernel has entered
T> an endless loop.
T>
T>Looking at pf_route() I see such possibility. From OpenBSD we have
T> this protection against endless looping:
T>
T> if ((*m)->m_pkthdr.pf.routed++ > 3) {
T> m0 = *m;
T> *m = NULL;
T> goto bad;
T> }
T>
T> In our code this transforms to:
T>
T> if (pd->pf_mtag->routed++ > 3) {
T> m0 = *m;
T> *m = NULL;
T> goto bad;
T> }
T>
T> The root difference between storing the tag on mbuf and on pfdesc
T> is that we lose pfdesc, and thus the tag, when we enter pf_test()
T> recursively. And pf_route() does this recursion:
T>
T> if (oifp != ifp) {
T> if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
T> goto bad;
T>
On second look I see that my suspicion may not be true. In the
beginning of pf_test() we do pf_get_mtag() which preserves already
present tag if there is one.
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
On Sun, Apr 15, 2012 at 11:10:03AM +, Gleb Smirnoff wrote:
T>I have a vague suspicion on what is happening. Your description of
T> the problem looks like if a packet processing in the kernel has entered
T> an endless loop.
T>
T>Looking at pf_route() I see such possibility. From OpenBSD we have
T> this protection against endless looping:
T>
T> if ((*m)->m_pkthdr.pf.routed++ > 3) {
T> m0 = *m;
T> *m = NULL;
T> goto bad;
T> }
T>
T> In our code this transforms to:
T>
T> if (pd->pf_mtag->routed++ > 3) {
T> m0 = *m;
T> *m = NULL;
T> goto bad;
T> }
T>
T> The root difference between storing the tag on mbuf and on pfdesc
T> is that we lose pfdesc, and thus the tag, when we enter pf_test()
T> recursively. And pf_route() does this recursion:
T>
T> if (oifp != ifp) {
T> if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
T> goto bad;
T>
On second look I see that my suspicion may not be true. In the
beginning of pf_test() we do pf_get_mtag() which preserves already
present tag if there is one.
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives
The following reply was made to PR kern/164402; it has been noted by GNATS.
From: Gleb Smirnoff
To: "Eugene M. Zheganin"
Cc: bug-follo...@freebsd.org
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
first matching packet arrives
Date: Sun, 15 Apr 2012 15:07:56 +0400
Hi,
I have a vague suspicion on what is happening. Your description of
the problem looks like if a packet processing in the kernel has entered
an endless loop.
Looking at pf_route() I see such possibility. From OpenBSD we have
this protection against endless looping:
if ((*m)->m_pkthdr.pf.routed++ > 3) {
m0 = *m;
*m = NULL;
goto bad;
}
In our code this transforms to:
if (pd->pf_mtag->routed++ > 3) {
m0 = *m;
*m = NULL;
goto bad;
}
The root difference between storing the tag on mbuf and on pfdesc
is that we lose pfdesc, and thus the tag, when we enter pf_test()
recursively. And pf_route() does this recursion:
if (oifp != ifp) {
if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
goto bad;
--
Totus tuus, Glebius.
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/114095: [carp] carp+pf delay with high state limit
The following reply was made to PR kern/114095; it has been noted by GNATS. From: Gleb Smirnoff To: Ermal Lu?i Cc: nerijus.ambra...@ktu.lt, freebsd-pf@FreeBSD.org, bug-follo...@freebsd.org Subject: Re: kern/114095: [carp] carp+pf delay with high state limit Date: Mon, 17 Oct 2011 23:13:48 +0400 On Mon, Oct 17, 2011 at 08:47:31PM +0200, Ermal Lu?i wrote: E> > This is a surprise for me that this feature had been removed! E> > E> > It used to be in stable/6: E> > E> > http://fxr.watson.org/fxr/ident?v=FREEBSD60;i=carp_suppress_preempt E> > E> > And I always treated that variable in CARP as shared with pf. Why did E> > they removed this feature from pfsync? E> E> OpenBSD has it but FreeBSD is SMP capable and global vars without E> synchronization do not work well. E> To support that you have to add cross-dependencies and synchronization E> between the two. E> E> Not only synchronization though even some housekeeping around E> I will probably give a look at this again after 9.0. Well, a possible race when pfsync clears its increment to carp_suppress_preempt but the CPU where carp callout is running doesn't notice it doesn't see it due to cache is harmless. It just mean that preemption would happen not right after pfsync has finished downloading states, but a couple of seconds later. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/114095: [carp] carp+pf delay with high state limit
On Mon, Oct 17, 2011 at 08:47:31PM +0200, Ermal Lu?i wrote: E> > This is a surprise for me that this feature had been removed! E> > E> > It used to be in stable/6: E> > E> > http://fxr.watson.org/fxr/ident?v=FREEBSD60;i=carp_suppress_preempt E> > E> > And I always treated that variable in CARP as shared with pf. Why did E> > they removed this feature from pfsync? E> E> OpenBSD has it but FreeBSD is SMP capable and global vars without E> synchronization do not work well. E> To support that you have to add cross-dependencies and synchronization E> between the two. E> E> Not only synchronization though even some housekeeping around E> I will probably give a look at this again after 9.0. Well, a possible race when pfsync clears its increment to carp_suppress_preempt but the CPU where carp callout is running doesn't notice it doesn't see it due to cache is harmless. It just mean that preemption would happen not right after pfsync has finished downloading states, but a couple of seconds later. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/114095: [carp] carp+pf delay with high state limit
The following reply was made to PR kern/114095; it has been noted by GNATS. From: Gleb Smirnoff To: Ermal Lu?i Cc: nerijus.ambra...@ktu.lt, freebsd-pf@FreeBSD.org, bug-follo...@freebsd.org Subject: Re: kern/114095: [carp] carp+pf delay with high state limit Date: Mon, 17 Oct 2011 17:17:42 +0400 On Mon, Oct 17, 2011 at 02:18:38PM +0200, Ermal Lu?i wrote: E> On Sat, Oct 15, 2011 at 4:20 PM, wrote: E> > Synopsis: [carp] carp+pf delay with high state limit E> > E> > State-Changed-From-To: open->closed E> > State-Changed-By: glebius E> > State-Changed-When: Sat Oct 15 14:20:00 UTC 2011 E> > State-Changed-Why: E> > Not a bug. This is a feature. pfsync(4) suppresses carp(4) E> > preemption until new recently booted node downloads full E> > table of pf(4) states from its peer. E> E> This is not true on FreeBSD. E> The issue might be from other reasons. This is a surprise for me that this feature had been removed! It used to be in stable/6: http://fxr.watson.org/fxr/ident?v=FREEBSD60;i=carp_suppress_preempt And I always treated that variable in CARP as shared with pf. Why did they removed this feature from pfsync? P.S. Since PR is about 6.2-RELEASE, then I have closed it correctly. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: kern/114095: [carp] carp+pf delay with high state limit
On Mon, Oct 17, 2011 at 02:18:38PM +0200, Ermal Lu?i wrote: E> On Sat, Oct 15, 2011 at 4:20 PM, wrote: E> > Synopsis: [carp] carp+pf delay with high state limit E> > E> > State-Changed-From-To: open->closed E> > State-Changed-By: glebius E> > State-Changed-When: Sat Oct 15 14:20:00 UTC 2011 E> > State-Changed-Why: E> > Not a bug. This is a feature. pfsync(4) suppresses carp(4) E> > preemption until new recently booted node downloads full E> > table of pf(4) states from its peer. E> E> This is not true on FreeBSD. E> The issue might be from other reasons. This is a surprise for me that this feature had been removed! It used to be in stable/6: http://fxr.watson.org/fxr/ident?v=FREEBSD60;i=carp_suppress_preempt And I always treated that variable in CARP as shared with pf. Why did they removed this feature from pfsync? P.S. Since PR is about 6.2-RELEASE, then I have closed it correctly. -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: altq on ng0 sometimes causing system panic
On Mon, Sep 11, 2006 at 02:32:19AM +0200, Volker wrote: V> two or three weeks ago I've switched from userland ppp to mpd for my V> internet connection. While using ng0 as the public interface I'm V> also using altq (cbq) for bw management. V> V> Everything works (haven't yet measured for queue effectiveness) but V> when issuing a `pfctl -gf mypf.conf' sometimes the system will V> panic. I need to reload my ruleset as soon as the internet V> connection has been set up because I've been lazy and am not using V> anchors so I'm just reloading my complete ruleset by a link-up V> script. I've been able to panic the machine just by reloading the V> ruleset manually several times in a row. V> V> As I currently don't have a serial console setup I'm unable to post V> any dumps or panic messages. Has anyone else experienced that? I've V> had queue statements in my pf rules before (even while using ppp and V> knowing about the problems with altq and tun) I've never experienced V> any panics. This is really just since changing from a tun to an ng V> device. V> V> If no one else has experienced panics like this I'll go and hook up V> the serial console and try to get a panic again. Current workaround V> is not to use altq on ng0 so I don't get panics ATM. V> V> Running RELENG_6, almost recently csup'ed. Please *show* the panic message and the backtrace. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/93829: [carp] pfsync state time problem with CARP + Arp.Balance
Synopsis: [carp] pfsync state time problem with CARP + Arp.Balance State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Wed Jun 7 10:28:13 UTC 2006 State-Changed-Why: I have documented why this setup can't work in carp(4). Responsible-Changed-From-To: freebsd-pf->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Wed Jun 7 10:28:13 UTC 2006 Responsible-Changed-Why: I have documented why this setup can't work in carp(4). http://www.freebsd.org/cgi/query-pr.cgi?pr=93829 ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/93829: Pfsync state time problem with CARP + Arp.Balance
The following reply was made to PR kern/93829; it has been noted by GNATS. From: Gleb Smirnoff <[EMAIL PROTECTED]> To: "C.Dornig" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: kern/93829: Pfsync state time problem with CARP + Arp.Balance Date: Sun, 26 Feb 2006 14:08:43 +0300 On Sat, Feb 25, 2006 at 02:24:25PM +, C.Dornig wrote: C> I have a problem with CARP + pf + pfsync in arp.balance mode. C> I have config 2 Cluster Routing / netfilter machines with carp + arpbalance. C> C> The pf rule a the same on both server. C> if the servers run in none arp.balance mode the rules are all fine and working perfektli. C> But, if i turn on arp.balance than i become follow problem. C> I made a ping (icmp packet) from my client pc (Client-LAN) to the Server behind the PF Cluster in other LAN. C> The first packet goes through the PFCluster1 and the back packet goes through 6luster2. But, the state information from the first packet to the server is not fast enough on the PFCluster2 machine and because the pf rules, the back packet will blocked. The next packet from client to server will passed also the back traffic. C> C> With out arp.balance the rule are ok, and all traffic will passed and the states will write correct. Only routing without pf are all ok. C> C> I have made all network diagnostics. I have made tcpdump on all interfaces and the carps are all OK. Also pfsync packets will receive and send from each machine. The two machine can send and receive packet each other. C> C> I think there is a time probleme from the pfsync. I mean that pfsync send too slow the state change to the other. You have a race between three computers - both CARP routers, and the host behind them. The ICMP packet can reach the host and be replied faster, then the state information is sent from one CARP router to another. I think, this problem is not solvable at all, so we must state that ARP load balancing is not compatible with pfsync(4). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [feature] ipfw verrevpath/versrcreach?
On Sat, Dec 31, 2005 at 12:50:57AM +0100, ?ukasz Bromirski wrote: ?> Is there by any chance work being done on pf to include functionality ?> that is present in FreeBSD ipfw, that checks if packet entered ?> router via correct interface as pointed out by routing table? ?> ?> I know there is antispoof, but it's simple check of connected network ?> and interface address, not full lookup to routing table contents. ?> On ipfw it's called verrevpath (checking if routing table points ?> for this source IP to the interface it came on) and versrcreach ?> (the same but default and blackhole routes don't count). Implementing this feature is very easy. The code that does this check is only a few lines. You can just copy and paste code from ipfw(4) and add new keywords to pf(4). Then submit patch to Daniel and Max. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/88362: [pf] [panic] carp with pfsync causing system crash, dump debug attached
Synopsis: [pf] [panic] carp with pfsync causing system crash, dump debug attached State-Changed-From-To: open->feedback State-Changed-By: glebius State-Changed-When: Mon Nov 7 11:58:15 GMT 2005 State-Changed-Why: Patch has been committed, and PR can be closed after submitter reports that upgrading to RELENG_5 fixes his problem, or after feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=88362 ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD + MPD + PF + ALTQ
On Wed, Oct 26, 2005 at 05:39:17PM +1000, Josh Finlay wrote: J> Thanks alot. :) J> J> Patched now. J> J> Hrm, would I need to buildworld again? J> Hope not, 4hrs waiting heh... Only kernel if you compile ng_iface into kernel, and only module if you load it dynamically. P.S. Please, do not top quote. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD + MPD + PF + ALTQ
On Wed, Oct 26, 2005 at 11:09:36AM +1000, Josh Finlay wrote: J> Gleb, my best friend! ;) ;) J> J> I've just cvsup'd to RELENG_6, would you have a nice pretty patch to give J> ng_iface(4) ALTQ functionality? J> J> I must have read wrong in previous messages, I thought RELENG_6 already had J> this merged in, but upon re-reading I found I was actually wrong, and my J> only real reason for going to RELENG_6 was for the ALTQ support on ng_iface. J> J> So i'm itching to get it kicking ;) The patch can be obtained this way: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_iface.c.diff?r1=text&tr1=1.43.2.1&r2=text&tr2=1.46 I will merge the change to RELENG_6 after 6.0-RELEASE is out. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf patch
On Tue, Oct 18, 2005 at 11:15:54AM +0300, Sorin Gheorghe wrote: S> did someone have the pf patch for tunning pf, i heard that pf has 6 classes and if i can patch the pf to remove some classes, it will become performant to shappe 10-15 kpps of trafic. pf doesn't shapes traffic, but altq does. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD + MPD + PF + ALTQ
On Fri, Oct 21, 2005 at 11:35:39PM +1000, Josh Finlay wrote: J> I tried a few examples I found, no luck, found another thing I will need to J> fix first: J> J> pfctl: ng0: driver does not support altq J> J> I searched for a patch for the ng_iface driver, but no luck. Recently ng_iface(4) has gained ALTQ support in CURRENT. I will merge this to RELENG_5 and RELENG_6 after the 6.0-RELEASE is out. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ALTQ and PPP access concentrator
Bruno, On Sun, Oct 16, 2005 at 02:06:44PM -0400, Bruno Afonso wrote: B> I've been recently "invited" (I mean, I was the only guy they knew that B> had fbsd experience :> ) to setup a pppoe server for a 20+ user base of B> wifi users. basically, we're using pppoe server from freebsd and a B> radius server for user authentication. B> B> there's a document explaining how to do this using ipfw and this uses B> ppp.linkup and ppp.linkdown to invoke scripts. Things get harder with pf B> + altq (I'm using cbq on tunX interfaces and hfsc on outgoing - read B> upload - interface). The way I've set it up was to create a script that B> reads a file that has listed all users on each interface and it B> generates the pf.conf. This was the only way I found to generate altq B> setup lines for each tunX interface. B> B> In a perfect world, one would do: B> B> altq on tun* ... B> B> This could for example be the DEFAULT altq setup instead a user would B> explicitly use B> B> altq on tun0 .. B> B> B> Having said this, it wouldn't help my setup too much since we have 3 to B> 4 classes of users and each has different bw priviledges so we always B> need to have a script... :-) Ideal solution would be when ALTQ (and probably pf) configuration is not changed in one commit, but altered on per interface basis. This will allow us to change only one users traffic bandwidth configuration, without resetting bandwidth settings on all other interfaces. And this is required if we want to store bandwidth parameters in RADIUS. P.S. Please, don't top quote. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ALTQ and PPP access concentrator
On Sat, Oct 15, 2005 at 04:39:37PM +0200, Max Laier wrote: M> I agree that ALTQ configuration (esp for big setups) has some limitations and M> gotchas as is. I'd like to take the opportunity to start a discussion about M> what features are required to make it more useable. It is certainly M> interesting to look at decoupling /dev/pf and altq configuration. The end M> result would be a (in-kernel) lookup service that allows pf (or any other M> end-user of ALTQ) to lookup QIDs by interface:qname. In order to keep things M> in sync I am thinking of a eventhandler of some kind. M> M> This would allow us to keep the inlined configuration as it happens right now Yes, I agree. Some work is needed here. Except the already described obstacles, we also have dangling pointers after the interfaces had been removed: pfctl -Af /etc/altq /usr/local/etc/rc.d/mpd4.sh restart [ this creates new ifnet instances, and destroys old ones] pfctl -Af /etc/altq boom! #5 0xc06fe33a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc05c1b91 in turnstile_setowner (ts=0xc1867dc0, owner=0x2839ea60) at /usr/src/sys/kern/subr_turnstile.c:417 #7 0xc05c1e94 in turnstile_wait (lock=0xc1cba10c, owner=0x2839ea60) at /usr/src/sys/kern/subr_turnstile.c:576 #8 0xc0598968 in _mtx_lock_sleep (m=0xc1cba10c, tid=0xc1c544e0, opts=0x0, file=0x0, line=0x0) at /usr/src/sys/kern/kern_mutex.c:553 #9 0xc045fe0e in priq_class_destroy (cl=0xc1bb6dc0) at /usr/src/sys/contrib/altq/altq/altq_priq.c:416 #10 0xc045fa7a in priq_clear_interface (pif=0xc1c45400) at /usr/src/sys/contrib/altq/altq/altq_priq.c:252 #11 0xc045f910 in priq_remove_altq (a=0xc1867dc0) at /usr/src/sys/contrib/altq/altq/altq_priq.c:161 #12 0xc0463290 in altq_remove (a=0xc1867dc0) at /usr/src/sys/contrib/altq/altq/altq_subr.c:647 #13 0xc048d72e in pf_commit_altq (ticket=0xc1c54500) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:1116 #14 0xc04910e7 in pfioctl (dev=0xc1711400, cmd=0x4, addr=0x0, flags=0x3, td=0xc1c54500) M> (just a little rewriting in pfctl), but enable easy changes for interfaces M> coming late. mpd would just trigger necessary altq-configuration from its M> UP-script. Actually I am dreaming to implement a RADIUS bandwidth management for mpd. In this case ALTQ configuration needs to be changed when the user logs in, for the interface he came. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ALTQ and PPP access concentrator
Colleagues,
I've got two problems when running ALTQ on PPP access
concentrator. May be you have ideas on how to solve them
in a nice way.
- When pf.conf is parsed at boot time, the p2p interfaces
(ng_iface(4) in my case) do not exist, so the ALTQ queues
are not created. The PPP software (mpd in my case) usually
starts at later stage of boot. Moreover, some programs like
ppp(8) create interfaces dynamically, not at boot time.
- The PPP access concentrator may have a lot of interfaces.
Why isn't it possible to specify same ALTQ policy on all
interfaces of given type, like this:
altq on ng* priq bandwidth 56Kb queue { cvsup def dns ack ssh }
Instead, one needs to copy and paste a lot of lines differing
only in interface unit number.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/82271: cbq scheduler cause bad latency
Synopsis: cbq scheduler cause bad latency Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: glebius Responsible-Changed-When: Mon Jun 20 08:59:48 GMT 2005 Responsible-Changed-Why: For pf gurus review. http://www.freebsd.org/cgi/query-pr.cgi?pr=82271 ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Carp Suppression
On Mon, Jun 13, 2005 at 12:00:36PM -0400, Josh Kayse wrote: J> The reason we are using CARP on a PLIP interface is to allow us to J> have redundant connections between 2 transparent bridging firewalls. J> Instead of sending packets over our network, we isolate them onto a J> PLIP interface and crossover interface. We then use ifstaded to J> monitor the carp interfaces and shut down bridging on one of the J> machines. AFAIU, you use PLIP line as some flag that triggers suppression. If slave "sees" master via PLIP, it keeps itself in slave mode. May be I don't understand you right. Although the idea is not officially supported, it is interesting. Can you please draw your setup, since I don't understand it clearly? Bringing link state support for p2p interfaces is a TODO, although CARP is not going to be supported on p2p interfaces officially. J> I will refrain from submitting any code to the community in the future. Why? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
