Date: Mon, 6 Apr 2009 18:45:29 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Randall Stewart <rrs@lakerest.net> Cc: svn-src-head@FreeBSD.org, Randall Stewart <rrs@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Coleman Kane <cokane@FreeBSD.org> Subject: Re: svn commit: r190775 - head/sbin/route Message-ID: <alpine.BSF.2.00.0904061840550.18619@fledge.watson.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Apr 2009, Randall Stewart wrote:
>> 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
>
> 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.
Perhaps I'm sort of old-fashioned, but I would generally expect:
(1) No netmask specified -- use class to determine netmask
(2) netmask specified using -net 192.168/20 -- use /20
(3) netmask specified using -netmask -- use the -netmask argument.
I guess I just don't administer routers very much anymore, but is using the
last set bit a commonly used way to name networks these days, as opposed to
explicitly setting the netmask with /whatever?
Robert N M Watson
Computer Laboratory
University of Cambridge
>
> 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)
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904061840550.18619>
