|
(0024054)
|
|
Zalewa
|
|
2024-10-07 18:00
|
|
OK, so this happens because we bind the UDP socket that is listening to the LAN broadcasts to an "Any" address. This "Any" is both IPv4 and IPv6. Here.
When a broadcast packet arrives, we need to know where it came from. We obtain the address of the host who sent it here.
Now, it appears that if the system Doomseeker runs in has an IPv6 address (regardless if there's actual connectivity) and the socket is bound to this encompassing "Any", Qt will map IPv4 addresses to IPv6. Converting such address to a string, for command line purposes, will produce the IPv6 address string as stated in the report.
To fix this, I can try mapping such IPv6 address back to an explicit IPv4 address.
I actually tried that, the code is rather short:
// Qt may provide us with an IPv4-mapped IPv6 address, so
// convert it to an explicit IPv4 if it's a mapped IPv4.
if (sender.protocol() == QAbstractSocket::IPv6Protocol)
{
bool isMapped = false;
quint32 ipv4 = sender.toIPv4Address(&isMapped);
if (isMapped)
{
sender = QHostAddress(ipv4);
}
}
If fixes the issue: you can connect to the server. The question is: will this blow anything up in an environment with real IPv6? I suspect no, because the LAN broadcasts, as Zandronum uses them, don't even function in IPv6. So, this feature is a pure IPv4 thing anyway.
Just in any case, I haven't pushed this fix yet, but it seems a valid one. I asked the tin can about it and it also says it should be ok, but the tin can can never be fully trusted.
An alternative fix would be not to bind the socket to "Any", but to "AnyIPv4". Qt should then cease to produce IPv4-mapped IPv6 addresses, but this may cause some error messages in environments where there is no IPv4 at all, and handling this properly may be more complicated than just remapping the IP.
|
|