Hi tech,
since OpenBSD 5.6 route change messages can change the interface of a route
(rt_ifa) even if a message doesn't seem to require it because of a changed
gateway or stuff like that.
I would like to ask if it's a regression or if the new behavior is intended.
Example: (only for testing - it doesn't represent my network topology)
ifconfig em0 inet6 fd88::1/64
ifconfig em1 inet6 fd99::1/64
route add -inet6 fd88::666 fd99::1
route get fd88::666
interface: em1 (as expected)
route change fd88::666 -mtu 1500
route get fd88::666
interface: em0 (broken - trying to ping the target results in "No route to
host")
In the example I can workaround the problem with adding a gateway while changing
the mtu:
route change fd88::666 fd99::1 -mtu 1500
A comment in route_output (rtsock.c) says
/*
* new gateway could require new ifaddr, ifp;
* flags may also be different; ifp may be specified
* by ll sockaddr when protocol address is ambiguous
*/
but their is no check for a 'new gateway'.
With OpenBSD 5.5 some checks with RTAX_GATEWAY, RTAX_IFP and RTAX_IFA were made,
before
rt_ifa changed.
Would it make sense to add a check like follow or is the new behavior intended
and
'route change' has to be called with destination and gateway now?
The patch is not tested very well yet, it's a proposal awaiting your comments.
Regards,
Florian
--- sys/net/rtsock.c 2014-11-26 06:08:59.000000000 +0100
+++ sys/net/rtsock.c.new 2014-11-26 06:08:24.000000000 +0100
@@ -763,7 +763,7 @@ report:
}
ifa = info.rti_ifa;
if (ifa) {
- if (rt->rt_ifa != ifa) {
+ if (rt->rt_ifa != ifa && newgate) {
if (rt->rt_ifa->ifa_rtrequest)
rt->rt_ifa->ifa_rtrequest(
RTM_DELETE, rt);
