ipfw table add problem
Ian Lepore
ian at FreeBSD.org
Mon Nov 25 15:03:05 UTC 2013
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, Özkan 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 mentioned
> > 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.
-- Ian
More information about the freebsd-stable
mailing list