svn commit: r190775 - head/sbin/route

Coleman Kane cokane at FreeBSD.org
Mon Apr 6 09:28:46 PDT 2009


On Mon, 2009-04-06 at 12:21 -0400, Randall Stewart wrote:
> On Apr 6, 2009, at 11:07 AM, Coleman Kane wrote:
> 
> > 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.
> >
> 
> It would have actually done any number of ones... basically looking
> at the bottom number of 0 bits and that would be the / value.
> 
> So depending on what number you put with
> 10.x (for x) you could get a variety of results..
> 
> 10.2 would == 10.2/17
> 10.4 would == 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.

> 
> etc.
> 
> This is not the correct behavior.. even though it might be
> technically right with regard to CIDR.
> 
> Now as far as the old class based routings go.. this is a problem
> since the two schemes are at odds.
> 
> We have for a long time had doing
> 
> route add -net 10.2.0.0 be equal to adding 10.2/16
> 
> 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.
> 
> 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..
> 
> R
> 
> >>
> >>  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
> >> =
> >> =
> >> =
> >> =
> >> =
> >> =
> >> =
> >> =
> >> =
> >> =====================================================================
> >> --- 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 == 0)  && (addr != 0)) {
> >> -		int i, j;
> >> -		for(i=0,j=1; i<32; i++)  {
> >> +		u_long i, j;
> >> +		for(i=0,j=0xff; i<4; i++)  {
> >> 			if (addr & j) {
> >> 				break;
> >> 			}
> >> -			j <<= 1;
> >> +			j <<= 8;
> >> 		}
> >> 		/* i holds the first non zero bit */
> >> -		bits = 32 - i;	
> >> +		bits = 32 - (i*8);	
> >> 	}
> >> 	mask = 0xffffffff << (32 - bits);
> >>
> >
> > -- 
> > Coleman Kane
> 
> ------------------------------
> Randall Stewart
> 803-317-4952 (cell)
> 803-345-0391(direct)
> 
-- 
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20090406/7a202bad/attachment.pgp


More information about the svn-src-head mailing list