From owner-svn-src-head@FreeBSD.ORG Mon Apr 6 16:28:44 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21D8A10656E5 for ; Mon, 6 Apr 2009 16:28:44 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id D0E1D8FC32 for ; Mon, 6 Apr 2009 16:28:43 +0000 (UTC) (envelope-from cokane@FreeBSD.org) X-CNFS-Analysis: v=1.0 c=1 a=yWHZTcLBkW0A:10 a=JrIlpGgeJDMA:10 a=6I5d2MoRAAAA:8 a=TEk0-XqTdsO1Vyy7xtwA:9 a=BV4U9yr8NeWk2-snvAUA:7 a=oIE-KR9vigrTBo-54b4_5H56snQA:4 a=LY0hPdMaydYA:10 a=DdoR2F1noGMA:10 a=-OVAfgye9ggA:10 a=p1dl59qkDAKad3d7:21 a=_icPO50CJ_6JW_lO:21 a=w_sEYLCNI7S7TjixogIA:9 a=nqx8j09HCemYT5h60A_Tvkg0DgMA:4 a=rPt6xJ-oxjAA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: gwout1 smtp.mail=cokane@FreeBSD.org; spf=softfail Received-SPF: softfail (gwout1: transitional domain FreeBSD.org does not designate 74.215.227.9 as permitted sender) Received: from [74.215.227.9] ([74.215.227.9:50053] helo=mail.cokane.org) by gwout1 (envelope-from ) (ecelerity 2.2.2.37 r(28805/28810M)) with ESMTP id 5E/51-27669-ABD2AD94; Mon, 06 Apr 2009 12:28:42 -0400 Received: from [10.128.128.2] (unknown [10.128.128.2]) by mail.cokane.org (Postfix) with ESMTPSA id E6F441143D; Mon, 6 Apr 2009 13:33:38 -0400 (EDT) From: Coleman Kane To: Randall Stewart In-Reply-To: <5EEC0668-D1C4-45E8-AFC1-959AE3E8715E@lakerest.net> References: <200904061427.n36ERTVF074015@svn.freebsd.org> <1239030459.1946.4.camel@localhost> <5EEC0668-D1C4-45E8-AFC1-959AE3E8715E@lakerest.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-FcsJJQgGjUhUn7DyIR5w" Organization: FreeBSD Project Date: Mon, 06 Apr 2009 12:26:58 -0400 Message-Id: <1239035218.1946.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Cc: svn-src-head@FreeBSD.org, Randall Stewart , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r190775 - head/sbin/route X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 16:28:46 -0000 --=-FcsJJQgGjUhUn7DyIR5w Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-04-06 at 12:21 -0400, Randall Stewart wrote: > On Apr 6, 2009, at 11:07 AM, Coleman Kane wrote: >=20 > > On Mon, 2009-04-06 at 14:27 +0000, Randall Stewart wrote: > >> Author: rrs > >> Date: Mon Apr 6 14:27:28 2009 > >> New Revision: 190775 > >> URL: http://svn.freebsd.org/changeset/base/190775 > >> > >> Log: > >> Ok, looking at the solution a bit closer, the level > >> calculation was too agressive. Instead we should only > >> look at each nibble. This makes it so we make > >> 10.2.0.0 become 10.2/16 NOT 10.2/17. > > > > I presume you meant "NOT 10.2/15" here? Correct me if I'm wrong, but > > that's what I gathered by the discussion of "the bug" in the previous > > thread. > > >=20 > It would have actually done any number of ones... basically looking > at the bottom number of 0 bits and that would be the / value. >=20 > So depending on what number you put with > 10.x (for x) you could get a variety of results.. >=20 > 10.2 would =3D=3D 10.2/17 > 10.4 would =3D=3D 10.2/18 I was under the impression that the above would sort out to something akin to the following binary sequences: 00001010 00000010 (10.2) produces a 15-bit-long mask (11111111 11111110) 00001010 00000100 (10.4) produces a 14-bit-long mask (11111111 11111100) I would expect 10.2.128 to produce a 17-bit mask, and 10.2.129 to produce an 18-bit mask, according to CIDR. >=20 > etc. >=20 > This is not the correct behavior.. even though it might be > technically right with regard to CIDR. >=20 > Now as far as the old class based routings go.. this is a problem > since the two schemes are at odds. >=20 > We have for a long time had doing >=20 > route add -net 10.2.0.0 be equal to adding 10.2/16 >=20 > But if you follow the old Class based routing then > the upper 4 bits of the address needs to be examined to > determine if its a /8, /16 etc. >=20 > That is incorrect in a CIDR world.. but I don't see a way > to make the two schemes work together. And since previous to 7.1 > the above worked.. I think this last fix is the right approach.. >=20 > R >=20 > >> > >> Need to explore the non-cidr address issue. The two > >> may not be seperable.. > >> > >> MFC after: 1 week > >> > >> Modified: > >> head/sbin/route/route.c > >> > >> Modified: head/sbin/route/route.c > >> =3D > >> =3D > >> =3D > >> =3D > >> =3D > >> =3D > >> =3D > >> =3D > >> =3D > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- head/sbin/route/route.c Mon Apr 6 14:12:22 2009 (r190774) > >> +++ head/sbin/route/route.c Mon Apr 6 14:27:28 2009 (r190775) > >> @@ -808,15 +808,15 @@ inet_makenetandmask(net, sin, bits) > >> * CIDR address. > >> */ > >> if ((bits =3D=3D 0) && (addr !=3D 0)) { > >> - int i, j; > >> - for(i=3D0,j=3D1; i<32; i++) { > >> + u_long i, j; > >> + for(i=3D0,j=3D0xff; i<4; i++) { > >> if (addr & j) { > >> break; > >> } > >> - j <<=3D 1; > >> + j <<=3D 8; > >> } > >> /* i holds the first non zero bit */ > >> - bits =3D 32 - i;=09 > >> + bits =3D 32 - (i*8);=09 > >> } > >> mask =3D 0xffffffff << (32 - bits); > >> > > > > --=20 > > Coleman Kane >=20 > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) >=20 --=20 Coleman Kane --=-FcsJJQgGjUhUn7DyIR5w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAknaLVIACgkQcMSxQcXat5ehGQCfT/po4jUM2JmR5Ygdvd7+2KWD p/kAoIErC7/mssSvQn4ZTxIeb22cTSEt =PE/H -----END PGP SIGNATURE----- --=-FcsJJQgGjUhUn7DyIR5w--