From vivek@m1e.net Wed Feb 4 15:41:08 2009 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C32A106564A for ; Wed, 4 Feb 2009 15:41:08 +0000 (UTC) (envelope-from vivek@m1e.net) Received: from mmfe1.m1e.net (mmfe1.m1e.net [206.112.95.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0E10D8FC16 for ; Wed, 4 Feb 2009 15:41:07 +0000 (UTC) (envelope-from vivek@m1e.net) Received: by mmfe1.m1e.net (Postfix, from userid 120) id E0E3C5084A; Wed, 4 Feb 2009 10:25:31 -0500 (EST) Message-Id: <20090204152531.E0E3C5084A@mmfe1.m1e.net> Date: Wed, 4 Feb 2009 10:25:31 -0500 (EST) From: Vivek Khera Reply-To: Vivek Khera To: FreeBSD-gnats-submit@freebsd.org Cc: Subject: route add changes interpretation of network specification X-Send-Pr-Version: 3.113 X-GNATS-Notify: >Number: 131365 >Category: bin >Synopsis: route(8): route add changes interpretation of network specification [regression] >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-net >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 04 15:50:02 UTC 2009 >Closed-Date: >Last-Modified: Fri May 29 14:00:09 UTC 2009 >Originator: Vivek Khera >Release: FreeBSD 7.1-RELEASE-p2 amd64 >Organization: >Environment: System: FreeBSD mmfe1.m1e.net 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Fri Jan 16 23:44:29 EST 2009 vivek@mmfe1.m1e.net:/n/lorax1/usr7/obj.amd64/n/lorax1/usr7/src/sys/KCI64SMP amd64 >Description: In my /etc.rc.conf, I have a static route for my VPN connection to route the internal address to my VPN router: route_vpn1="-net 192.168 192.168.100.202" Up through FreeBSD 7.0-REL (including all 5.x and 6.x releases), this was interpreted by the route add command as 192.168.0.0/16. As of FreeBSD 7.1 it is treated as 192.168.0.0/24. The only way to see this is to use netstat -rn command, as netstat -r will show nothing different on a 7.0 vs a 7.1 machine. Also pinging an address in the 192.168.x.y (where x > 0) range will try to use the default route rather than the expected VPN route. The man page has not changed to reflect this new behavior, either. >How-To-Repeat: add a static route like this: route add -net 192.168 192.168.100.202 and view the routes with netstat -rn They will be different on 7.1 than any prior FreeBSD release. >Fix: the workaround is to explicitly specify the netmask: route add -net 192.168/16 192.168.100.202 At minimum, the man page needs to be updated to reflect this, and I would have expected an entry in UPDATING as I nearly lost access to this machine because of the loss of the route. I was lucky to have another local machine to access it via the LAN. >Release-Note: >Audit-Trail: Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Tue Feb 10 14:14:05 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=131365 From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/131365: commit references a PR Date: Mon, 6 Apr 2009 10:09:37 +0000 (UTC) Author: rrs Date: Mon Apr 6 10:09:20 2009 New Revision: 190758 URL: http://svn.freebsd.org/changeset/base/190758 Log: Class based addressing went out in the early 90's. Basically if a entry is not route add -net xxx/bits then we should use the addr (xxx) to establish the number of bits by looking at the first non-zero bit. So if we enter route add -net 10.1.1.0 10.1.3.5 this is the same as doing route add -net 10.1.1.0/24 Since the 8th bit (zero counting) is set to 1 we set bits to 32-8. Users can of course still use the /x to change this behavior or in cases where the network is in the trailing part of the address, a "netmask" argument can be supplied to override what is established from the interpretation of the address itself. e.g: route add -net 10.1.1.8 -netmask 0xff00ffff should overide and place the proper CIDR mask in place. PR: 131365 MFC after: 1 week Modified: head/sbin/route/route.c Modified: head/sbin/route/route.c ============================================================================== --- head/sbin/route/route.c Mon Apr 6 07:13:26 2009 (r190757) +++ head/sbin/route/route.c Mon Apr 6 10:09:20 2009 (r190758) @@ -713,7 +713,7 @@ newroute(argc, argv) #ifdef INET6 if (af == AF_INET6) { rtm_addrs &= ~RTA_NETMASK; - memset((void *)&so_mask, 0, sizeof(so_mask)); + memset((void *)&so_mask, 0, sizeof(so_mask)); } #endif } @@ -803,21 +803,22 @@ inet_makenetandmask(net, sin, bits) addr = net << IN_CLASSC_NSHIFT; else addr = net; - - if (bits != 0) - mask = 0xffffffff << (32 - bits); - else if (net == 0) - mask = 0; - else if (IN_CLASSA(addr)) - mask = IN_CLASSA_NET; - else if (IN_CLASSB(addr)) - mask = IN_CLASSB_NET; - else if (IN_CLASSC(addr)) - mask = IN_CLASSC_NET; - else if (IN_MULTICAST(addr)) - mask = IN_CLASSD_NET; - else - mask = 0xffffffff; + /* + * If no /xx was specified we must cacluate the + * CIDR address. + */ + if ((bits == 0) && (addr != 0)) { + int i, j; + for(i=0,j=1; i<32; i++) { + if (addr & j) { + break; + } + j <<= 1; + } + /* i holds the first non zero bit */ + bits = 32 - i; + } + mask = 0xffffffff << (32 - bits); sin->sin_addr.s_addr = htonl(addr); sin = &so_mask.sin; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From: Mykola Dzham To: bug-followup@FreeBSD.org, rrs@FreeBSD.org Cc: Subject: Re: bin/131365: r190758 break using 0 , 0/0, 0.0.0.0/0 as alias for 'default' Date: Sat, 11 Apr 2009 11:20:20 +0300 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! r190758 break using 0.0.0.0/0 as alias for default rote: $ route -n get default route to: default destination: default mask: default gateway: 192.168.1.1 interface: em0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 $ route -n get -net 0.0.0.0 route: writing to routing socket: No such process Attached patch fix this -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua --UugvWAfsgieZRqgk Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="route.c.patch" Index: route.c =================================================================== --- route.c (revision 190880) +++ route.c (working copy) @@ -818,7 +818,8 @@ /* i holds the first non zero bit */ bits = 32 - (i*8); } - mask = 0xffffffff << (32 - bits); + if (bits != 0) + mask = 0xffffffff << (32 - bits); sin->sin_addr.s_addr = htonl(addr); sin = &so_mask.sin; --UugvWAfsgieZRqgk-- From: Randall Stewart To: Mykola Dzham Cc: bug-followup@FreeBSD.org, rrs@FreeBSD.org Subject: Re: bin/131365: r190758 break using 0 , 0/0, 0.0.0.0/0 as alias for 'default' Date: Sat, 11 Apr 2009 06:04:37 -0400 Good catch Mykola.. I will get this in :) R On Apr 11, 2009, at 4:20 AM, Mykola Dzham wrote: > Hi! > r190758 break using 0.0.0.0/0 as alias for default rote: > > $ route -n get default > route to: default > destination: default > mask: default > gateway: 192.168.1.1 > interface: em0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount > mtu expire > 0 0 0 0 0 0 > 1500 0 > > $ route -n get -net 0.0.0.0 > route: writing to routing socket: No such process > > Attached patch fix this > > -- > Mykola Dzham, LEFT-(UANIC|RIPE) > JID: levsha@jabber.net.ua > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From: Vick Khera To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/131365: route(8): route add changes interpretation of network specification [regression] Date: Fri, 29 May 2009 09:57:13 -0400 I'm not really following the discussion here so much, but in FreeBSD 7.2, it still sets the routes incorrectly from my perspective. I have in my rc.conf the following: route_vpn1="-net 192.168 192.168.100.202" and it results in the following route (from netstat -rn) Destination Gateway Flags Refs Use Netif Expire 192.168.0.0/24 192.168.100.202 UGS 0 0 em1 whereas in 7.0 and prior, it resulted in a /16 route as I expected, and as I understand it should be from the man page. The man page explicitly states: "-net 128.32 is interpreted as 128.32.0.0" so the man page and the behavior are seemingly inconsistent (still). >Unformatted: