Date: Mon, 25 Nov 2013 19:31:18 -0500 From: Michael Butler <imb@protected-networks.net> To: freebsd-stable@freebsd.org Subject: Re: ipfw table add problem Message-ID: <5293EBD6.8010009@protected-networks.net> In-Reply-To: <20131126001806.27951AD3DBF@rock.dv.isc.org> References: <CAAcX-AGDZbFn5RmhLBBn2PPWRPcsFUnea5MgTc7nuXGD8Ge53A@mail.gmail.com> <52911993.8010108@ipfw.ru> <CAAcX-AEt_i8RUfmMy6WLnER0X=uLk5A1=oj911k-nyMJEghRLw@mail.gmail.com> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/25/13 19:18, Mark Andrews wrote: > > In message <1385391778.1220.4.camel@revolution.hippie.lan>, Ian Lepore writes: >> On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: >>> On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: >>> > On 24.11.2013 19:43, =D6zkan KIRIK wrote: >>> > > Hi, >>> > > = >> >>> > > I tested patch. This patch solves, ipfw table 1 add 4899 >>> > Ok. So I'll commit this fix soon. >>> > > = >> >>> > > But, ipfw table 1 add 10.2.3.01 works incorrectly. >>> > > output is below. >>> > > # ./ipfw table 1 flush >>> > > # ./ipfw table 1 add 10.2.3.01 >>> > inet_pton() does not recognize this as valid IPv4 address, so it is >>> > treated as usigned unteger key. It looks like this behavior is mention= >> ed >>> > in STANDARDS section. >>> > > # ./ipfw table 1 list >>> > > 0.0.0.10/32 0 >>> = >> >>> I'm wondering if "so don't do that" is really sufficient to deal with = >> >>> this? If it's not recognised as a valid address, shouldn't it fail to = >> >>> add anything, with a complaint? I don't see how a string containing = >> >>> dots can be seen as a valid unsigned integer? >> >> It's still not clear to me that inet_pton() is doing the right thing. >> Per the rfc cited earlier in the thread, it's not supposed to interpret >> the digits as octal or hex -- they are specifically declared to be >> decimal numbers. There's nothing invalid about "01" as a decimal >> number. The fact that many of us have a C-programming background and >> tend to think of leading-zero as implying octal doesn't change that. > > But it does result in unexpected results when there is code that > does treat 070 as 56 not 70. Rejecting ambigious input is a good > thing. Part of what inet_pton() was trying to do was to get rid > of the ambiguity in address inputs by tightening up the specification. > > 10.2.3.70 is not ambigious > 10.2.3.070 is ambigious > When the "STANDARDS" section of the inet_pton() man page explicitly defines the interpretation to be decimal, its rejection of a leading zero or misinterpretation as octal defies that definition. It does not say "decimal except when a leading zero is present". As long as the input string can be be properly interpreted as a decimal number, it should be. Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a warning from either inet_pton() or ipfw is an egregious breach of POLA, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKT69YACgkQQv9rrgRC1JKNKgCgj4WOaZ4neyDEdkbVyVDqoKbz vf8AnRV3uv/LCzO+OjXiIGA6S8eGQqAm =tjly -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5293EBD6.8010009>