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.
Attachment:
signature.asc
Description: This is a digitally signed message part