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.
[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.