Am 12.05.22 um 21:14 schrieb Gert Doering:
On Thu, May 12, 2022 at 06:46:50PM +0200, Frank Doepper wrote:
Under normal conditions, neither should make any difference, but if
this triggers a kernel bug, it might...
Did you have a look at that kernel code? Maybe this will my first linux
kernel bug report?
I'm not a kernel coding guru. Last time I bumped into "this" (multihome
not working for v4-mapped address on linux) I reported the effect to one
of the ipv6 lists ...
https://www.mail-archive.com/ipv6-ops@lists.cluenet.de/msg00959.html
... and magic happened... one of the kernel network maintainers picked
up the ball, went looking, and replied "I see the problem and yes, this
is unfortunate, I see" :-) - and then we had patches and things started
working.
Thank you for the detailed information!
Is there a way to circumvent this (like binding to every address
separately, like bind9 and ntpd do)?
Not today, unfortunately.
Antonio was working on multiple listening sockets, but our code is old
and complicated. Actually it was working for "multiple sockets of the
same socket type" (udp+udp or tcp+tcp) but udp+tcp never worked, and the
momentum got lost...
udp+udp would help here ("bind to explicit v4 and explicit v6 address")
I've tested this with mhome.c and the issue keeps the same when binding to
IPv4 only, so I think this time it's not a IPv4+IPv6 thing but rather a
"UDP on wildcard socket with confusing interfaces" thing.
I think I have to build a minimal setup for reproducing and contact some
kernel developers. Or find a way to circumvent this problem.
Viele Grüße,
Frank
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
