Hello everyone.
Final patch version now uses single IP_FW3 socket option.
Together with other changes this makes me think such changes should be
reviewed by a wider number of people. If there are no
objections/comments I plan to commit this on tuesday.
Changes:
* Tables (actually, radix trees)
On 25. Dec 2011, at 14:59 , Alexander V. Chernikov wrote:
Hello everyone.
Final patch version now uses single IP_FW3 socket option.
Together with other changes this makes me think such changes should be
reviewed by a wider number of people. If there are no
objections/comments I plan to
Hi Alexander,
Changes:
* Tables (actually, radix trees) are now created/freed on demand.
Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily
high number that would allow flexible numbering of tables? Arbitrarily
high being 0x or some other nice large number that
On 25. Dec 2011, at 17:47 , Pawel Tyll wrote:
Hi Alexander,
Changes:
* Tables (actually, radix trees) are now created/freed on demand.
Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily
high number that would allow flexible numbering of tables? Arbitrarily
high being
Bjoern A. Zeeb wrote:
On 25. Dec 2011, at 17:47 , Pawel Tyll wrote:
Hi Alexander,
Changes:
* Tables (actually, radix trees) are now created/freed on demand.
Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily
high number that would allow flexible numbering of tables?
On 25. Dec 2011, at 18:55 , Alexander V. Chernikov wrote:
Bjoern A. Zeeb wrote:
On 25. Dec 2011, at 17:47 , Pawel Tyll wrote:
Hi Alexander,
Changes:
* Tables (actually, radix trees) are now created/freed on demand.
Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily
On Sun, Dec 25, 2011 at 10:55:22PM +0400, Alexander V. Chernikov wrote:
Bjoern A. Zeeb wrote:
On 25. Dec 2011, at 17:47 , Pawel Tyll wrote:
Hi Alexander,
Changes:
* Tables (actually, radix trees) are now created/freed on demand.
Does this mean IPFW_TABLES_MAX can now be safely
At the moment maximum number of tables remains the same however it is
now possible to define IPFW_TABLES_MAX to 65k without much (memory)
overhead. Since pointer to tables are stored in array, defining 2^32
tables require 4G * (8+8+1) memory for pointers only.
65k is also a good amount.
On Sun, Dec 18, 2011 at 03:58:30PM +0400, Alexander V. Chernikov wrote:
Pawel Tyll wrote:
Hi lists,
Are there any plans to implement IPv6 tables in ipfw? It would seem
that our gov. may want to force us into IPv6 in 6 months ;)
I've got working implementation for IPv4+IPv6 and
Hi lists,
Are there any plans to implement IPv6 tables in ipfw? It would seem
that our gov. may want to force us into IPv6 in 6 months ;)
Cheers.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To
Pawel Tyll wrote:
Hi lists,
Are there any plans to implement IPv6 tables in ipfw? It would seem
that our gov. may want to force us into IPv6 in 6 months ;)
I've got working implementation for IPv4+IPv6 and interface tables:
15:56 [0] zfsbase# /usr/obj/usr/src/sbin/ipfw/ipfw table 2 list
Hi Alexander,
I've got working implementation for IPv4+IPv6 and interface tables:
Lately every time I have some kind of problem, you come with a
solution ready :
Thanks for the heads-up!
___
freebsd-net@freebsd.org mailing list
On Sun, Dec 18, 2011 at 3:58 AM, Alexander V. Chernikov
melif...@freebsd.org wrote:
Pawel Tyll wrote:
Hi lists,
Are there any plans to implement IPv6 tables in ipfw? It would seem
that our gov. may want to force us into IPv6 in 6 months ;)
I've got working implementation for IPv4+IPv6 and
13 matches
Mail list logo
