Skip site navigation (1)Skip section navigation (2)
Date:      Wed,  4 Feb 2009 10:25:31 -0500 (EST)
From:      Vivek Khera <vivek@khera.org>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   bin/131365: route add changes interpretation of network specification
Message-ID:  <20090204152531.E0E3C5084A@mmfe1.m1e.net>
Resent-Message-ID: <200902041550.n14Fo2De090508@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         131365
>Category:       bin
>Synopsis:       route add changes interpretation of network specification
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>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:
>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:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090204152531.E0E3C5084A>