Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Nov 2013 11:18:05 +1100
From:      Mark Andrews <marka@isc.org>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        "Alexander V. Chernikov" <melifaro@FreeBSD.org>, Ian Smith <smithi@nimnet.asn.au>, freebsd-ipfw <freebsd-ipfw@FreeBSD.org>, freebsd-stable <freebsd-stable@FreeBSD.org>, Luigi Rizzo <rizzo@iet.unipi.it>, =?ISO-8859-1?Q?=D6zkan?= KIRIK <ozkan.kirik@gmail.com>
Subject:   Re: ipfw table add problem
Message-ID:  <20131126001806.27951AD3DBF@rock.dv.isc.org>
In-Reply-To: Your message of "Mon, 25 Nov 2013 08:02:58 -0700." <1385391778.1220.4.camel@revolution.hippie.lan>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

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

Mark

> -- Ian
> 
> 
> 
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131126001806.27951AD3DBF>