From owner-freebsd-stable@FreeBSD.ORG Fri Nov 22 00:36:05 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 810F1394; Fri, 22 Nov 2013 00:36:05 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12EDA2571; Fri, 22 Nov 2013 00:36:04 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 80F6523839C; Fri, 22 Nov 2013 00:35:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9717916042E; Fri, 22 Nov 2013 00:42:38 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id DF5F51603E9; Fri, 22 Nov 2013 00:42:37 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8D5B8AB6EA6; Fri, 22 Nov 2013 11:35:38 +1100 (EST) To: Ian Lepore From: Mark Andrews References: <1385045442.31172.549.camel@revolution.hippie.lan> Subject: Re: ipfw table add problem In-reply-to: Your message of "Thu, 21 Nov 2013 07:50:42 -0700." <1385045442.31172.549.camel@revolution.hippie.lan> Date: Fri, 22 Nov 2013 11:35:38 +1100 Message-Id: <20131122003538.8D5B8AB6EA6@rock.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mx.ams1.isc.org Cc: freebsd-ipfw , Luigi Rizzo , freebsd-stable , =?ISO-8859-1?Q?=D6zkan?= KIRIK , Andreas Nilsson X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 00:36:05 -0000 In message <1385045442.31172.549.camel@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 wro= > te: > > = > > > > > > > > > > > > > On Tue, Nov 19, 2013 at 9:36 PM, =D6zkan KIRIK w= > rote: > > > > > >> Hi, > > >> > > >> > > >> > > >> On Tue, Nov 19, 2013 at 10:22 PM, Andreas Nilsson = > wrote: > > >> > > >>> > > >>> > > >>> > > >>> On Tue, Nov 19, 2013 at 8:55 PM, =D6zkan KIRIK >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-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