ipfw table add problem
Mark Andrews
marka at isc.org
Tue Nov 26 00:18:23 UTC 2013
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
Mark
> -- Ian
>
>
>
>
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the freebsd-ipfw
mailing list