From owner-freebsd-ipfw@FreeBSD.ORG Sun Nov 24 15:43:23 2013 Return-Path: Delivered-To: freebsd-ipfw@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 600C7DB4; Sun, 24 Nov 2013 15:43:23 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCB32267C; Sun, 24 Nov 2013 15:43:22 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id n12so1850662wgh.14 for ; Sun, 24 Nov 2013 07:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ce1rm9lEZ8IiSIg+MfBASYXQY2V87SpHFLCEGFqIBqM=; b=Ji6FrspQk7GgBlwzvJJ3nYH1bsdVhiLvJtR92mA/IKNG5Jhx02e+trBlEJ2EjW+IYl s3fSWQSCA3f7tZuwvMI6TBJR+IkV81o49qyOudnEVGcsra0u28mMycKSMlIgjzez7gMR cXz/nnRGZOygtq63IvkECdao7r5EDQH9e693Y+8jkHSioEFnBURFn+AFW8rleq6jkcA3 OxUWFG9CFjcH23kHjGesSfspuwxfTIqYXAhALgMuPUwaMQtBjQ1SwlDvzuBzs5gmhKZP Xw1Yy/vO+BM64mYq38xE0IUxGnuhUiUnrmH5JwXkWGALtA3bZgnifmSt7C2K11OIVffU 1uIw== MIME-Version: 1.0 X-Received: by 10.180.103.233 with SMTP id fz9mr10340533wib.20.1385307801283; Sun, 24 Nov 2013 07:43:21 -0800 (PST) Received: by 10.216.119.200 with HTTP; Sun, 24 Nov 2013 07:43:21 -0800 (PST) In-Reply-To: <52911993.8010108@ipfw.ru> References: <52911993.8010108@ipfw.ru> Date: Sun, 24 Nov 2013 17:43:21 +0200 Message-ID: Subject: Re: ipfw table add problem From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-ipfw , freebsd-stable , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 15:43:23 -0000 Hi, I tested patch. This patch solves, ipfw table 1 add 4899 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 # ./ipfw table 1 list 0.0.0.10/32 0 On Sat, Nov 23, 2013 at 11:09 PM, Alexander V. Chernikov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 19.11.2013 23:55, =EF=BF=96zkan 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 > > > > #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 > > > > #ipfw table 1 delete ::/0 ipfw: setsockopt(IP_FW_TABLE_XDEL): No > > such process > > > > > > I guess that, this problem is related to radix mask calculation > > problem/fix. > Hello. > I'm sorry, it seems that key lookups were broken for quite a long time. > > Can you apply attached patch, rebuild ipfw(8) binary and see if this > helps? > > > > > > Is there a quick solution for this. Best, regards, > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To > > unsubscribe, send any mail to > > "freebsd-ipfw-unsubscribe@freebsd.org" > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (FreeBSD) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlKRGZIACgkQwcJ4iSZ1q2n0hgCgkiqRewC61LptUaG4ejvHIg0q > PawAoID3nfNxh3sTOVE/iKNtfjHpl9u0 > =3D6GdO > -----END PGP SIGNATURE----- > From owner-freebsd-ipfw@FreeBSD.ORG Sun Nov 24 19:56:51 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96370D7A; Sun, 24 Nov 2013 19:56:51 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 573412259; Sun, 24 Nov 2013 19:56:51 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Vkbzc-0005cS-6U; Sun, 24 Nov 2013 19:53:04 +0400 Message-ID: <529259DE.2040701@FreeBSD.org> Date: Sun, 24 Nov 2013 23:56:14 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130728 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Subject: Re: ipfw table add problem References: <52911993.8010108@ipfw.ru> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2JKWEJWRTHEUCKVBDGILP" Cc: freebsd-ipfw , freebsd-stable , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 19:56:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JKWEJWRTHEUCKVBDGILP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24.11.2013 19:43, =C3=96zkan KIRIK wrote: > Hi, >=20 > I tested patch. This patch solves, ipfw table 1 add 4899 Ok. So I'll commit this fix soon. >=20 > 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 >=20 >=20 >=20 >=20 > On Sat, Nov 23, 2013 at 11:09 PM, Alexander V. Chernikov > wrote: >=20 > On 19.11.2013 23:55, =EF=BF=96zkan 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 >>>> >>>> #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 >>>> >>>> #ipfw table 1 delete ::/0 ipfw: setsockopt(IP_FW_TABLE_XDEL): No >>>> such process >>>> >>>> >>>> I guess that, this problem is related to radix mask calculation >>>> problem/fix. > Hello. > I'm sorry, it seems that key lookups were broken for quite a long time.= >=20 > Can you apply attached patch, rebuild ipfw(8) binary and see if this > helps? >=20 >=20 >>>> >>>> Is there a quick solution for this. Best, regards, >>>> _______________________________________________ >>>> freebsd-ipfw@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To >>>> unsubscribe, send any mail to >>>> "freebsd-ipfw-unsubscribe@freebsd.org" >>>> >=20 >> > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"= >=20 ------enig2JKWEJWRTHEUCKVBDGILP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKSWeMACgkQwcJ4iSZ1q2njZACfdD3Slr+nei3etHXm83sRilmD 2hoAoICRbULOBCyJMBFXqMW6but3XSS4 =FFua -----END PGP SIGNATURE----- ------enig2JKWEJWRTHEUCKVBDGILP-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 25 04:31:26 2013 Return-Path: Delivered-To: freebsd-ipfw@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 A077589C; Mon, 25 Nov 2013 04:31:26 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C352293D; Mon, 25 Nov 2013 04:31:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id rAP4UQqj028170; Mon, 25 Nov 2013 15:30:26 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 25 Nov 2013 15:30:26 +1100 (EST) From: Ian Smith To: "Alexander V. Chernikov" Subject: Re: ipfw table add problem In-Reply-To: <529259DE.2040701@FreeBSD.org> Message-ID: <20131125152238.S78756@sola.nimnet.asn.au> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-ipfw , Luigi Rizzo , freebsd-stable X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 04:31:26 -0000 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? cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 25 11:06:51 2013 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED52155F for ; Mon, 25 Nov 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC21B2F49 for ; Mon, 25 Nov 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAPB6oQd089887 for ; Mon, 25 Nov 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAPB6oF4089885 for freebsd-ipfw@FreeBSD.org; Mon, 25 Nov 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Nov 2013 11:06:50 GMT Message-Id: <201311251106.rAPB6oF4089885@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 42 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 25 15:03:05 2013 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AB1D428; Mon, 25 Nov 2013 15:03:05 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5ED1A2FF7; Mon, 25 Nov 2013 15:03:05 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vkxgm-000NtG-Fv; Mon, 25 Nov 2013 15:03:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAPF2w68004656; Mon, 25 Nov 2013 08:02:58 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX187EZWJOYy3dfW2L8BSCaSJ Subject: Re: ipfw table add problem From: Ian Lepore To: Ian Smith In-Reply-To: <20131125152238.S78756@sola.nimnet.asn.au> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 25 Nov 2013 08:02:58 -0700 Message-ID: <1385391778.1220.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id rAPF2w68004656 Cc: freebsd-ipfw , "Alexander V. Chernikov" , Luigi Rizzo , freebsd-stable X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 15:03:05 -0000 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, > > >=20 > > > I tested patch. This patch solves, ipfw table 1 add 4899 > > Ok. So I'll commit this fix soon. > > >=20 > > > 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 menti= oned > > in STANDARDS section. > > > # ./ipfw table 1 list > > > 0.0.0.10/32 0 >=20 > I'm wondering if "so don't do that" is really sufficient to deal with=20 > this? If it's not recognised as a valid address, shouldn't it fail to=20 > add anything, with a complaint? I don't see how a string containing=20 > 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 From owner-freebsd-ipfw@FreeBSD.ORG Tue Nov 26 00:18:23 2013 Return-Path: Delivered-To: freebsd-ipfw@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 321DB2D3; Tue, 26 Nov 2013 00:18:23 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6A002443; Tue, 26 Nov 2013 00:18:22 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id BD41F2383A8; Tue, 26 Nov 2013 00:18:07 +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 783DF160436; Tue, 26 Nov 2013 00:25:19 +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 481E116042E; Tue, 26 Nov 2013 00:25:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 27951AD3DBF; Tue, 26 Nov 2013 11:18:06 +1100 (EST) To: Ian Lepore From: Mark Andrews References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> Subject: Re: ipfw table add problem In-reply-to: Your message of "Mon, 25 Nov 2013 08:02:58 -0700." <1385391778.1220.4.camel@revolution.hippie.lan> Date: Tue, 26 Nov 2013 11:18:05 +1100 Message-Id: <20131126001806.27951AD3DBF@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: "Alexander V. Chernikov" , Ian Smith , freebsd-ipfw , freebsd-stable , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 00:18:23 -0000 In message <1385391778.1220.4.camel@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@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 From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 27 07:56:58 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 559C1503; Wed, 27 Nov 2013 07:56:58 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 994082E0E; Wed, 27 Nov 2013 07:56:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id rAR7uahG034742; Wed, 27 Nov 2013 18:56:36 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 27 Nov 2013 18:56:36 +1100 (EST) From: Ian Smith To: Ben Morrow Subject: Re: ipfw table add problem In-Reply-To: <20131126124757.GA9974@anubis.morrow.me.uk> Message-ID: <20131127011442.P78756@sola.nimnet.asn.au> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <20131126124757.GA9974@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20131127181617.C78756@sola.nimnet.asn.au> Cc: "Alexander V.Chernikov" , Mark Andrews , Ian Lepore , freebsd-ipfw@freebsd.org, Michael Butler , freebsd-stable@freebsd.org, Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 07:56:58 -0000 On Tue, 26 Nov 2013 12:48:01 +0000, Ben Morrow wrote: > To: freebsd-stable@freebsd.org Restoring cc ipfw@ and others after the inet_pton side?thread in stable@. grepping /usr/src for inet_pton suggests that a behavioural change in inet_pton at this stage seems rather unlikely :) > Quoth Michael Butler : > > > > Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a > > warning from either inet_pton() or ipfw is an egregious breach of POLA, > > That's not a bug in inet_pton, though, that's a bug in ipfw. It's > blindly passing the string to atoi or some such when inet_pton fails, > and ignoring the fact it doesn't consume the whole string. Indeed it is; strtol actually, which quits at the first (here decimal) non-digit. It does return a pointer to it though, and a check for that character being '.' seems like a fair indicator of a failed dotted quad? http://svnweb.freebsd.org/base/head/sbin/ipfw/ipfw2.c?revision=250759&view=co if (ishexnumber(*arg) != 0 || *arg == ':') { /* Remove / if exists */ if ((p = strchr(arg, '/')) != NULL) { *p = '\0'; mask = atoi(p + 1); } if (inet_pton(AF_INET, arg, paddr) == 1) { ... } else if (inet_pton(AF_INET6, arg, paddr) == 1) { ... } else { /* Port or any other key */ key = strtol(arg, &p, 10); /* Skip non-base 10 entries like 'fa1' */ if (p != arg) { pkey = (uint32_t *)paddr; *pkey = htonl(key); type = IPFW_TABLE_CIDR; addrlen = sizeof(uint32_t); } } } if (type == 0 && strchr(arg, '.') == NULL) { /* Assume interface name. Copy significant data only */ ... } if (type == 0) { if (lookup_host(arg, (struct in_addr *)paddr) != 0) errx(EX_NOHOST, "hostname ``%s'' unknown", arg); ... } ... } I'm mostly a pascal programmer (oh, the shame! :) so I can easily misuse C pointers, but my reading of strtol(3) leads to suggest something like: } else { /* Port or any other key */ key = strtol(arg, &p, 10); /* Skip non-base 10 entries like 'fa1' */ if (p != arg) { + /* IPv4 address that failed inet_pton */ + if (*p == '.') { + errx(EX_DATAERR, "bad IPv4 address"); + } pkey = (uint32_t *)paddr; *pkey = htonl(key); type = IPFW_TABLE_CIDR; addrlen = sizeof(uint32_t); } } cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 27 10:12:50 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7038CD5E; Wed, 27 Nov 2013 10:12:50 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 311AD25FF; Wed, 27 Nov 2013 10:12:50 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=95.108.170.36.red-dhcp.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1VlYId-0007JI-J0; Wed, 27 Nov 2013 10:08:35 +0400 Message-ID: <5295C539.8070400@FreeBSD.org> Date: Wed, 27 Nov 2013 14:11:05 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ian Smith , Ben Morrow Subject: Re: ipfw table add problem References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <20131126124757.GA9974@anubis.morrow.me.uk> <20131127011442.P78756@sola.nimnet.asn.au> In-Reply-To: <20131127011442.P78756@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Mark Andrews , Ian Lepore , freebsd-ipfw@freebsd.org, Michael Butler , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 10:12:50 -0000 On 27.11.2013 11:56, Ian Smith wrote: > On Tue, 26 Nov 2013 12:48:01 +0000, Ben Morrow wrote: > > To: freebsd-stable@freebsd.org > > Restoring cc ipfw@ and others after the inet_pton side?thread in > stable@. grepping /usr/src for inet_pton suggests that a behavioural > change in inet_pton at this stage seems rather unlikely :) > > > Quoth Michael Butler : > > > > > > Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a > > > warning from either inet_pton() or ipfw is an egregious breach of POLA, > > > > That's not a bug in inet_pton, though, that's a bug in ipfw. It's > > blindly passing the string to atoi or some such when inet_pton fails, > > and ignoring the fact it doesn't consume the whole string. > > Indeed it is; strtol actually, which quits at the first (here decimal) > non-digit. It does return a pointer to it though, and a check for that > character being '.' seems like a fair indicator of a failed dotted quad? Fixed in r258677, thanks! > > http://svnweb.freebsd.org/base/head/sbin/ipfw/ipfw2.c?revision=250759&view=co > > if (ishexnumber(*arg) != 0 || *arg == ':') { > /* Remove / if exists */ > if ((p = strchr(arg, '/')) != NULL) { > *p = '\0'; > mask = atoi(p + 1); > } > > if (inet_pton(AF_INET, arg, paddr) == 1) { > ... > } else if (inet_pton(AF_INET6, arg, paddr) == 1) { > ... > } else { > /* Port or any other key */ > key = strtol(arg, &p, 10); > /* Skip non-base 10 entries like 'fa1' */ > if (p != arg) { > pkey = (uint32_t *)paddr; > *pkey = htonl(key); > type = IPFW_TABLE_CIDR; > addrlen = sizeof(uint32_t); > } > } > } > > if (type == 0 && strchr(arg, '.') == NULL) { > /* Assume interface name. Copy significant data only */ > ... > } > > if (type == 0) { > if (lookup_host(arg, (struct in_addr *)paddr) != 0) > errx(EX_NOHOST, "hostname ``%s'' unknown", arg); > ... > } > ... > } > > I'm mostly a pascal programmer (oh, the shame! :) so I can easily misuse > C pointers, but my reading of strtol(3) leads to suggest something like: > > } else { > /* Port or any other key */ > key = strtol(arg, &p, 10); > /* Skip non-base 10 entries like 'fa1' */ > if (p != arg) { > + /* IPv4 address that failed inet_pton */ > + if (*p == '.') { > + errx(EX_DATAERR, "bad IPv4 address"); > + } > pkey = (uint32_t *)paddr; > *pkey = htonl(key); > type = IPFW_TABLE_CIDR; > addrlen = sizeof(uint32_t); > } > } > > cheers, Ian > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >