The UDP multicast that Minecraft sends to notify listening clients of LAN games is only sent to the first active network interface. If that interface is not the LAN that the other Minecraft clients are on, then they don’t autodiscover games, despite the direct connection option working fine.
This can happen for various reasons:
For one person I know, there was an Ethernet adapter listed first with a 192.168.x.x IP, and a WiFi adapter listed second with a 10.0.x.x IP. All the clients were on the 10.0.x.x network. Everything works fine except autodiscovery.
For myself, I use Hyper-V to host test OSs on my PC. This installs a vEthernet network interface which is listed first for me, and my actual LAN is listed second. Again, everything works fine for LAN games except autodiscovery.
It seems that it’s not that unusual to have multiple network interfaces for various reasons, and there seem to be a lot of questions asked on the internet about why Minecraft LAN autodiscovery isn’t working.
Here’s what I would propose. I don’t know of any reason that Minecraft needs to allow this type of situation to become a barrier to autodiscovery. The solution that I’ve tested seems to work great, which is to send the UDP multicast packet once per network interface, binding a Windows socket to the IP of each network interface. The following can be executed in any PowerShell window on Windows to demonstrate a proof of concept:
$payload = '[MOTD]Your message here[/MOTD][AD]12345[/AD]'
$bytes = [System.Text.Encoding]::UTF8.GetBytes($payload)
foreach ($address in [System.Net.Dns]::GetHostEntry([System.Net.Dns]::GetHostName()).AddressList) {
if ($address.AddressFamily -ne [System.Net.Sockets.AddressFamily]::InterNetwork) {
continue
}
$udpClient = [System.Net.Sockets.UdpClient]::new()
$udpClient.Client.Bind(([IPEndPoint]::new($address, 0)))
[void] $udpClient.Send($bytes, $bytes.Length, '224.0.2.60', 4445)
$udpClient.Dispose()
}
If you do not bind the socket, it appears that the UDP multicast only sends through the first interface, which leads to the avoidable autodiscovery failure.
I suppose the receiving side of this would also have to have the mirroring update: creating a Windows socket bound to each network interface, and listening for the 224.0.6.2:4445 packet.