[1.1.53] Can't connect to LAN game on headless server but 1.0 works

[robot256]

Tl;dr: My setup actively works with a Factorio 1.0.0 game. It does not work for a Factorio 1.1.53 game on the same hardware

My old 1.0 server and client work perfectly together, even after a fresh install of Linux on the server and upgrading my router to a Unifi system. I have never been able to connect my 1.1 client to my 1.1 server, running on the same two machines (after shutting down the 1.0 server, of course). I first tried back on 1.1.43 or so in December 2021, and the problem still exists in 1.1.53.

The server starts and appears in the client's Browse LAN list, but joining the game always times out before the server even seems to acknowledge anything. The fact that older versions still work makes me think it can't be a hardware or firewall issue, but I haven't seen anyone else with the same problem on 1.1.X so it has to be something unique. I'm at my wit's end and found only one other post with a similar problem (from 2017) and no posted resolution. I'm not new to the amateur network and sysadmin game, but I sincerely don't know how to continue debugging this. Any suggestions are eagerly awaited!

Steps to reproduce on my setup:

1. Load existing save on Client 1. Sync mods to new install directory.
2. Copy mods, mod settings, and save file to new headless server on Server.
3. Start factorio server inside a Screen session.

   Code: Select all

   ./bin/x64/factorio --start-server-load-latest --server-settings ./server-settings.json

4. See game listed in "Browse LAN" on Client 1 and Client 2.
5. Attempt to connect, get "Could not communicate with server" error every single time.
6. No entry whatsoever in "factorio-current.log", except for once when it said "connection rejected due to mod mismatch" when I had intentionally changed the client's mods.

The client log file contains for each failed attempt:

Code: Select all

213.898 Joining game IP ADDR:({192.168.1.124:34197})
 213.898 Info UDPSocket.cpp:33: Opening socket
 213.900 Info ClientMultiplayerManager.cpp:610: UpdateTick(4294967295) changing state from(Ready) to(Connecting)
 223.945 Error ClientMultiplayerManager.cpp:98: MultiplayerManager failed: multiplayer.not-received-connection-accept-reply
 223.946 Info ClientMultiplayerManager.cpp:610: UpdateTick(4294967295) changing state from(Connecting) to(InitializationFailed)
 248.231 Info ClientMultiplayerManager.cpp:210: Quitting multiplayer connection.
 248.231 Info ClientMultiplayerManager.cpp:610: UpdateTick(4294967295) changing state from(InitializationFailed) to(Disconnected)
 248.315 Info UDPSocket.cpp:218: Closing socket
 248.315 Info UDPSocket.cpp:248: Socket closed

The server log simply looks like this, with nothing further:

Code: Select all

 46.732 Info UDPSocket.cpp:27: Opening socket at (IP ADDR:({0.0.0.0:34197}))
  46.732 Hosting game at IP ADDR:({0.0.0.0:34197})
  46.732 Info ServerMultiplayerManager.cpp:797: updateTick(3023888) changing state from(CreatingGame) to(InGame)
  46.733 Info UDPSocket.cpp:39: Opening socket for broadcast

Combing through a Wireshark packet log of the failed connection attempt, I see the following:

1. Client sends 12 bytes from port 61323 to server port 34197.
2. Server responds with 22 bytes.
3. 12ms later, Client sends a series of 19 packets containing the client modlist, which takes one millisecond total to send.
4. 4ms later, Server responds with three 25-byte packets and one 21-byte packet, each 100ms apart, like it is waiting for a response.
5. There is no further response from the client, and the client times out after 30 seconds.

So it looks like the client can hear the server's initial request for the client modlist, but can't hear the server say "yes it's okay to join". The server doesn't get far enough along in the handshake to even record a log entry.

Server:

• Debian 11 (recently upgraded from Debian 8)
• Intel Core i3-4370
• 16GB RAM
• Factorio stored on 9TB Raid Z
• Minecraft and InfluxDB servers running flawlessly
• No firewall running
• Fixed IP assigned by DHCP

Client 1:

• Windows 10 (Desktop)
• Intel Core i5-3570K
• 24GB RAM
• Nvidia GTX950
• 256GB SSD
• Gigabit Ethernet connection to LAN
• Fresh zip download of Factorio 1.1.53
• Eset firewall installed, disabled
• Can connect to public online games

Client 2:

• Windows 10 (Laptop)
• i5-10210U
• 20GB RAM
• 256GB SSD
• WiFi 5GHz connection to LAN
• Updated zip download of Factorio 1.1.53
• Windows firewall installed, running with exceptions, or disabled
• Can connect to public online games

Network:

• Unifi Dream Machine Pro router and Unifi switch, fully updated
• Clients and server on same VLAN
• Port forwarding configured (not needed for LAN play), but works for Minecraft as well

[robot256]

Update:

I get the same result when Client 1 Steam client tries to connect to Server headless server.

I get the same result when Client 1 standalone hosts the game and Client 2 Steam client tries to connect to it.

I get the same result when Client 1 Steam client hosts the game in LAN mode and Client 2 Steam client tries to connect to it.

This post describes a similar symptom, and the solution was to connect two Steam clients to each other to get around some sort of network problem. I have no idea how I could have a NAT problem when both computers are on the same LAN. viewtopic.php?f=49&t=101647&p=561969#p561969

[Atraps003]

Have you tried testing with two instances of factorio on the same computer?

[robot256]

Solution found: had to change mods / mod settings.

Just now, I discovered that my server is accessible after uninstalling a few mods. I first confirmed that a server with no mods worked, which means either something changed or I completely forgot that step initially.

Specifically, I was trying to use the combination of Alien Biomes, Dectorio, and Asphalt Paving. This only works with a specific set of custom mod settings, and the default settings exceed the tile limit and prevents the game from loading. When loading the save file in single player, the mods and settings are normally synchronized at the same time, so this condition rarely occurs.

But when joining a multiplayer server, mods and settings are NOT synchronized at the same time. The active mod list is updated, the game is restarted, and a second connection attempt and restart is needed to synchronize mod settings (at least when one of the custom settings is for a newly-downloaded mod). This often results in the tile limit error occurring. If you manually load the correct mod-settings.dat file and attempt to connect, THAT is when the connection failure occurs.

After deleting Dectorio and Asphalt Paving, I could successfully synchronize mods, synchronize settings, and join the game.

I believe it has something to do with the mod setting verification process. I will figure out a minimal reproduction case and post a formal bug report.

[robot256]

Following up that I did resolve my issue completely by making a fresh mod settings file and fixing that bug in Dectorio. (The new mod-settings.json is only 21kB instead of 76kB.) There is still the issue that syncing mods doesn't work because the first time you enable all the mods, there are too many tiles, so you can never get to the second sync step to change the mod settings. Reported in these two threads:

viewtopic.php?f=7&t=101654

viewtopic.php?f=7&t=101655