[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] Deletion of route scrubs ifa flag IFA_ROUTE even if it's not the automatic route
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. 
> 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
>  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
Main Index |
Thread Index |