Factorio Forums

I've been playing modded Factorio multiplayer with a friend for several weeks. We started on 2.0.69, and are now on 2.0.72.

We had some trouble initially, which lead us to switch from IPv4 to IPv6, because he couldn't connect to my server over IPv4 due to it not recognizing that mods were synced even though they were. We suspect a packet fragmentation issue, since it was dependent on the size of the modlist rather than which specific mods were loaded.

Now he can't join the game over IPv6 either. It shows the connection attempts, which consist of a connection attempt, followed by a UserVerificationError, and then silently fails. Ping works fine, at ~20-30ms, and he can connect if I run the server without mods. Any suggestions for getting it working again?

Example of a connection attempt:
117495.613 ConnectionRequestReplyConfirm (type(ConnectionRequestReplyConfirm) ) from(IP ADDR:({[REDACTED]:49914}))
117495.615 Refusing connection for address (IP ADDR:({[REDACTED]:49914})), username (REDACTED). UserVerificationMissing

I got Wireshark out and confirmed that the problem was packet loss. By comparing a successful and unsuccessful (from my friend) connection (from me) on both ends, we determined it was a router configuration issue that was causing it to drop the middle fragments of one of the handshake messages. Tweaking the router settings made it work some of the time, so far, but it's still not completely reliable.

Once the game connects, we have a very stable connection, with minimal latency, since we're on the same ISP and geographically closeby. It's only the handshake that's a problem, and the handshake packets are huge; they contain the entire list of enabled mods. If it's not already in the feature requests/suggestions list, I'd like to suggest making the multiplayer handshake more robust.

That's interesting that you have a router issue that's capable of killing packets. Were you hitting a max payload size like MTU? Was it trying to use jumbo frames but failing somewhere along the way?

I once had a similar issue with Streets of Rogue using too many mods at a time hitting some sort of theoretical packet length limit that would cause timeouts despite both computers being on the same local network.

Early on while we were playing this save, we were having extreme latency issues, despite having more than enough bandwidth, and ICMP ping latency being consistently low. In response, I set up QoS and traffic shaping on my router, which worked amazingly well for Factorio; he went from having 20+ tick latency down to less than 8 most of the time.

Traffic shaping sometimes drops packets -- that's intended behavior -- and for TCP, that's fine, since TCP is a reliable protocol and will just resend them. Factorio uses UDP, which leaves resending dropped packets up to the application, and Factorio apparently doesn't do that during the handshake.

I confirmed it was my traffic shaping configuration was source of that specific packet loss, because it keeps a count of how many packets it drops, and that counter went up by the number of missing packets each time my friend tried to connect. I incrased its buffer size (the setting is technically called 'bucket size ratio' on my router) a bit so it stopped dropping them in exchange for potentially higher latency.

In this instance, it's partially a problem of my own creation, but actually debugging it was a pain. I'm not sure if we'd have figured it out at all without Wireshark. That packet loss sensitivity might explain why some people suggest running Factorio over a VPN, since that would wrap its traffic in a reliable protocol (and introduce its own latency.)

It's me. I'm the friend. The problem we observed was a result of Factorio apparently requiring 0% packet loss during the initial connection handshake. (Despite tolerating it quite well during actual gameplay) This is not reasonable for an internet application, especially when its behavior during the handshake (under certain conditions) is almost guaranteed to cause packet loss.


We noted, in the capture, that the server's response to my join request was never fully received. ConnectionAcceptOrDeny message would be fragmented into 83(!) 504-byte segments, and I would receive, on average, 70 of them. The typical pattern was for me to receive packets 1-49, and then 64-83.


My client would then respond by re-sending it's previous ConnectionRequestReplyConfirm packet, to which the server would respond with a repeat of the ConnectionAcceptOrDeny message which would be once again, missing its middle segment.


After the second attempt, it seemed to simply give up, and display the frustratingly vague "Could not establish network communication with the server" message.


As a side note, the fact that this is the message displayed for everything from "address unreachable" to "I talked to the server and didn't like what it said" is rather frustrating.

We determined that this failure was the result of a couple of factors:

1. The ConnectionAcceptOrDeny message contains the complete list of installed mods on the server. This is quite reasonable, and clearly necessary for the client to synchronize its mod list with the server, if the user so chooses. However, in the event that the server is running a large mod list (279 mods, in our case) this message can be relatively long. (~42KB in this case)
   1. It appears that Factorio fragments this message into packets likely to be below the MTU of any internet connected network; in this case 504 bytes.
   2. With a large mod list, this message is split into a large number of packets, all sent in rapid succession.
   3. If any of the fragments are lost, there is no mechanism for the client to request their individual retransmission, so its only option seems to be to repeat the previous request and receive entire message again.
2. Sending a large number of UDP packets in a single burst is extremely likely to cause some of them to be dropped. Traffic shaping and OoS features in routers are designed to prevent applications from monopolizing the network by dropping their packets if they are deemed too chatty, until they settle down. TCP is designed to work with this behavior via its exponential backoff and retry behavior, where it will slow down its transmission rate if packets are lost, until it finds a speed at which communication appears to be reliable. Applications which use UDP are opting out of this process because they value timely delivery over in-order, reliable, and complete data transfer.

I've seen posts about similar problems, and as far as I can tell their solution was generally "use a VPN" which strikes me as both something which should not be required to play a game, and also defeats the purpose of using UDP transport for gameplay, since this is effectively tunneling the game's traffic through TCP. We played DOOM (1993) and hosted a Minecraft server over this connection, and neither had any issues, only Factorio did. The fact that in our case, the traffic shaping was under our control doesn't mean that it will be for everyone, either due to it being actually outside their control, such as when done by an ISP, or simply outside of their technical knowledge.

Factorio should use reliable transport for functions which clearly require reliability. Either by implementing proper per-packet retransmission for handshake messages which can be fragmented, or by simply using TCP for the handshake.