LAN lobby discovery fails between Linux and macOS builds

[fbraz3]

Summary

LAN game discovery in the LAN Gaming screen is failing across platforms (Linux host <-> macOS client, and likely same-platform too). The two machines do not see each other in the LAN game list.

Observed behavior

• Linux machine opens LAN lobby and hosts a game.
• macOS machine opens LAN lobby on the same network segment.
• Neither side sees the other game in the LAN list.

Expected behavior

• LAN lobbies should discover hosts across Linux/macOS (and Linux/Linux, macOS/macOS) when machines are on the same subnet.

Investigation notes (code pointers)

Current LAN discovery uses UDP broadcast on port 8086:

• Core/GameEngine/Source/GameNetwork/LANAPI.cpp:84
  • m_broadcastAddr = INADDR_BROADCAST;
• Core/GameEngine/Source/GameNetwork/LANAPI.cpp:203
  • Broadcast send path uses m_broadcastAddr for discovery/announce traffic.

Local IP selection in LAN lobby defaults to the first enumerated address when no default is configured:

• GeneralsMD/Code/GameEngine/Source/GameClient/GUI/GUICallbacks/Menus/LanLobbyMenu.cpp:423
• GeneralsMD/Code/GameEngine/Source/GameClient/GUI/GUICallbacks/Menus/LanLobbyMenu.cpp:439

On POSIX, interface enumeration currently includes non-loopback interfaces that are merely IFF_UP, then sorts by numeric IP:

• Core/GameEngine/Source/GameNetwork/IPEnumeration.cpp:110
• Core/GameEngine/Source/GameNetwork/IPEnumeration.cpp:198

This can prefer Docker/VPN/virtual NIC addresses over the active LAN NIC, causing bind+broadcast behavior that does not reach peers.

Main hypotheses

1. Broadcast target too generic

   • Using only 255.255.255.255 (INADDR_BROADCAST) may not be reliable across all Linux/macOS interface/routing setups.
   • Per-interface subnet broadcast (e.g. 192.168.x.255) may be required/reliable.

2. Wrong local NIC/IP auto-selected

   • LAN lobby defaults to first enumerated IP if no default is set.
   • Enumeration can include virtual interfaces and ordering is IP-ascending, not route/interface-quality based.

3. Insufficient diagnostics

   • LAN failure path only signals generic socket error, making root-cause confirmation hard without targeted logging.

Proposed investigation plan

1. Add temporary debug logs in LAN init/update paths for:
   • selected local IP
   • socket bind result/error
   • broadcast destination used
   • incoming packet source addresses in LANAPI update loop
2. Improve IP enumeration and selection policy on POSIX:
   • exclude non-broadcast/multicast-capable virtual interfaces where appropriate
   • prefer active default-route interface
   • keep manual override via options menu
3. Support/try per-interface broadcast addresses instead of only INADDR_BROADCAST.
4. Validate matrix:
   • Linux <-> Linux
   • macOS <-> macOS
   • Linux <-> macOS

Acceptance criteria

• Two machines on the same subnet can discover each other in LAN Gaming for all pairs above.
• LAN host announcement/request traffic is visible in logs with selected NIC/IP and broadcast destination.
• No regression in Windows LAN discovery behavior.

Notes

This issue is focused on GeneralsXZH LAN discovery path first (can be backported where shared).