Date: Sat, 17 May 2014 17:44:37 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: Dennis Yusupoff <dyr@smartspb.net>, FreeBSD Net <freebsd-net@freebsd.org>, Marcelo Gondim <gondim@bsdinfo.com.br> Subject: Re: Problem with ipfw table add 0.0.0.0/8 Message-ID: <537767C5.80205@FreeBSD.org> In-Reply-To: <53720AA4.80909@smartspb.net> References: <5371084F.1060009@bsdinfo.com.br> <F78BF3AC-F031-4528-A4C1-5B22E88CEC00@dataix.net> <5371112B.2030209@bsdinfo.com.br> <5371E9E7.70400@smartspb.net> <5371F4C8.3080501@FreeBSD.org> <53720AA4.80909@smartspb.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13.05.2014 16:05, Dennis Yusupoff wrote: > I think that universal table for all kind of data (ipv4, ipv6, ports, > etc) is a bad idea by design. At least unless you haven't any ability to It is not always "universal" in kernel. Actually, different radix tables are used to store both IPv4 and IPv6 in single table. > specify address family on add, to avoid attempts to guess what user > meant. Something like "ipfw table X add DEEF.DE ipv6". I'm going to add explicit table type/naming setup soon. Idea is the following: 1) Existing table can be named and addressed by either number or name. However, you still need to assign table number manually. 2) Table type/name can be specified explicitly via one of the following commands: * ipfw table 1 create [type <cidr|u32|ifindex|iface>] [name "table_name"] * ipfw table <num|name> name "table_name" * ipfw table "table_name" type <cidr|u32|ifindex|iface> 3) ipfw(8) stops trying to guess appropriate type based on used value. Instead, it requests table type from kernel and interprets value according to returned type. Default type for all tables is cidr 4) Table(s) can be returned to default values using ipfw table <num|all|name> destroy. Destroy means: * flush * table tries (or other structures) freed * type set to cidr > > > 13.05.2014 14:32, Alexander V. Chernikov пишет: >> On 13.05.2014 13:46, Dennis Yusupoff wrote: >>> May be this will help? See answer on >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/189471 >> I'll try to fix it within a few days. Fixed in r266310. >> >> The problem itself happens due to the fact that every CIDR table >> address is packed into IPv6 address and IPv4 ones are encoded as >> deprecated IPv6-compatible ones. >> this leads to the problems with decoding things like 0/X or ::1
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?537767C5.80205>