[patch] Source entries removing is awfully slow.

[Ermal Luçi]

Hello,

can you specify what does not fit on the current interface from pfctl?

-k and -K have different scopes.

You already can specify src/dst today through them.
The only not possible thing is specifying ports/id for protocols that
support them tcp/udp/icmp,
mostly because the switch/parsing of arguments does not allow that.

Furthermore pfctl is not really a well built utility per se, it does not
provide any interface/library so external tools can use easily.
That would be an improvement to it so extra features you need can be built
easily
and do not need to go into this utility per se.

Though going back to your request, can you specify your requirments since i
did not understand from the mail fwd here.



On Mon, Dec 2, 2013 at 5:39 PM, Gleb Smirnoff <glebius at freebsd.org> wrote:

>   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 4823e84500000003
> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>



-- 
Ermal