ipfw table add problem

[Ian Lepore]

On Fri, 2013-11-22 at 11:35 +1100, Mark Andrews wrote:
> In message <1385045442.31172.549.camel at revolution.hippie.lan>, Ian Lepore writes:
> > On Tue, 2013-11-19 at 23:26 +0200, =D6zkan KIRIK wrote:
> > > On Tue, Nov 19, 2013 at 11:21 PM, Andreas Nilsson <andrnils at gmail.com>wro=
> > te:
> > > =
> > 
> > > >
> > > >
> > > >
> > > > On Tue, Nov 19, 2013 at 9:36 PM, =D6zkan KIRIK <ozkan.kirik at gmail.com>w=
> > rote:
> > > >
> > > >> Hi,
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Nov 19, 2013 at 10:22 PM, Andreas Nilsson <andrnils at gmail.com>=
> > wrote:
> > > >>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Tue, Nov 19, 2013 at 8:55 PM, =D6zkan KIRIK <ozkan.kirik at gmail.com=
> > >wrote:
> > > >>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> I'm using kernel FreeBSD 10.0-BETA3 #2 r257635 kernel.
> > > >>>> I am trying to add port number to ipfw tables. But there is something
> > > >>>> strange :
> > > >>>> Problem is easily repeatable.
> > > >>>>
> > > >>>> #ipfw table 1 flush
> > > >>>> #ipfw table 1 add 4899
> > > >>>> #ipfw table 1 list
> > > >>>> ::/0 0
> > > >>>>
> > > >>> Works with ipfw table 1 add 0 4899
> > > >>>
> > > >> No, i want to use this table as port list ( to use with "lookup src-po=
> > rt
> > > >> 1" ) . If you add like this, you cannot match against ports. Am I wron=
> > g?
> > > >>
> > > > No, that should be possible.
> > > >
> > > >>
> > > >>
> > > >>>
> > > >>>> #ipfw table 1 flush
> > > >>>> #ipfw table 1 add 10.2.3.01       ( not 10.0.0.1,   the last 1 has 0=
> >  as
> > > >>>> prefix )
> > > >>>> #ipfw table 1 list
> > > >>>> ::/0 0
> > > >>>>
> > > >>> Did you mean ipfw table 1 add 10.2.3.0 1 ? That works for me.
> > > >>>
> > > >> Please dont leave spaces between 0 and 1.
> > > >>
> > > > Ok. any specific reason to type it as 10.2.3.01 instead 0f 10.2.3.1 ?
> > > >
> > > There is no specific reason, but both 10.2.3.01 and 10.2.3.1 are has true
> > > syntax.
> > > The problem is, ipfw doesnt throw any errors, but record added as
> > > 0.0.0.0/0( all the IPv4 network ). This behaviour is really dangerous.
> > > =
> > 
> > > FreeBSD 8.2 and 8.4 doesnt have this problem.
> > 
> > For this, I wonder if ipfw was recently changed from using inet_aton()
> > to inet_pton() to parse addresses?  Our implementation of inet_pton()
> > does not match the manpage -- it's supposed to accept decimal, octal, or
> > hex numbers for each of the dotted IP comonents, but it accepts decimal
> > only.  10.2.3.01 appears to cause it to return 0 as the address.  Our
> > inet_aton() handles oct/dec/hex.
> 
> The man page is wrong.
> 
> RFC 3493 states inet_pton *only* takes dotted decimal.  This was
> the same in RFC 2553.  The implementation Paul Vixie and I wrote
> back in 199[89] for BIND only accepts dotted decimal with no leading
> zeros.

Actually, it was me that was wrong... the man page does mention the
differences between inet_aton() and inet_pton(), I just didn't read all
the way to the end.

-- Ian