Re: [CFT] new tables for ipfw
On Wed, Aug 13, 2014 at 1:15 PM, Alexander V. Chernikov melif...@yandex-team.ru wrote: I've been hacking ipfw for a while and It seems there is something ready to test/review in projects/ipfw branch. Отличная работа! Thanks so much. Copious examples will be helpful - the ipfw man page is already too huge, and ipfw merits an entire guide on its own, with examples. I'm volunteering, but the new features will be - well, new. - M ___ 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 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru wrote: On 14.08.2014 15:15, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 Thu, Aug 14, 2014 at 5:08 AM, Marko Zec z...@fer.hr wrote: On Thu, 14 Aug 2014 15:52:34 +0400 Alexander V. Chernikov melif...@yandex-team.ru wrote: On 14.08.2014 15:15, Luigi Rizzo wrote: On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org The link is http://www.nxlab.fer.hr/dxr/ Thank you very much . Mehmet Erol Sanliturk
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: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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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 melif...@yandex-team.ru 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=revisionrevision=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 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
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
