Hi,
On Tue, Jul 09, 2019 at 12:48:06AM +0200, Antonio Quartulli wrote:
>
> Changes from v1:
> - use IN6_IS_ADDR_UNSPECIFIED to check if GW address is specified. This fixes
> the issue of never setting the ON_LINK flag for IPv6 routes
Something is still not working correctly.
It *must not* set the ON_LINK flag for routes that are behind a gatway
("route to gateway" vs. "route to interface"), but it still does.
Here's what I tested:
- my home network has 2001:608:4:0::/64 on link
- I have set up a route fd00::200::/48 -> tun0 (no gateway)
- default gateway is either statically configured (FreeBSD) or learned
from RA (linux)
- I asked openvpn the following question:
openvpn --show-gateway
openvpn --show-gateway 2001:608::2
openvpn --show-gateway 2001:608:4::123
openvpn --show-gateway fd00::200::1
the first is "find me the way to reach ::", which is via default
gateway (and the target is not ON_LINK), the second is "find me the
way to this particular IPv6 address" - which is also via default
gateway (here), and not ON_LINK.
The third is "find me the way to reach 2001:608:4::123", which is
another host on the LAN, so packets for this IPv6 address must be
sent "towards the LAN" not "to a gateway" -> this is ON_LINK.
The fourth is something of an oddball, point to point interfaces
do not have neighbour discovery - so all routes to a gateway *behind*
a p2p interface are also "ON_LINK", as there is no gateway we could
put into a route.
Now, this is what OpenVPN 2.4.7 prints here (or master "with no patch")
(leaving off IPv4):
$ openvpn247 --show-gateway
Sun Jul 14 21:51:09 2019 ROUTE6_GATEWAY fe80::250:43ff:fe01:dc37 IFACE=enp0s25
$ openvpn247 --show-gateway 2001:608::2
Sun Jul 14 21:51:22 2019 ROUTE6_GATEWAY fe80::250:43ff:fe01:dc37 IFACE=enp0s25
$ openvpn247 --show-gateway 2001:608:4::123
Sun Jul 14 21:51:33 2019 ROUTE6_GATEWAY 2001:608:4::123 ON_LINK IFACE=enp0s25
$ openvpn247 --show-gateway fd00::200::1
Sun Jul 14 21:52:14 2019 ROUTE6_GATEWAY fd00::200::1 ON_LINK IFACE=tun0
and this is what OpenVPN master + your patch prints
$ src/openvpn/openvpn --show-gateway
Sun Jul 14 21:42:25 2019 ROUTE6_GATEWAY fe80::250:43ff:fe01:dc37 ON_LINK
IFACE=enp0s25 HWADDR=00:00:00:00:54:97
$ src/openvpn/openvpn --show-gateway 2001:608::2
Sun Jul 14 21:46:02 2019 ROUTE6_GATEWAY fe80::250:43ff:fe01:dc37 ON_LINK
IFACE=enp0s25 HWADDR=00:00:00:00:54:b7
$ src/openvpn/openvpn --show-gateway 2001:608:4::123
Sun Jul 14 21:42:51 2019 ROUTE6_GATEWAY 2001:608:4::123 ON_LINK IFACE=enp0s25
$ src/openvpn/openvpn --show-gateway fd00::200::1
Sun Jul 14 21:42:59 2019 ROUTE6_GATEWAY fd00::200::1 ON_LINK IFACE=tun0
HWADDR=00:00:00:00:54:87
as you can see, it now insists on "everything is ON_LINK".
Now... I think the issue might be just that you removed the
-CLEAR(*rgi6);
bit, so "there is cruft in that structure, and it is flagged as
'the ON_LINK bit is set'" - but it's too late for me to do a full
code review, so can't say for sure. If I just add it back, it
behaves correctly, but it would be good to give this function another
long and hard stare...
However - as it is today, I need to NAK this. Sorry. (And I should
have been much quicker)
gert
(PS: FreeBSD is, as expected, showing the same things before/after, with
ON_LINK only for test 3+4 - but that's a totally different code path, so
no surprises here)
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
