From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 00:31:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AAFA73D for ; Tue, 26 Nov 2013 00:31:22 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1184D2511 for ; Tue, 26 Nov 2013 00:31:21 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 83CB96132 for ; Mon, 25 Nov 2013 19:31:20 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Zyk8m/SzqgOjsj1oCxeRsMuKSUki0KIDm8qeECZ9rI2vIICJGNqQRZ1bdLIxdy/ge eZFH3/UvL2ehU6UZNck0Gn7a5yJvebwe42avzn8ebGDzOAgBDUFX6CP/pFMPi4i Message-ID: <5293EBD6.8010009@protected-networks.net> Date: Mon, 25 Nov 2013 19:31:18 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ipfw table add problem References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> In-Reply-To: <20131126001806.27951AD3DBF@rock.dv.isc.org> X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 00:31:22 -0000 -----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-----