Re: [CFT] new tables for ipfw
On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: > Hello list. > > I've been hacking ipfw for a while and It seems there is something ready > to test/review in projects/ipfw branch. > this is a fantastic piece of work, thanks for doing it and for integrating the feedback. I have some detailed feedback that will send you privately, but just a curiosity: ... > > Some examples (see ipfw(8) manual page for the description): > > > ... > > > ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" > why do we need to specify mask lengths in the above ? cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14.08.2014 13:23, Luigi Rizzo wrote: On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: Hello list. I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. this is a fantastic piece of work, thanks for doing it and for integrating the feedback. I have some detailed feedback that will send you privately, but just a curiosity: ... Some examples (see ipfw(8) manual page for the description): ... ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" why do we need to specify mask lengths in the above ? Well, since we're hashing IP we have to know mask to cut host bits in advance. (And the real reason is that I'm too lazy to implement hierarchical matching (check /32, then /31, then /30) like how, for example, this is done in ipset), so this particular algorithm supports only single IPv4 and single IPv6 mask. Anyway, it is not too hard to add another algo which is doing the above. cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: > On 14.08.2014 13:23, Luigi Rizzo wrote: > > > > > On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov < > melif...@yandex-team.ru> wrote: > >> Hello list. >> >> I've been hacking ipfw for a while and It seems there is something ready >> to test/review in projects/ipfw branch. >> > > this is a fantastic piece of work, thanks for doing it and for > integrating the feedback. > > I have some detailed feedback that will send you privately, > but just a curiosity: > > ... >> >> Some examples (see ipfw(8) manual page for the description): >> >> >> ... >> >> >> ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" >> > > why do we need to specify mask lengths in the above ? > > Well, since we're hashing IP we have to know mask to cut host bits in > advance. > (And the real reason is that I'm too lazy to implement hierarchical > matching (check /32, then /31, then /30) like how, for example, > oh well for that we should use cidr:radix Research results have never shown a strong superiority of hierarchical hash tables over good radix implementations, and in those cases one usually adopts partial prefix expansion so you only have, say, masks that are a multiple of 2..8 bits so you only need a small number of hash lookups. cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14.08.2014 14:44, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: On 14.08.2014 13:23, Luigi Rizzo wrote: On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: Hello list. I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. this is a fantastic piece of work, thanks for doing it and for integrating the feedback. I have some detailed feedback that will send you privately, but just a curiosity: ... Some examples (see ipfw(8) manual page for the description): ... ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" why do we need to specify mask lengths in the above ? Well, since we're hashing IP we have to know mask to cut host bits in advance. (And the real reason is that I'm too lazy to implement hierarchical matching (check /32, then /31, then /30) like how, for example, oh well for that we should use cidr:radix Research results have never shown a strong superiority of hierarchical hash tables over good radix implementations, and in those cases one usually adopts partial prefix expansion so you only have, say, masks that are a multiple of 2..8 bits so you only need a small number of hash lookups. Definitely, especially for IPv6. So I was actually thinking about covering some special sparse cases (e.g. someone having a bunch of /32 and a bunch of /30 and that's all). Btw, since we're talking about "good radix implementation": what license does DXR have? :) Is it OK to merge it as another cidr implementation? cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: > On 14.08.2014 14:44, Luigi Rizzo wrote: > > > > > On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov < > melif...@yandex-team.ru> wrote: > >> On 14.08.2014 13:23, Luigi Rizzo wrote: >> >> >> >> >> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov < >> melif...@yandex-team.ru> wrote: >> >>> Hello list. >>> >>> I've been hacking ipfw for a while and It seems there is something ready >>> to test/review in projects/ipfw branch. >>> >> >> this is a fantastic piece of work, thanks for doing it and for >> integrating the feedback. >> >> I have some detailed feedback that will send you privately, >> but just a curiosity: >> >> ... >>> >>> Some examples (see ipfw(8) manual page for the description): >>> >>> >>> ... >>> >>> >>> ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" >>> >> >> why do we need to specify mask lengths in the above ? >> >> Well, since we're hashing IP we have to know mask to cut host bits in >> advance. >> (And the real reason is that I'm too lazy to implement hierarchical >> matching (check /32, then /31, then /30) like how, for example, >> > > oh well for that we should use cidr:radix > > Research results have never shown a strong superiority of > hierarchical hash tables over good radix implementations, > and in those cases one usually adopts partial prefix > expansion so you only have, say, masks that are a > multiple of 2..8 bits so you only need a small number of > hash lookups. > > Definitely, especially for IPv6. So I was actually thinking about covering > some special sparse cases (e.g. someone having a bunch of /32 and a bunch > of /30 and that's all). > > Btw, since we're talking about "good radix implementation": what license > does DXR have? :) > Is it OK to merge it as another cidr implementation? > "cidr" is a very ugly name, i'd rather use "addr" DXR has a bsd license and of course it is possible to use it. You should ask Marko Zec for his latest version of the code (and probably make sure we have one copy of the code in the source tree). Speaking of features, one thing that would be nice is the ability for tables to reference the in-kernel tables (e.g. fibs, socket lists, interface lists...), perhaps in readonly mode. How complex do you think that would be ? cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14.08.2014 15:15, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: On 14.08.2014 14:44, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: On 14.08.2014 13:23, Luigi Rizzo wrote: On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: Hello list. I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. this is a fantastic piece of work, thanks for doing it and for integrating the feedback. I have some detailed feedback that will send you privately, but just a curiosity: ... Some examples (see ipfw(8) manual page for the description): ... ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" why do we need to specify mask lengths in the above ? Well, since we're hashing IP we have to know mask to cut host bits in advance. (And the real reason is that I'm too lazy to implement hierarchical matching (check /32, then /31, then /30) like how, for example, oh well for that we should use cidr:radix Research results have never shown a strong superiority of hierarchical hash tables over good radix implementations, and in those cases one usually adopts partial prefix expansion so you only have, say, masks that are a multiple of 2..8 bits so you only need a small number of hash lookups. Definitely, especially for IPv6. So I was actually thinking about covering some special sparse cases (e.g. someone having a bunch of /32 and a bunch of /30 and that's all). Btw, since we're talking about "good radix implementation": what license does DXR have? :) Is it OK to merge it as another cidr implementation? "cidr" is a very ugly name, i'd rather use "addr" Ok, no problem with that. "addr" really sounds better. DXR has a bsd license and of course it is possible to use it. You should ask Marko Zec for his latest version of the code (and probably make sure we have one copy of the code in the source tree). Great!. I'll ask him :) Speaking of features, one thing that would be nice is the ability for tables to reference the in-kernel tables (e.g. fibs, socket lists, interface lists...), perhaps in readonly mode. How complex do you think that would be ? Implementing algo support for particular provider like sockets/iflists shouldn't be hard. Most of the algorithms complexity lies in table modifications. Here we have to support lookup and dump operations, so it is the question of providing necessary bindings to existing mechanisms (via some direct binding or utilizing things like kernel_sysctl for dump support). It looks like the following maps well to current table concept: * such tables are not created by default * user issues `ipfw table kfib create type addr algo "addr:kernel fib=0"` or `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` or `ipfw table kiface create type iface algo "iface:kernel"` * tables have special "readonly" type, flush_all requests are ignored * no state stored internally So generic table handling code needs to be modified to support read-only tables (and making more callbacks optional). Additionally, we might need to proxy "info" request info algo callback (optional, "real" algorithms won't implement it) to be able to show number of items (and some other info) to user. cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 2014-08-14 13:15, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: On 14.08.2014 14:44, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: On 14.08.2014 13:23, Luigi Rizzo wrote: On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: Hello list. I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. this is a fantastic piece of work, thanks for doing it and for integrating the feedback. I have some detailed feedback that will send you privately, but just a curiosity: ... Some examples (see ipfw(8) manual page for the description): ... ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" why do we need to specify mask lengths in the above ? Well, since we're hashing IP we have to know mask to cut host bits in advance. (And the real reason is that I'm too lazy to implement hierarchical matching (check /32, then /31, then /30) like how, for example, oh well for that we should use cidr:radix Research results have never shown a strong superiority of hierarchical hash tables over good radix implementations, and in those cases one usually adopts partial prefix expansion so you only have, say, masks that are a multiple of 2..8 bits so you only need a small number of hash lookups. Definitely, especially for IPv6. So I was actually thinking about covering some special sparse cases (e.g. someone having a bunch of /32 and a bunch of /30 and that's all). Btw, since we're talking about "good radix implementation": what license does DXR have? :) Is it OK to merge it as another cidr implementation? "cidr" is a very ugly name, i'd rather use "addr" DXR has a bsd license and of course it is possible to use it. You should ask Marko Zec for his latest version of the code (and probably make sure we have one copy of the code in the source tree). Speaking of features, one thing that would be nice is the ability for tables to reference the in-kernel tables (e.g. fibs, socket lists, interface lists...), perhaps in readonly mode. How complex do you think that would be ? I'm a very happy user of ipfw and I think these are nice improvements and will make things more flexible... I have 2 nits to pick with the current version. I've found the notation ipnr:something rather frustrating when using ipv6 addresses. Sort of like typing a ipv6 address in a browser, the last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. compare 2001:4cb8:3:1::1 2001:4cb8:3:1::1:80 [2001:4cb8:3:1::1]:80 The first and the last are the same host but a different port, the middle one is just a different host. Could/should we do the same in ipfw? And I keep running into the ipfw add deny all from table(50) to any notation. the ()'s need to be escaped in most any shell. Where as I look at the syntax there is little reason to require the ()'s. the keyword table always needs to be followed by a number (and in the new version a (word|number) ). Thanx for the nice work, --WjW ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On Thu, 14 Aug 2014 15:52:34 +0400 "Alexander V. Chernikov" wrote: > On 14.08.2014 15:15, Luigi Rizzo wrote: > > > > > > > > On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov > > mailto:melif...@yandex-team.ru>> wrote: > > > > On 14.08.2014 14:44, Luigi Rizzo wrote: > >> > >> > >> > >> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov > >> mailto:melif...@yandex-team.ru>> > >> wrote: > >> > >> On 14.08.2014 13:23, Luigi Rizzo wrote: > >>> > >>> > >>> > >>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov > >>> mailto:melif...@yandex-team.ru>> > >>> wrote: > >>> > >>> Hello list. > >>> > >>> I've been hacking ipfw for a while and It seems there > >>> is something ready to test/review in projects/ipfw branch. > >>> > >>> > >>> this is a fantastic piece of work, thanks for doing it > >>> and for integrating the feedback. > >>> > >>> I have some detailed feedback that will send you > >>> privately, but just a curiosity: > >>> > >>> ... > >>> > >>> Some examples (see ipfw(8) manual page for the > >>> description): > >>> > >>> ... > >>> > >>> > >>> ipfw table mi_test create type cidr algo "cidr:hash > >>> masks=/30,/64" > >>> > >>> > >>> why do we need to specify mask lengths in the above ? > >> Well, since we're hashing IP we have to know mask to cut > >> host bits in advance. > >> (And the real reason is that I'm too lazy to implement > >> hierarchical matching (check /32, then /31, then /30) like > >> how, for example, > >> > >> > >> oh well for that we should use cidr:radix > >> > >> Research results have never shown a strong superiority of > >> hierarchical hash tables over good radix implementations, > >> and in those cases one usually adopts partial prefix > >> expansion so you only have, say, masks that are a > >> multiple of 2..8 bits so you only need a small number of > >> hash lookups. > > Definitely, especially for IPv6. So I was actually thinking > > about covering some special sparse cases (e.g. someone having a > > bunch of /32 and a bunch of /30 and that's all). > > > > Btw, since we're talking about "good radix implementation": what > > license does DXR have? :) > > Is it OK to merge it as another cidr implementation? > > > > "cidr" is a very ugly name, i'd rather use "addr" > Ok, no problem with that. "addr" really sounds better. > > > > DXR has a bsd license and of course it is possible to use it. > > You should ask Marko Zec for his latest version of the code > > (and probably make sure we have one copy of the code in the source > > tree). > Great!. I'll ask him :) The so far cleanest DXR implementation is significantly C++ poluted and wrapped inside Click glue (available here: http://www.nxab.fer.hr/dxr) I'll try to backport the fixes to the original C-only / BSD implementation over the weekend and let you know how it goes... Marko > > > > Speaking of features, one thing that would be nice is the ability > > for tables to reference the in-kernel tables (e.g. fibs, socket > > lists, interface lists...), perhaps in readonly mode. > > How complex do you think that would be ? > Implementing algo support for particular provider like > sockets/iflists shouldn't be hard. Most of the algorithms complexity > lies in table modifications. Here we have to support > lookup and dump operations, so it is the question of providing > necessary bindings to existing mechanisms (via some direct binding or > utilizing things like kernel_sysctl for dump support). > > It looks like the following maps well to current table concept: > * such tables are not created by default > * user issues > `ipfw table kfib create type addr algo "addr:kernel fib=0"` > or > `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` > or > `ipfw table kiface create type iface algo "iface:kernel"` > * tables have special "readonly" type, flush_all requests are ignored > * no state stored internally > > So generic table handling code needs to be modified to support > read-only tables (and making more callbacks optional). > Additionally, we might need to proxy "info" request info algo > callback (optional, "real" algorithms won't implement it) to be able > to show number of items (and some other info) to user. > > > > > > > cheers > > luigi > > > > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14.08.2014 16:08, Marko Zec wrote: On Thu, 14 Aug 2014 15:52:34 +0400 "Alexander V. Chernikov" wrote: On 14.08.2014 15:15, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: On 14.08.2014 14:44, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: On 14.08.2014 13:23, Luigi Rizzo wrote: On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: Hello list. I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. this is a fantastic piece of work, thanks for doing it and for integrating the feedback. I have some detailed feedback that will send you privately, but just a curiosity: ... Some examples (see ipfw(8) manual page for the description): ... ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" why do we need to specify mask lengths in the above ? Well, since we're hashing IP we have to know mask to cut host bits in advance. (And the real reason is that I'm too lazy to implement hierarchical matching (check /32, then /31, then /30) like how, for example, oh well for that we should use cidr:radix Research results have never shown a strong superiority of hierarchical hash tables over good radix implementations, and in those cases one usually adopts partial prefix expansion so you only have, say, masks that are a multiple of 2..8 bits so you only need a small number of hash lookups. Definitely, especially for IPv6. So I was actually thinking about covering some special sparse cases (e.g. someone having a bunch of /32 and a bunch of /30 and that's all). Btw, since we're talking about "good radix implementation": what license does DXR have? :) Is it OK to merge it as another cidr implementation? "cidr" is a very ugly name, i'd rather use "addr" Ok, no problem with that. "addr" really sounds better. DXR has a bsd license and of course it is possible to use it. You should ask Marko Zec for his latest version of the code (and probably make sure we have one copy of the code in the source tree). Great!. I'll ask him :) The so far cleanest DXR implementation is significantly C++ poluted and wrapped inside Click glue (available here: http://www.nxab.fer.hr/dxr) I'll try to backport the fixes to the original C-only / BSD implementation over the weekend and let you know how it goes... Great! I've got 2012 version half-ported (and radix fix has been merged to the tree), but something definitely has changed since then :) I'd be happy to hear from you :) Marko Speaking of features, one thing that would be nice is the ability for tables to reference the in-kernel tables (e.g. fibs, socket lists, interface lists...), perhaps in readonly mode. How complex do you think that would be ? Implementing algo support for particular provider like sockets/iflists shouldn't be hard. Most of the algorithms complexity lies in table modifications. Here we have to support lookup and dump operations, so it is the question of providing necessary bindings to existing mechanisms (via some direct binding or utilizing things like kernel_sysctl for dump support). It looks like the following maps well to current table concept: * such tables are not created by default * user issues `ipfw table kfib create type addr algo "addr:kernel fib=0"` or `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` or `ipfw table kiface create type iface algo "iface:kernel"` * tables have special "readonly" type, flush_all requests are ignored * no state stored internally So generic table handling code needs to be modified to support read-only tables (and making more callbacks optional). Additionally, we might need to proxy "info" request info algo callback (optional, "real" algorithms won't implement it) to be able to show number of items (and some other info) to user. cheers luigi ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On Thu, Aug 14, 2014 at 5:08 AM, Marko Zec wrote: > On Thu, 14 Aug 2014 15:52:34 +0400 > "Alexander V. Chernikov" wrote: > > > On 14.08.2014 15:15, Luigi Rizzo wrote: > > > > > > > > > > > > On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov > > > mailto:melif...@yandex-team.ru>> wrote: > > > > > > On 14.08.2014 14:44, Luigi Rizzo wrote: > > >> > > >> > > >> > > >> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov > > >> mailto:melif...@yandex-team.ru>> > > >> wrote: > > >> > > >> On 14.08.2014 13:23, Luigi Rizzo wrote: > > >>> > > >>> > > >>> > > >>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov > > >>> mailto:melif...@yandex-team.ru>> > > >>> wrote: > > >>> > > >>> Hello list. > > >>> > > >>> I've been hacking ipfw for a while and It seems there > > >>> is something ready to test/review in projects/ipfw branch. > > >>> > > >>> > > >>> this is a fantastic piece of work, thanks for doing it > > >>> and for integrating the feedback. > > >>> > > >>> I have some detailed feedback that will send you > > >>> privately, but just a curiosity: > > >>> > > >>> ... > > >>> > > >>> Some examples (see ipfw(8) manual page for the > > >>> description): > > >>> > > >>> ... > > >>> > > >>> > > >>> ipfw table mi_test create type cidr algo "cidr:hash > > >>> masks=/30,/64" > > >>> > > >>> > > >>> why do we need to specify mask lengths in the above ? > > >> Well, since we're hashing IP we have to know mask to cut > > >> host bits in advance. > > >> (And the real reason is that I'm too lazy to implement > > >> hierarchical matching (check /32, then /31, then /30) like > > >> how, for example, > > >> > > >> > > >> oh well for that we should use cidr:radix > > >> > > >> Research results have never shown a strong superiority of > > >> hierarchical hash tables over good radix implementations, > > >> and in those cases one usually adopts partial prefix > > >> expansion so you only have, say, masks that are a > > >> multiple of 2..8 bits so you only need a small number of > > >> hash lookups. > > > Definitely, especially for IPv6. So I was actually thinking > > > about covering some special sparse cases (e.g. someone having a > > > bunch of /32 and a bunch of /30 and that's all). > > > > > > Btw, since we're talking about "good radix implementation": what > > > license does DXR have? :) > > > Is it OK to merge it as another cidr implementation? > > > > > > "cidr" is a very ugly name, i'd rather use "addr" > > Ok, no problem with that. "addr" really sounds better. > > > > > > DXR has a bsd license and of course it is possible to use it. > > > You should ask Marko Zec for his latest version of the code > > > (and probably make sure we have one copy of the code in the source > > > tree). > > Great!. I'll ask him :) > > The so far cleanest DXR implementation is significantly C++ poluted and > wrapped inside Click glue (available here: http://www.nxab.fer.hr/dxr) > > I'll try to backport the fixes to the original C-only / BSD > implementation over the weekend and let you know how it goes... > > Marko > > > > > > > > Speaking of features, one thing that would be nice is the ability > > > for tables to reference the in-kernel tables (e.g. fibs, socket > > > lists, interface lists...), perhaps in readonly mode. > > > How complex do you think that would be ? > > Implementing algo support for particular provider like > > sockets/iflists shouldn't be hard. Most of the algorithms complexity > > lies in table modifications. Here we have to support > > lookup and dump operations, so it is the question of providing > > necessary bindings to existing mechanisms (via some direct binding or > > utilizing things like kernel_sysctl for dump support). > > > > It looks like the following maps well to current table concept: > > * such tables are not created by default > > * user issues > > `ipfw table kfib create type addr algo "addr:kernel fib=0"` > > or > > `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` > > or > > `ipfw table kiface create type iface algo "iface:kernel"` > > * tables have special "readonly" type, flush_all requests are ignored > > * no state stored internally > > > > So generic table handling code needs to be modified to support > > read-only tables (and making more callbacks optional). > > Additionally, we might need to proxy "info" request info algo > > callback (optional, "real" algorithms won't implement it) to be able > > to show number of items (and some other info) to user. > > > > > > > > > > > > cheers > > > luigi > > > > > > > ___ > > freebsd-...@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscr...@fr
Re: [CFT] new tables for ipfw
On 8/14/2014 08:08, Willem Jan Withagen wrote: > I've found the notation ipnr:something rather frustrating when using > ipv6 addresses. Sort of like typing a ipv6 address in a browser, the > last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. > compare > 2001:4cb8:3:1::1 > 2001:4cb8:3:1::1:80 > [2001:4cb8:3:1::1]:80 > The first and the last are the same host but a different port, the > middle one is just a different host. > > Could/should we do the same in ipfw? the first and second forms are valid, but as ipv6 addresses *with no port*, The third is an ipv6 address with a port. If the intent of the second form is an address and port, it will not be parsed that way by standard parsers and violates the ivp6 addressing rfc's. -lee ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14.08.2014 16:08, Willem Jan Withagen wrote: On 2014-08-14 13:15, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: On 14.08.2014 14:44, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: On 14.08.2014 13:23, Luigi Rizzo wrote: On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: Hello list. I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. this is a fantastic piece of work, thanks for doing it and for integrating the feedback. I have some detailed feedback that will send you privately, but just a curiosity: ... Some examples (see ipfw(8) manual page for the description): ... ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" why do we need to specify mask lengths in the above ? Well, since we're hashing IP we have to know mask to cut host bits in advance. (And the real reason is that I'm too lazy to implement hierarchical matching (check /32, then /31, then /30) like how, for example, oh well for that we should use cidr:radix Research results have never shown a strong superiority of hierarchical hash tables over good radix implementations, and in those cases one usually adopts partial prefix expansion so you only have, say, masks that are a multiple of 2..8 bits so you only need a small number of hash lookups. Definitely, especially for IPv6. So I was actually thinking about covering some special sparse cases (e.g. someone having a bunch of /32 and a bunch of /30 and that's all). Btw, since we're talking about "good radix implementation": what license does DXR have? :) Is it OK to merge it as another cidr implementation? "cidr" is a very ugly name, i'd rather use "addr" DXR has a bsd license and of course it is possible to use it. You should ask Marko Zec for his latest version of the code (and probably make sure we have one copy of the code in the source tree). Speaking of features, one thing that would be nice is the ability for tables to reference the in-kernel tables (e.g. fibs, socket lists, interface lists...), perhaps in readonly mode. How complex do you think that would be ? I'm a very happy user of ipfw and I think these are nice improvements and will make things more flexible... I have 2 nits to pick with the current version. I've found the notation ipnr:something rather frustrating when using ipv6 addresses. Sort of like typing a ipv6 address in a browser, the last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. compare 2001:4cb8:3:1::1 2001:4cb8:3:1::1:80 [2001:4cb8:3:1::1]:80 The first and the last are the same host but a different port, the middle one is just a different host. Could/should we do the same in ipfw? Well, we should, but I'm unsure if we have host:port notation anywhere in current (or new) syntax: And I keep running into the ipfw add deny all from table(50) to any notation. the ()'s need to be escaped in most any shell. Where as I look at the syntax there is little reason to require the ()'s. the keyword table always needs to be followed by a number (and in the new version a (word|number) ). We need _some_ discriminator to ensure that the next parameter after "to" or "from" is not hostname. We also have some other places where tables are used: "via interface|table(X)", lookup X, flow table(X) [new]. I agree that parenthesis might not be the best choice. (and something like :tablename:, %tablename%, or even table:tablename might look better). Theoretically, we can support both (old/new) and show rules with new one by default. Thanx for the nice work, --WjW ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14-8-2014 14:46, Lee Dilkie wrote: > > On 8/14/2014 08:08, Willem Jan Withagen wrote: >> I've found the notation ipnr:something rather frustrating when using >> ipv6 addresses. Sort of like typing a ipv6 address in a browser, the >> last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. >> compare >> 2001:4cb8:3:1::1 >> 2001:4cb8:3:1::1:80 >> [2001:4cb8:3:1::1]:80 >> The first and the last are the same host but a different port, the >> middle one is just a different host. >> >> Could/should we do the same in ipfw? > > the first and second forms are valid, but as ipv6 addresses *with no port*, > > The third is an ipv6 address with a port. > > If the intent of the second form is an address and port, it will not be > parsed that way by standard parsers and violates the ivp6 addressing rfc's. I agree, but ipfw does not understand [2001:4cb8:3:1::1] last time I tried. So I think you rephrased what I meant to say. Thanx, --WjW ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14-8-2014 17:20, Alexander V. Chernikov wrote: > On 14.08.2014 16:08, Willem Jan Withagen wrote: >> On 2014-08-14 13:15, Luigi Rizzo wrote: >>> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov < >>> melif...@yandex-team.ru> wrote: >>> On 14.08.2014 14:44, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov < melif...@yandex-team.ru> wrote: >On 14.08.2014 13:23, Luigi Rizzo wrote: > > > > > On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov < > melif...@yandex-team.ru> wrote: > >> Hello list. >> >> I've been hacking ipfw for a while and It seems there is something >> ready >> to test/review in projects/ipfw branch. >> > > this is a fantastic piece of work, thanks for doing it and for > integrating the feedback. > > I have some detailed feedback that will send you privately, > but just a curiosity: > >... >> >> Some examples (see ipfw(8) manual page for the description): >> >> >> ... >> >> >>ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" >> > > why do we need to specify mask lengths in the above ? > > Well, since we're hashing IP we have to know mask to cut host > bits in > advance. > (And the real reason is that I'm too lazy to implement hierarchical > matching (check /32, then /31, then /30) like how, for example, > oh well for that we should use cidr:radix Research results have never shown a strong superiority of hierarchical hash tables over good radix implementations, and in those cases one usually adopts partial prefix expansion so you only have, say, masks that are a multiple of 2..8 bits so you only need a small number of hash lookups. Definitely, especially for IPv6. So I was actually thinking about covering some special sparse cases (e.g. someone having a bunch of /32 and a bunch of /30 and that's all). Btw, since we're talking about "good radix implementation": what license does DXR have? :) Is it OK to merge it as another cidr implementation? >>> >>> "cidr" is a very ugly name, i'd rather use "addr" >>> >>> DXR has a bsd license and of course it is possible to use it. >>> You should ask Marko Zec for his latest version of the code >>> (and probably make sure we have one copy of the code in the source >>> tree). >>> >>> Speaking of features, one thing that would be nice is the ability >>> for tables to reference the in-kernel tables (e.g. fibs, socket >>> lists, interface lists...), perhaps in readonly mode. >>> How complex do you think that would be ? >> >> I'm a very happy user of ipfw and I think these are nice improvements >> and will make things more flexible... >> >> I have 2 nits to pick with the current version. >> >> I've found the notation ipnr:something rather frustrating when using >> ipv6 addresses. Sort of like typing a ipv6 address in a browser, the >> last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. >> compare >> 2001:4cb8:3:1::1 >> 2001:4cb8:3:1::1:80 >> [2001:4cb8:3:1::1]:80 >> The first and the last are the same host but a different port, the >> middle one is just a different host. >> >> Could/should we do the same in ipfw? > Well, we should, but I'm unsure if we have host:port notation anywhere > in current (or new) syntax: I can not answer that right from the top of my head. But I remember digging in the code to see how adresses were converted and how IPv6 fitted in there. And that because of the problem described above. But the main reason for "reporting" this, is that I forsee to possibility that with the new syntax it might be possible to run into this. But you have disgned the syntax, so I'll take your word for it that would not happen. >> And I keep running into the >> ipfw add deny all from table(50) to any >> notation. the ()'s need to be escaped in most any shell. Where as I >> look at the syntax there is little reason to require the ()'s. >> the keyword table always needs to be followed by a number (and in the >> new version a (word|number) ). > We need _some_ discriminator to ensure that the next parameter after > "to" or "from" is not hostname. > We also have some other places where tables are used: "via > interface|table(X)", lookup X, flow table(X) [new]. > I agree that parenthesis might not be the best choice. (and something > like :tablename:, %tablename%, or even table:tablename might look better). > Theoretically, we can support both (old/new) and show rules with new one > by default. (I'm looking at this from a parseable grammar view, perhaps not 100% fitting) Well my argument is that after the table-keyword "table" there would always be the table-identifier, be it a name or a number. So "table" is a reserved word,
Re: [CFT] new tables for ipfw
On 14-8-2014 17:53, Lee Dilkie wrote: > > On 8/14/2014 11:27 AM, Willem Jan Withagen wrote: >> On 14-8-2014 14:46, Lee Dilkie wrote: >>> On 8/14/2014 08:08, Willem Jan Withagen wrote: I've found the notation ipnr:something rather frustrating when using ipv6 addresses. Sort of like typing a ipv6 address in a browser, the last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. compare 2001:4cb8:3:1::1 2001:4cb8:3:1::1:80 [2001:4cb8:3:1::1]:80 The first and the last are the same host but a different port, the middle one is just a different host. Could/should we do the same in ipfw? >>> the first and second forms are valid, but as ipv6 addresses *with no port*, >>> >>> The third is an ipv6 address with a port. >>> >>> If the intent of the second form is an address and port, it will not be >>> parsed that way by standard parsers and violates the ivp6 addressing rfc's. >> I agree, but ipfw does not understand [2001:4cb8:3:1::1] last time I tried. >> So I think you rephrased what I meant to say. >> >> Thanx, >> --WjW >> > > and re-reading your original post, yes you did state it correctly. > > ipfw needs to be fixed to understand the correct format of ipv6 addresses. > > however, this isn't the only offender. netstat's output is also > incorrect (linux example) > > > tcp0 0 :::22 > :::*LISTEN > > should be > > tcp0 0 [::]:22 > [::]:*LISTEN > > I don't understand why folks dream up incompatible, and unparsable, ipv6 > address formats. Why bother with rfc's if no-one writes to them. > > (see rfc5952) It think that that was the RFC I found when looking into getting the browser to do the right thing when I want it to go to: [2001:4cb8:3:1::1]:8080 Well the RFC would be an argument to at least spec an IPv6 address in a ipfw rule to be allowed either with or without []'s. And if you run into trouble by not using the []'s, they are "easily" added. --WjW ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14-8-2014 17:20, Alexander V. Chernikov wrote: >> I've found the notation ipnr:something rather frustrating when using >> ipv6 addresses. Sort of like typing a ipv6 address in a browser, the >> last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. >> compare >> 2001:4cb8:3:1::1 >> 2001:4cb8:3:1::1:80 >> [2001:4cb8:3:1::1]:80 >> The first and the last are the same host but a different port, the >> middle one is just a different host. >> >> Could/should we do the same in ipfw? > Well, we should, but I'm unsure if we have host:port notation anywhere > in current (or new) syntax: I now remember the case, sort of I think: When using an IPv6 address the last time I ran into the snag with: (From the ipfw(8) manual) ip-addr: addr:mask Matches all addresses with base addr (specified as an IP address, a network number, or a hostname) and the mask of mask, specified as a dotted quad. As an example, 1.2.3.4:255.0.255.0 or 1.0.3.0:255.0.255.0 will match 1.*.3.*. This form is advised only for non-contiguous masks. It is better to resort to the addr/masklen format for contiguous masks, which is more compact and less Which tried to use the last quad of an IPv6 adress in a very convoluted case, which I cannot reproduce any longer. Reading the manual, one of my problems is now clearly a RTFM: how to use ftp-data in a rule without the complaint that data is not a valid port-name. :) again something learned. --WjW ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 8/14/2014 11:27 AM, Willem Jan Withagen wrote: > On 14-8-2014 14:46, Lee Dilkie wrote: >> On 8/14/2014 08:08, Willem Jan Withagen wrote: >>> I've found the notation ipnr:something rather frustrating when using >>> ipv6 addresses. Sort of like typing a ipv6 address in a browser, the >>> last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. >>> compare >>> 2001:4cb8:3:1::1 >>> 2001:4cb8:3:1::1:80 >>> [2001:4cb8:3:1::1]:80 >>> The first and the last are the same host but a different port, the >>> middle one is just a different host. >>> >>> Could/should we do the same in ipfw? >> the first and second forms are valid, but as ipv6 addresses *with no port*, >> >> The third is an ipv6 address with a port. >> >> If the intent of the second form is an address and port, it will not be >> parsed that way by standard parsers and violates the ivp6 addressing rfc's. > I agree, but ipfw does not understand [2001:4cb8:3:1::1] last time I tried. > So I think you rephrased what I meant to say. > > Thanx, > --WjW > and re-reading your original post, yes you did state it correctly. ipfw needs to be fixed to understand the correct format of ipv6 addresses. however, this isn't the only offender. netstat's output is also incorrect (linux example) tcp0 0 :::22 :::*LISTEN should be tcp0 0 [::]:22 [::]:*LISTEN I don't understand why folks dream up incompatible, and unparsable, ipv6 address formats. Why bother with rfc's if no-one writes to them. (see rfc5952) -lee ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: [CFT] new tables for ipfw
On 14.08.2014 15:52, Alexander V. Chernikov wrote: > On 14.08.2014 15:15, Luigi Rizzo wrote: >> >> >> >> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov >> mailto:melif...@yandex-team.ru>> wrote: >> >> On 14.08.2014 14:44, Luigi Rizzo wrote: >>> >>> >>> >>> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov >>> mailto:melif...@yandex-team.ru>> wrote: >>> >>> On 14.08.2014 13:23, Luigi Rizzo wrote: On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov mailto:melif...@yandex-team.ru>> wrote: Hello list. I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. this is a fantastic piece of work, thanks for doing it and for integrating the feedback. I have some detailed feedback that will send you privately, but just a curiosity: ... Some examples (see ipfw(8) manual page for the description): ... ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" why do we need to specify mask lengths in the above ? >>> Well, since we're hashing IP we have to know mask to cut >>> host bits in advance. >>> (And the real reason is that I'm too lazy to implement >>> hierarchical matching (check /32, then /31, then /30) like >>> how, for example, >>> >>> >>> oh well for that we should use cidr:radix >>> >>> Research results have never shown a strong superiority of >>> hierarchical hash tables over good radix implementations, >>> and in those cases one usually adopts partial prefix >>> expansion so you only have, say, masks that are a >>> multiple of 2..8 bits so you only need a small number of >>> hash lookups. >> Definitely, especially for IPv6. So I was actually thinking about >> covering some special sparse cases (e.g. someone having a bunch >> of /32 and a bunch of /30 and that's all). >> >> Btw, since we're talking about "good radix implementation": what >> license does DXR have? :) >> Is it OK to merge it as another cidr implementation? >> >> >> "cidr" is a very ugly name, i'd rather use "addr" > Ok, no problem with that. "addr" really sounds better. >> >> DXR has a bsd license and of course it is possible to use it. >> You should ask Marko Zec for his latest version of the code >> (and probably make sure we have one copy of the code in the source tree). > Great!. I'll ask him :) >> >> Speaking of features, one thing that would be nice is the ability >> for tables to reference the in-kernel tables (e.g. fibs, socket >> lists, interface lists...), perhaps in readonly mode. >> How complex do you think that would be ? Well, the most major problem is that tables handling code assumed that we do known number of items in advance, and since we're holding locks it won't change, so we don't need large contigious buffer to dump data to. This is not the case with "external" tables, so we can't _reliably_ dump them (the same situation as in case of dynamic states). Anyway, I've added cidr:kfib algo ( http://svnweb.freebsd.org/base?view=revision&revision=270001 ) and it looks funny. Quoting commit message: # ipfw table fib2 create algo "cidr:kfib fib=2" # ipfw table fib2 info +++ table(fib2), set(0) +++ kindex: 2, type: cidr, locked valtype: number, references: 0 algorithm: cidr:kfib fib=2 items: 11, size: 288 # ipfw table fib2 list +++ table(fib2), set(0) +++ 10.0.0.0/24 0 127.0.0.1/32 0 ::/96 0 ::1/128 0 :::0.0.0.0/96 0 2a02:978:2::/112 0 fe80::/10 0 fe80:1::/64 0 fe80:2::/64 0 fe80:3::/64 0 ff02::/16 0 # ipfw table fib2 lookup 10.0.0.5 10.0.0.0/24 0 # ipfw table fib2 lookup 2a02:978:2::11 2a02:978:2::/112 0 # ipfw table fib2 detail +++ table(fib2), set(0) +++ kindex: 2, type: cidr, locked valtype: number, references: 0 algorithm: cidr:kfib fib=2 items: 11, size: 288 IPv4 algorithm radix info items: 0 itemsize: 200 IPv6 algorithm radix info items: 0 itemsize: 200 > Implementing algo support for particular provider like sockets/iflists > shouldn't be hard. Most of the algorithms complexity lies in table > modifications. Here we have to support > lookup and dump operations, so it is the question of providing > necessary bindings to existing mechanisms (via some direct binding or > utilizing things like kernel_sysctl for dump support). > > It looks like the following maps well to current table concept: > * such tables are not created by default > * user issues > `ipfw table kfib create type addr algo "addr:kernel fib=0"` > or > `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` > or > `ipfw table kifa
RE: Re: [CFT] new tables for ipfw
NB: Please CC me on replies, I'm off-list > On 14-8-2014 14:46, Lee Dilkie wrote: >> >> On 8/14/2014 08:08, Willem Jan Withagen wrote: >>> I've found the notation ipnr:something rather frustrating when using >>> ipv6 addresses. Sort of like typing a ipv6 address in a browser, the >>> last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. >>> compare >>> 2001:4cb8:3:1::1 >>> 2001:4cb8:3:1::1:80 >>> [2001:4cb8:3:1::1]:80 >>> The first and the last are the same host but a different port, the >>> middle one is just a different host. >>> >>> Could/should we do the same in ipfw? >> >> the first and second forms are valid, but as ipv6 addresses *with no port*, >> >> The third is an ipv6 address with a port. >> >> If the intent of the second form is an address and port, it will not be >> parsed that way by standard parsers and violates the ivp6 addressing rfc's. > > I agree, but ipfw does not understand [2001:4cb8:3:1::1] last time I tried. > So I think you rephrased what I meant to say. Might want to have a look at IPv6 address validators. Execute on FreeBSD 9.3 or 10.1: bsdconfig includes -adF 'ip.*6' | less -R Or on FreeBSD 9.2 or 10.0: less '+/ip[^ ]*6' /usr/share/bsdconfig/media/tcpip.subr less '+/ip[^ ]*6' /usr/share/bsdconfig/networking/ipaddr.subr (output from 9.3 command pasted below) dte...@scribe9.vicor.com ~ $ bsdconfig includes -dF 'ip.*6' >>> Functions in media/tcpip.subr matching `ip.*6': + f_validate_ipaddr6 $ipv6_addr Returns zero if the given argument (an IPv6 address) is of the proper format. The return status for invalid IP address is one of: 1 One or more individual segments within the IP address (separated by colons) contains one or more invalid characters. Segments must contain only combinations of the characters 0-9, A-F, or a-f. 2 Too many/incorrect null segments. A single null segment is allowed within the IP address (separated by colons) but not allowed at the beginning or end (unless a double-null segment; i.e., "::*" or "*::"). 3 One or more individual segments within the IP address (separated by colons) exceeds the length of 4 hex-digits. 4 The IP address entered has either too few (less than 3), too many (more than 8), or not enough segments, separated by colons. 5* The IPv4 address at the end of the IPv6 address is invalid. * When there is an error with the dotted-quad IPv4 address at the end of the IPv6 address, the return value of 5 is OR'd with a bit-shifted (<< 4) return of f_validate_ipaddr. >>> Functions in networking/ipaddr.subr matching `ip.*6': + f_dialog_ip6error $error $ipv6_addr Display a msgbox with the appropriate error message for an error returned by the f_validate_ipaddr6 function above. + f_dialog_validate_ipaddr6 $ipv6_addr Returns zero if the given argument (an IPv6 address) is of the proper format. If the IP address is determined to be invalid, the appropriate error will be displayed using the f_dialog_ip6error function above. (end pasted output) Yes, the code is shell. But you can trivially convert the logic into something like C using nothing more than strchr, strlen, and fnmatch. -- Devin ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
