Re: [PATCH] Deletion of route scrubs ifa flag IFA_ROUTE even if it's not the automatic route

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Wed, 11 Mar 2009 02:14:47 +0000
Roy Marples <roy%marples.name@localhost> wrote:

> On Tue, 2009-03-10 at 19:00 -0500, David Young wrote:
> > Make sure to have a look at all of the sites that call
> > rt_replace_ifa(), because the callers may expect to manage
> > IFA_ROUTE themselves.
> > 
> > It would be too bad if we ship a worse 5.0 kernel than possible,
> > but if you can workaround this defect in userland, now, instead of
> > changing the kernel so late in the 5.0 release cycle, with
> > unforeseen consequences, then we may ship a better 5.0 kernel than
> > otherwise in the end! :-)
> 
> OK, here's the issue.
> 
> ifconfig bge0 alias 192.168.0.1/24
> ifconfig iwi0 alias 192.168.0.2/24
> route change 192.168.0.0/24 -ifa 192.168.0.2
> 
> So far so good - we've changed the automatic subnet route.
> 
> ifconfig bge0 -alias 192.168.0.1/24
> ifconfig iwi0 -alias 192.168.0.2/24
> 
> Now, should the automatic subnet route still be around, or should it
> be deleted? I'm guessing that it should stay around as the fact we
> changed it makes it no longer automatic. [1]
> 
> http://mail-index.netbsd.org/tech-net/2008/12/23/msg000920.html
> I tried to do the same thing for IPv6.
> It appears that IPv6 leaves the automatic route around in this
> instance as well. I've not tested my rt_replace_ifa() patch to see
> the route is removed after all addresses have been when the ifa has
> been changed.
> 
> I think I'll just revert the rtsock.c change, get that pulled up to
> NetBSD-5 and document this in dhcpcd-5. It's the safest course of
> action.
> 
> Thanks
> 
> Roy
> 
> [1] This all stems from me trying to make dhcpcd restore as much of
> the initial environment as possible. One of the features of dhcpcd-5
> is to prefer a wired interface over a wireless one on the same subnet
> even when the wireless interface is active first. We do this by
> changing the ifa, which works nicely. However, there is also the case
> where the user has an existing subnet route, which will be destroyed
> by dhcpcd in this instance. The rt_replace_ifa() patch was an effort
> to avoid this.

I've had problems in this sort of situation with dhclient and with
routes not going away.  What I ended up doing was putting a 'route
flushall' into my suspend/resume script -- which isn't quite right, but
does the trick for most of my situations.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb