In message <1385045442.31172.549.ca...@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 <andrn...@gmail.com>wro= > te: > > = > > > > > > > > > > > > > On Tue, Nov 19, 2013 at 9:36 PM, =D6zkan KIRIK <ozkan.ki...@gmail.com>w= > rote: > > > > > >> Hi, > > >> > > >> > > >> > > >> On Tue, Nov 19, 2013 at 10:22 PM, Andreas Nilsson <andrn...@gmail.com>= > wrote: > > >> > > >>> > > >>> > > >>> > > >>> On Tue, Nov 19, 2013 at 8:55 PM, =D6zkan KIRIK <ozkan.ki...@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. Mark > -- Ian > > > _______________________________________________ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"