This does change semantics of "local <address>" or "remote <address>",
but in a useful way. The old code would just fail on
proto udp4
remote 2001:db8::1
because it tried to force-resolve the v6 address as "proto v4" (and vice
versa):
2024-12-24 13:24:18 RESOLVE: Cannot resolve host address: 2001:db8::1:51194
(Name does not resolve)
2024-12-24 13:25:01 RESOLVE: Cannot resolve host address: 199.102.77.82:51194
(Name does not resolve)
The new code will basically change "proto udp4" to "udp6" if a numeric v6
address is seen (and vice versa).
This has a small risk for unforeseen breakage (configs that have v4+v6
connection entries in them, and purposely selecting one or the other
using "proto udp4/udp6"), but I'm willing to accept that - if we really
need that use case (instead of just letting the transport layer decide if
v4 or v6 succeeds) we might enhance `--proto-force` to also serve as a
v4/v6 switch. Or introduce -4/-6.
Tested client-side with the "mismatched" combinations, and subjected to
the full client/server side tests - which uncovered a unforeseen surprise
in v7 (instead of a dual-stack socket for "ANY", I only got v4 sockets)
- this has been addressed in v9, and my zoo behaves "as before".
Your patch has been applied to the master branch.
commit 8b209d9e5d80799eec931e2fec9b15f7e2c1a7b0
Author: Antonio Quartulli
Date: Fri Dec 27 17:17:55 2024 +0100
override ai_family if 'local' numeric address was specified
Signed-off-by: Antonio Quartulli <a...@unstable.cc>
Signed-off-by: Gianmarco De Gregori <gianma...@mandelbit.com>
Acked-by: Gert Doering <g...@greenie.muc.de>
Message-Id: <20241227161755.4010-1-g...@greenie.muc.de>
URL:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg30257.html
Signed-off-by: Gert Doering <g...@greenie.muc.de>
--
kind regards,
Gert Doering
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
