Re: [RFC/RFT] projects/ipsec
On Tue, Dec 27, 2016 at 6:10 AM, Andrey V. Elsukov wrote: > On 27.12.2016 16:15, Jim Thompson wrote: > >> In it's initial state if_ipsec allows to use only one set of >>> encryption parameters (because only one sainfo anonyumous is >>> possible), so at this time it doesn't allow to create multiple >>> tunnels with VPN hubs that use different cipers and/or transform >>> sets, but as far as I understand this is subject to change and >>> Andrey is already working on a support of this feature from >>> ipsec-tools IKE daemon. >>> >> >> pfSense (which you mention below) is using strongswan, so when >> Andrey is finished with ipsec-tools, we will need to review his >> changes and see what we can do for strongswan. >> >> I'm looking forward to the mutliple-tunnel support, which is >> required for pfSense. >> > > There are no such limits. You can create multiple VTI interfaces. > The problem is in with racoon configuration restrictions. It looks like > ipsec-tools project is dead, I didn't received any replies from > ipsec-tools-devel mailing list. > > I'm not aware how to configure strongswan, so if someone will not try to > do this, I don't know when I will do this. > > Strongswan already supports this. Just the FreeBSD code for it is not there due to the missing feature until now. > -- > WBR, Andrey V. Elsukov > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > -- > Ermal > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: negative refcount after dhclient during boot
On Wed, Jul 8, 2015 at 5:09 PM, Ermal Luçi wrote: > > > On Tue, Jul 7, 2015 at 6:11 PM, Rink Springer wrote: > >> Hi eri@, >> >> On Mon, Jul 06, 2015 at 09:21:54AM +0200, Rink Springer wrote: >> > On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote: >> > > On Jul 5, 2015, at 8:16, Rink Springer wrote: >> > > >> > > > Hi all, >> > > > >> > > > On my FreeBSD/mips machine (it's a RouterStation Pro), I get the >> > > > following panic during boot: >> > > >> > > ? >> > > >> > > > This reproduces 100%. I'm at: >> > > > >> > > > FreeBSD 11.0-CURRENT #0 r285099: Sun Jul 5 12:31:47 CEST 2015 >> > > > >> > > > Let me know what I can do to help track this down; I only started >> > > > getting the panic after 'gateway_enable=YES' in /etc/rc.conf >> > > > >> > > > The kernel has INVARIANTS but no WITNESS. Config available at >> > > > http://rink.nu/tmp/FRINGE - boot log at >> http://rink.nu/tmp/fringe.txt >> > > >> > > Please file a bug! >> > >> > Done, 201371. >> >> After a suggestion by adrian@, it seems reverting r285051 fixes the >> problem for me (i.e. the system boots now) >> >> > Can you please try with this patch and let me know if it fixes the issue. > > Index: sys/netinet/ip_output.c > === > --- sys/netinet/ip_output.c (revision 285271) > +++ sys/netinet/ip_output.c (working copy) > @@ -660,6 +660,13 @@ > done: > if (ro == &iproute) > RO_RTFREE(ro); > + else if (rte == NULL) > + /* > +* If the caller supplied a route but somehow the reference > +* to it has been released need to prevent the caller > +* calling RTFREE on it again. > +*/ > + ro->ro_rt = NULL; > if (have_ia_ref) > ifa_free(&ia->ia_ifa); > return (error); > > >> Regards, >> Rink > > Actually this is the correct fix apparently. https://reviews.freebsd.org/D3036 -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: negative refcount after dhclient during boot
On Tue, Jul 7, 2015 at 6:11 PM, Rink Springer wrote: > Hi eri@, > > On Mon, Jul 06, 2015 at 09:21:54AM +0200, Rink Springer wrote: > > On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote: > > > On Jul 5, 2015, at 8:16, Rink Springer wrote: > > > > > > > Hi all, > > > > > > > > On my FreeBSD/mips machine (it's a RouterStation Pro), I get the > > > > following panic during boot: > > > > > > ? > > > > > > > This reproduces 100%. I'm at: > > > > > > > > FreeBSD 11.0-CURRENT #0 r285099: Sun Jul 5 12:31:47 CEST 2015 > > > > > > > > Let me know what I can do to help track this down; I only started > > > > getting the panic after 'gateway_enable=YES' in /etc/rc.conf > > > > > > > > The kernel has INVARIANTS but no WITNESS. Config available at > > > > http://rink.nu/tmp/FRINGE - boot log at > http://rink.nu/tmp/fringe.txt > > > > > > Please file a bug! > > > > Done, 201371. > > After a suggestion by adrian@, it seems reverting r285051 fixes the > problem for me (i.e. the system boots now) > > Can you please try with this patch and let me know if it fixes the issue. Index: sys/netinet/ip_output.c === --- sys/netinet/ip_output.c (revision 285271) +++ sys/netinet/ip_output.c (working copy) @@ -660,6 +660,13 @@ done: if (ro == &iproute) RO_RTFREE(ro); + else if (rte == NULL) + /* +* If the caller supplied a route but somehow the reference +* to it has been released need to prevent the caller +* calling RTFREE on it again. +*/ + ro->ro_rt = NULL; if (have_ia_ref) ifa_free(&ia->ia_ifa); return (error); > Regards, > Rink > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour
And some better marketing from Dragonfly about it http://forum.nginx.org/read.php?29,241283,241283 :) On Fri, Nov 29, 2013 at 7:55 PM, Ermal Luçi wrote: > Also some discussions and improvements to it. > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html > > > On Fri, Nov 29, 2013 at 7:42 PM, Ermal Luçi wrote: > >> Well seems Dragonfly has some version of it already from commit [1]. >> >> In FreeBSD there is the framework for this with by defining PCBGROUP. >> Also the explanation of it at [2] and [3]. >> It can achieve approximately the same features of SO_RESUSEPORT of linux. >> The only thing missing is the marketing behind it and i think and better >> RSS support. >> By looking at dates the support is there before linux so all you guys >> looking for it can experiment with it. >> >> What i was trying to accomplish was something else from performance >> improvement and >> maybe put a sysctl behind it to make it more acceptable.. >> >> [1] >> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c021abb8197718d7a2d441c9 >> [2] >> http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=bigexcerpts#L51 >> [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html >> >> >> On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wrote: >> >>> Tim, you are wrong. Read what is "multicast" definition, and read how >>> UDP and TCP sockets work in Linux 3.9+ kernels. >>> >>> Oleg . >>> >>> >>> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wrote: >>> >>>> >>>> On Nov 29, 2013, at 4:04 AM, Ermal Luçi wrote: >>>> >>>> > Hello, >>>> > >>>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons >>>> to >>>> > share the same port and possibly listening ip … >>>> >>>> These flags are used with TCP-based servers. >>>> >>>> I’ve used them to make software upgrades go more smoothly. >>>> Without them, the following often happens: >>>> >>>> * Old server stops. In the process, all of its TCP connections are >>>> closed. >>>> >>>> * Connections to old server remain in the TCP connection table until >>>> the remote end can acknowledge. >>>> >>>> * New server starts. >>>> >>>> * New server tries to open port but fails because that port is “still >>>> in use” by connections in the TCP connection table. >>>> >>>> With these flags, the new server can open the port even though >>>> it is “still in use” by existing connections. >>>> >>>> >>>> > This is not the case today. >>>> > Only multicast sockets seem to have the behaviour of broadcasting the >>>> data >>>> > to all sockets sharing the same properties through these options! >>>> >>>> That is what multicast is for. >>>> >>>> If you want the same data sent to all listeners, then >>>> that is multicast behavior and you should be using >>>> a multicast socket. >>>> >>>> > The patch at [1] implements/corrects the behaviour for UDP sockets. >>>> >>>> You’re trying to turn all UDP sockets with those options >>>> into multicast sockets. >>>> >>>> If you want a multicast socket, you should ask for one. >>>> >>>> Tim >>>> >>>> ___ >>>> freebsd-...@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>>> >>> >>> >> >> >> -- >> Ermal >> > > > > -- > Ermal > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour
Also some discussions and improvements to it. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html On Fri, Nov 29, 2013 at 7:42 PM, Ermal Luçi wrote: > Well seems Dragonfly has some version of it already from commit [1]. > > In FreeBSD there is the framework for this with by defining PCBGROUP. > Also the explanation of it at [2] and [3]. > It can achieve approximately the same features of SO_RESUSEPORT of linux. > The only thing missing is the marketing behind it and i think and better > RSS support. > By looking at dates the support is there before linux so all you guys > looking for it can experiment with it. > > What i was trying to accomplish was something else from performance > improvement and > maybe put a sysctl behind it to make it more acceptable.. > > [1] > http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c021abb8197718d7a2d441c9 > [2] > http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=bigexcerpts#L51 > [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html > > > On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wrote: > >> Tim, you are wrong. Read what is "multicast" definition, and read how UDP >> and TCP sockets work in Linux 3.9+ kernels. >> >> Oleg . >> >> >> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wrote: >> >>> >>> On Nov 29, 2013, at 4:04 AM, Ermal Luçi wrote: >>> >>> > Hello, >>> > >>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons >>> to >>> > share the same port and possibly listening ip … >>> >>> These flags are used with TCP-based servers. >>> >>> I’ve used them to make software upgrades go more smoothly. >>> Without them, the following often happens: >>> >>> * Old server stops. In the process, all of its TCP connections are >>> closed. >>> >>> * Connections to old server remain in the TCP connection table until the >>> remote end can acknowledge. >>> >>> * New server starts. >>> >>> * New server tries to open port but fails because that port is “still in >>> use” by connections in the TCP connection table. >>> >>> With these flags, the new server can open the port even though >>> it is “still in use” by existing connections. >>> >>> >>> > This is not the case today. >>> > Only multicast sockets seem to have the behaviour of broadcasting the >>> data >>> > to all sockets sharing the same properties through these options! >>> >>> That is what multicast is for. >>> >>> If you want the same data sent to all listeners, then >>> that is multicast behavior and you should be using >>> a multicast socket. >>> >>> > The patch at [1] implements/corrects the behaviour for UDP sockets. >>> >>> You’re trying to turn all UDP sockets with those options >>> into multicast sockets. >>> >>> If you want a multicast socket, you should ask for one. >>> >>> Tim >>> >>> ___ >>> freebsd-...@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >> >> > > > -- > Ermal > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour
On Fri, Nov 29, 2013 at 6:59 PM, Tim Kientzle wrote: > > On Nov 29, 2013, at 4:04 AM, Ermal Luçi wrote: > > > Hello, > > > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to > > share the same port and possibly listening ip … > > These flags are used with TCP-based servers. > Every one has its own use-case! > > I’ve used them to make software upgrades go more smoothly. > Without them, the following often happens: > > * Old server stops. In the process, all of its TCP connections are closed. > > * Connections to old server remain in the TCP connection table until the > remote end can acknowledge. > > * New server starts. > > * New server tries to open port but fails because that port is “still in > use” by connections in the TCP connection table. > > With these flags, the new server can open the port even though > it is “still in use” by existing connections. > > > > This is not the case today. > > Only multicast sockets seem to have the behaviour of broadcasting the > data > > to all sockets sharing the same properties through these options! > > That is what multicast is for. > > Multicast has its defined scope and its applications though i think its interpreting the same socket options and respecting the options for what they should do and how they should behave. > If you want the same data sent to all listeners, then > that is multicast behavior and you should be using > a multicast socket. > > > The patch at [1] implements/corrects the behaviour for UDP sockets. > > You’re trying to turn all UDP sockets with those options > into multicast sockets. > Not really the idea is how you do support the use case of having two daemons using the same port numbers but speaking different protocols. The best would be to merge these daemons but in the case you cannot there should be some support on it. At the very end there are only 65k ports :). Probably a sysctl for the feature might be a further compromise on it? > > If you want a multicast socket, you should ask for one. > > Tim > > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour
Well seems Dragonfly has some version of it already from commit [1]. In FreeBSD there is the framework for this with by defining PCBGROUP. Also the explanation of it at [2] and [3]. It can achieve approximately the same features of SO_RESUSEPORT of linux. The only thing missing is the marketing behind it and i think and better RSS support. By looking at dates the support is there before linux so all you guys looking for it can experiment with it. What i was trying to accomplish was something else from performance improvement and maybe put a sysctl behind it to make it more acceptable.. [1] http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c021abb8197718d7a2d441c9 [2] http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=bigexcerpts#L51 [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wrote: > Tim, you are wrong. Read what is "multicast" definition, and read how UDP > and TCP sockets work in Linux 3.9+ kernels. > > Oleg . > > > On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wrote: > >> >> On Nov 29, 2013, at 4:04 AM, Ermal Luçi wrote: >> >> > Hello, >> > >> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to >> > share the same port and possibly listening ip … >> >> These flags are used with TCP-based servers. >> >> I’ve used them to make software upgrades go more smoothly. >> Without them, the following often happens: >> >> * Old server stops. In the process, all of its TCP connections are >> closed. >> >> * Connections to old server remain in the TCP connection table until the >> remote end can acknowledge. >> >> * New server starts. >> >> * New server tries to open port but fails because that port is “still in >> use” by connections in the TCP connection table. >> >> With these flags, the new server can open the port even though >> it is “still in use” by existing connections. >> >> >> > This is not the case today. >> > Only multicast sockets seem to have the behaviour of broadcasting the >> data >> > to all sockets sharing the same properties through these options! >> >> That is what multicast is for. >> >> If you want the same data sent to all listeners, then >> that is multicast behavior and you should be using >> a multicast socket. >> >> > The patch at [1] implements/corrects the behaviour for UDP sockets. >> >> You’re trying to turn all UDP sockets with those options >> into multicast sockets. >> >> If you want a multicast socket, you should ask for one. >> >> Tim >> >> ___ >> freebsd-...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> > > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour
Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip, you would expect if you bind two daemon with such options to same port to see the same traffic on both! This is not the case today. Only multicast sockets seem to have the behaviour of broadcasting the data to all sockets sharing the same properties through these options! The patch at [1] implements/corrects the behaviour for UDP sockets. Is there anything to be corrected in that patch? Why it has not been provided there before? Can it be committed to the tree? Any extra security checks for jails needed there? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding/ipfw/pf evolution (in pps) on -current
Hello, would you mind running a performance test with a snapshot of tomorrow from this link http://snapshots.pfsense.org/ There are some optimizations in pfSense and it would be nicer to compare to FreeBSD itself how it behaves. That is before the lock changes in HEAD since its FreeBSD 8. Regards, Ermal On Thu, Apr 25, 2013 at 7:40 AM, Olivier Cochard-Labbé wrote: > On Wed, Apr 24, 2013 at 1:46 PM, Sami Halabi wrote: > > 3. there some point of improved performance (without fw) that went down > > again somewhere before Clang got prod. > > Found it ! > > It's commit 242402: "Rework the known mutexes..." > > ministat -s 242401.forwarding 242402.forwarding > x 242401.forwarding > + 242402.forwarding > > +---+ > |+ > | > |+ + + + >x xx x x| > | > |A| | > | |_A_M___| > | > > +---+ > N Min MaxMedian AvgStddev > x 5417527420242418902419074 1049.7974 > + 5402211404828404096403689 1237.6696 > Difference at 95.0% confidence > -15385 +/- 1673.69 > -3.67119% +/- 0.399377% > (Student's t, pooled s = 1147.58) > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Re-sizable UFS project
On Tue, Nov 27, 2012 at 12:13 PM, Alex Dupre wrote: > Ermal Luçi ha scritto: > > some time ago the FreeBSD Foundation published/approved a project for > live > > resizing of UFS filesystems. > > Does any know if the project was successful and any outcome from it? > > http://lists.freebsd.org/pipermail/svn-src-head/2012-November/042539.html > > -- > Alex Dupre > Thank you, somehow my search terms must have been wrong. -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re-sizable UFS project
Hello, some time ago the FreeBSD Foundation published/approved a project for live resizing of UFS filesystems. Does any know if the project was successful and any outcome from it? -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Wed, Nov 21, 2012 at 3:52 PM, Gleb Smirnoff wrote: > 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. > > I am sorry but you are asking arguments i already have given you. You didn;t listen once and i do not expect this time as well. > 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? > > Well you have used it for your work so it was not so PITA. Most of the ones you closed had message 'This is to old to be true'; 'I have re-written PF and this should be fixed'. > 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"? > > See above. > 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. > > I really do not think you do the right approach or the right communication on this. Sorry for replying to you ;). > -- > Totus tuus, Glebius. > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Wed, Nov 21, 2012 at 8:56 AM, Gleb Smirnoff wrote: > 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. > > The issues is you cannot without modifying rule config. > 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. > > Well it depends on the amount of work. Cherry-picking would be when tehre is reasonable similarities. Also another argument to do this would be simplicity on locking as well as i told you when you started the changes. Though i am open to work together on this to merge the new syntax thorugh a whole bulk merge rather than cherry-pick. You already have 'broken' some functionality as if-bound in FreeBSD 10.x so why not break syntax and see to introduce if real value behind a converter as well. > -- > Totus tuus, Glebius. > ___ > freebsd...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org" > -- Ermal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
