The root cause of this is the multicast interface selection used by the LAN-scan thread on the receiving end.
Where the bug is:net.minecraft.client.server.LanServerDetection$LanServerDetector opens a MulticastSocket and joins the LAN discovery group using the legacy MulticastSocket.joinGroup(InetAddress) overload. That overload does not let the caller pick a network interface — it silently defers to whatever interface the OS/JVM's default route resolution picks. On a machine with only one real network adapter, that default is almost always correct, which is why this is intermittent and hard to reproduce reliably. On a machine with several adapters — VPN clients, VMware/VirtualBox host-only or NAT adapters, Docker/WSL bridges, Hyper-V virtual switches, etc. — the OS/JVM's chosen "default" interface is frequently a virtual one with no route to the actual LAN, so the multicast group membership never gets registered on the interface the "Share to LAN" broadcast is actually arriving on. Direct-connect-by-IP still works because that's ordinary unicast TCP, unaffected by multicast group membership.
Why it matches the reports here: this explains the pattern across the duplicates on this ticket — works on some machines and not others on the same network, works after a reinstall/OS change that altered adapter ordering, "some computers see each other, others don't" on a LAN with mixed configurations. It's consistent with an interface-selection bug rather than a protocol regression, since the sending side (LanServerPinger) sends plain UDP broadcast and isn't affected the same way.
The fix: in the receiver's constructor, replace the interface-agnostic socket.joinGroup(group) call with the modern joinGroup(SocketAddress, NetworkInterface) overload, and explicitly join the group on every network interface that looks like a genuine, active adapter (up, multicast-capable, not loopback/point-to-point, carrying an IPv4 address) — instead of relying on whichever interface the OS/JVM defaults to. Deliberately not filtering by adapter name/type beyond that: someone may be legitimately hosting or joining from inside a VM, so a virtual adapter is still a valid one to join on. If no such interface is found, fall back to the original behavior. This is a small, self-contained change and doesn't affect the sending side or direct-connect at all.
I've verified this class and its constructor have been structurally unchanged since at least 1.14.4 through current versions, so a single fix along these lines would apply across the affected version range in this ticket.
steigr
The root cause of this is the multicast interface selection used by the LAN-scan thread on the receiving end.
Where the bug is:
net.minecraft.client.server.LanServerDetection$LanServerDetectoropens aMulticastSocketand joins the LAN discovery group using the legacyMulticastSocket.joinGroup(InetAddress)overload. That overload does not let the caller pick a network interface — it silently defers to whatever interface the OS/JVM's default route resolution picks. On a machine with only one real network adapter, that default is almost always correct, which is why this is intermittent and hard to reproduce reliably. On a machine with several adapters — VPN clients, VMware/VirtualBox host-only or NAT adapters, Docker/WSL bridges, Hyper-V virtual switches, etc. — the OS/JVM's chosen "default" interface is frequently a virtual one with no route to the actual LAN, so the multicast group membership never gets registered on the interface the "Share to LAN" broadcast is actually arriving on. Direct-connect-by-IP still works because that's ordinary unicast TCP, unaffected by multicast group membership.Why it matches the reports here: this explains the pattern across the duplicates on this ticket — works on some machines and not others on the same network, works after a reinstall/OS change that altered adapter ordering, "some computers see each other, others don't" on a LAN with mixed configurations. It's consistent with an interface-selection bug rather than a protocol regression, since the sending side (
LanServerPinger) sends plain UDP broadcast and isn't affected the same way.The fix: in the receiver's constructor, replace the interface-agnostic
socket.joinGroup(group)call with the modernjoinGroup(SocketAddress, NetworkInterface)overload, and explicitly join the group on every network interface that looks like a genuine, active adapter (up, multicast-capable, not loopback/point-to-point, carrying an IPv4 address) — instead of relying on whichever interface the OS/JVM defaults to. Deliberately not filtering by adapter name/type beyond that: someone may be legitimately hosting or joining from inside a VM, so a virtual adapter is still a valid one to join on. If no such interface is found, fall back to the original behavior. This is a small, self-contained change and doesn't affect the sending side or direct-connect at all.I've verified this class and its constructor have been structurally unchanged since at least 1.14.4 through current versions, so a single fix along these lines would apply across the affected version range in this ticket.