IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Tore Anderson]

* Hannes Frederic Sowa

> In its current form, not so good. If you can tell me specific software
> that *breaks*, I can ask. At first I thought I might be able to just
> switch an 'if' but the patch got a bit more complex.

What breaks is OpenVPN servers listening on an UDP IPv6 socket with
IPV6_V6ONLY=0. If an IPv4 client attempts to set up a tunnel to a
non-primary address of the server (for example in the case of a server
with multiple interfaces or dedicated service OpenVPN service
addresses), the OpenVPN process fails to use the address it was
contacted on when replying to the client, instead using the default IPv4
source address of the system. This in turn leads to the tunnel failing
to establish.

See: https://community.openvpn.net/openvpn/ticket/306

FWIW: So far the "solution" has been to simply keep the UDP server
IPv4-only, which works fine since with current versions of OpenVPN you
have to explicitly ask for IPv6 to be used, which nobody (except I)
does. However when OpenVPN 2.4 gets released the client will start using
standard getaddrinfo() and thus prefer IPv6 when available, and then
having no process listening on IPv6 in the server end becomes a real
problem - nobody likes timeouts...

> Maybe the workaround with IPv4 PKT_INFO does help for the time being.

Probably, although I'm guessing Gert would rather not go there when your
more proper fix is right around the corner. No worries, I'll look into
backporting the patch to the kernel I'm currently running or upgrading
to 3.14 once it's released. Thanks again!

Tore