Hi, On Fri, Jan 26, 2018 at 10:26:58AM -0500, Selva Nair wrote: > The mystery (at least for me) is where that host part is coming > from... Its zeroed out before setting the route, and I thought the > same (?) route list pointer is > passed in while deleting routes.
So. Staring a bit at the code (while sf.net is refusing to forward my
last mail to patchwork... so I can't go ahead and commit & close more
patches).
The clearing of the route happens in
route.c: route_ipv6_clear_host_bits()
which is only called from add_route_ipv6().
route_ipv6_clear_host_bits() does clear the "call by reference" route_ipv6
structure, though, so it really should bubble up the call chain to
add_routes(), zeroeing out the bits in the "rl6->routes_ipv6" IPv6 route
list.
Testing this on linux with "--route-ipv6 2001:db8::1234:abcd/112" I can
see that this seems to work correctly...
Tue Feb 20 15:19:02 2018 add_route_ipv6(2001:db8::1234:0/112 ->
fd00:abcd:194:4::1 metric -1) dev tap3
Tue Feb 20 15:19:02 2018 /bin/route -A inet6 add 2001:db8::1234:0/112 dev tap3
gw fd00:abcd:194:4::1
Tue Feb 20 15:19:15 2018 delete_route_ipv6(2001:db8::1234:0/112)
Tue Feb 20 15:19:15 2018 /bin/route -A inet6 del 2001:db8::1234:0/112 dev tap3
gw fd00:abcd:194:4::1
(just grabbing a random test config, "tap" has no significance here, works
the same with "tun")
"master" behaves the same here as release/2.4.
Re-reading the thread, I can now see where this is coming from - this
is not "normal routes" but "on-link interface routes", and this is
something that got broken on introducing the iservice (where the zeroeing
of the host bits was changed from "zap the local copy" to "zap the
upstream copy, and do not zap it in delete_route() again, because, not
needed") - commit a24dd2e31.
The on-link route is installed by tun.c:add_route_connected_v6_net(),
which operates on a on-stack instance of "struct route_ipv6"...
void
add_route_connected_v6_net(struct tuntap *tt,
const struct env_set *es)
{
struct route_ipv6 r6;
CLEAR(r6);
r6.network = tt->local_ipv6;
r6.netbits = tt->netbits_ipv6;
r6.gateway = tt->local_ipv6;
r6.metric = 0; /* connected route */
r6.flags = RT_DEFINED | RT_METRIC_DEFINED;
add_route_ipv6(&r6, tt, 0, es);
}
... so the zero'ing in add_route_ipv6() does not "stick".
On termination, we call delete_route_connected_v6_net(), which sets up
a new "route_ipv6" copy... with all bits set.
Jan Just, could you please test the following patch? This will explicitly
clear the host bits for the "on-link" route again.
Fully untested :-)
gert
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index ebb15bd3..79453665 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -839,6 +839,7 @@ delete_route_connected_v6_net(struct tuntap *tt,
r6.gateway = tt->local_ipv6;
r6.metric = 0; /* connected route */
r6.flags = RT_DEFINED | RT_ADDED | RT_METRIC_DEFINED;
+ route_ipv6_clear_host_bits(&r6);
delete_route_ipv6(&r6, tt, 0, es);
}
#endif /* if defined(_WIN32) || defined(TARGET_DARWIN) ||
defined(TARGET_NETBSD) || defined(TARGET_OPENBSD) */
--
now what should I write here...
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
