ipfw table add problem
Michael Butler
imb at protected-networks.net
Tue Nov 26 00:31:22 UTC 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/25/13 19:18, Mark Andrews wrote:
>
> In message <1385391778.1220.4.camel at 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-----
More information about the freebsd-stable
mailing list