Hello, I’m the upstream developer of Moonlight.
I think there is a bit of confusion regarding the actual change between Qt 5.9 and Qt 5.14. The API that seems to be the problem here is QNetworkInterface. The code on Moonlight’s end is identical between Qt 5.9 and 5.14. There are no new Qt APIs or anything that we’re using on 5.14. We’re using QNetworkInterface just like we did before, and it broke because Qt 5.14 in core20 was built with the AF_NETLINK backend for QNetworkInterface.
We use QNetworkInterface in 3 places.
The first one is to send Wake-on-LAN broadcast packets via all connected interfaces to ensure it reaches the target PC on multi-homed systems. We do this by find the local IP address and subnet of each interface and calculating the subnet broadcast address to use when sending our WOL packets.
The second is a VPN detection heuristic that lets us reduce our MTU slightly to ensure we’re not causing IP fragmentation when the VPN encapsulates our video traffic. The code there uses the MTU, MAC address (some VPN interfaces have common prefixes), interface type, and interface name to determine if the interface we’re connected through is likely a VPN.
The third (and most critical one) is in our QMdnsEngine submodule. mDNS is a multicast protocol and in order to join a multicast group, you should specify an interface. Without an interface, you’re not guaranteed where your mDNS packets will go out on multi-homed systems. Because
QNetworkInterface::allInterfaces() returns an empty list, we can’t join a multicast group or specify the outbound multicast interface and the mDNS packets don’t get sent/received.
None of these things (except maybe #2) really seem like something normal apps shouldn’t be doing. Getting local interface IP addresses doesn’t seem like something that should be a privileged operation (especially since one can simply call
getsockname() on a connected socket to accomplish the same thing). It’s basic stuff that
getifaddrs() could do. I think it’s likely that other Qt apps will run into this issue as well.
The bigger risk in my opinion is that Qt apps will subtly break when updating to core20. We caught this because the mDNS breakage was obvious, but imagine if the only breakage was something less clear, like our VPN heuristic or Wake-on-LAN multi-homed support. It might be that the app now connects via an internet relay rather than directly via LAN, or that your streaming performance over a VPN gets slightly worse, or that Wake-on-LAN doesn’t work consistently for some users. It’s just functional enough to escape the developer’s attention, but the user experience will suffer.
Apologies, I wanted to provide more links to the Moonlight source and Qt documentation, but I can’t post more than 2 links since I’m a new user.