[0.12][cube] Headless server not working with more than one

[kovarex]

Hello, this should be solvable by the new option prepared for 0.12.4, to disable peer to peer option while connecting (packets sent through server).

[creodor]

That's wonderful news, and much faster than I expected. Thank you for letting us know, and especially thanks for the quick turn around; we'll make sure to test it out when everyone's available for it!

[Em3xus]

Hi,

I have followed the Linux headless server instructions to have the latest version (factorio_headless_x64_0.12.26.tar) running on a newly set up Ubuntu Server 14.04.4 LTS.

I am having the same issues as this thread, where anyone can connect to the server without issues, but when a second player tries to join I get errors like the following:

Code: Select all

  12.246 Info WindowsUDPSocket.cpp:73: Opening socket at port (34198)
  12.246 Info Router.cpp:582: Router state -> Connecting
  12.246 Verbose Router.cpp:197: Started router thread.
  12.248 Info MultiplayerManager.cpp:906: networkTick(0) mapTick(-1) changing state from(Ready) to(Connecting)
  12.280 Info Router.cpp:582: Router state -> WaitingForAccept
  12.523 Info Synchronizer.cpp:54: NetworkTick(68157) initialized Synchronizer local peer(12) latency(15).
  12.523 Info Synchronizer.cpp:500: networkTick(68157) adding peer(0) success(true).
  12.523 Info Synchronizer.cpp:500: networkTick(68157) adding peer(11) success(true).
  12.523 Info Router.cpp:582: Router state -> Connected
  12.523 Info Router.cpp:767: ConnectionAccepted ownPeerID(12) nextPeerID(13)
  12.523 Info MultiplayerManager.cpp:906: networkTick(68157) mapTick(-1) changing state from(Connecting) to(VerifyingConnection)
  14.182 Info Synchronizer.cpp:444: NetworkTick(68157) peer(11) drop detection state(100/600).
  15.842 Info Synchronizer.cpp:444: NetworkTick(68157) peer(11) drop detection state(200/600).
  17.503 Info Synchronizer.cpp:444: NetworkTick(68157) peer(11) drop detection state(300/600).
  19.165 Info Synchronizer.cpp:444: NetworkTick(68157) peer(11) drop detection state(400/600).
  20.846 Info Synchronizer.cpp:444: NetworkTick(68157) peer(11) drop detection state(500/600).
  22.503 Info Synchronizer.cpp:444: NetworkTick(68157) peer(11) drop detection state(600/600).
  22.521 Info Synchronizer.cpp:590: NetworkTick(68157) peer(11) peerHeartbeatsEmpty(true) is not responding, dropping.
  22.521 Error MultiplayerManager.cpp:110: MultiplayerManager failed: multiplayer.failed-to-connect-to-peer("FRIENDS_PUBLIC_IP:34199")
  22.521 Info MultiplayerManager.cpp:906: networkTick(68157) mapTick(-1) changing state from(VerifyingConnection) to(Failed)
  23.807 Info MultiplayerManager.cpp:161: NetworkTick(68157) quitting multiplayer connection.
  23.807 Info MultiplayerManager.cpp:906: networkTick(68157) mapTick(-1) changing state from(Failed) to(Disconnected)
  23.807 Info Router.cpp:556: Router peerID(12) shutting down.
  23.807 Verbose Router.cpp:279: Finishing router thread.

I have the headless server running on the default port (34197)
My desktop (on the same LAN as the server) is set to use port 34198.
As above, my friend even tried changing his port to 34199.
We have also tried other port configurations with the same result.

The save used for the server does not have peer-2-peer enabled as per the instructions. We also tried with it on for shits n giggles to the same effect.

We have both forwarded our ports.
In my case, I have the default port forwarded to the server, and 34198 forwarded to my desktop.

It seems like even though this latest update should enable communication from the server to my desktop, that our games are still trying to communicate directly.

We are each able to host a windows game via the normal steam menu without troubles and play, and have been playing on a friends Windows headless server also without issues.

[cube]

I must say I'm a little confused about what exactly is happening :-)
Just to make sure I understand correctly -- your setup looks like this:

Code: Select all

Server (server internal IP) --- N
                                A (your external IP) --- Internet --- Your friend's computer
Your computer ----------------- T

right?

But where is the log from? It's from your computer when you are trying to connect to your friend's machine? There's no need to do that when you have a server running on your LAN.

If the configuration is as in the picture, then it should be enough to forward some port (34197 for convenience) on the router to the servers internal address
(the record in the router's settings will look something like this: "UDP *:34197 -> server_itnernal_ip:34197"). Then you should be able to connect to the server from your computer using just "server internal IP" as an address, and your friend should use "your external IP" as an address.
We are using almost exactly this configuration in the office, so generally it works :-)

If you are hosting the game on your machine (not headless server), make sure that the "use peer to peer communication" check box is disabled. It just complicates things :-)

[Aranoxx]

I have the exact same problem. I followed the Headless installation guide and everything works well.
But as soon as some one else connect before me from outside the LAN, then I can't connect.

Right now two of my buddies play on the server and I am just sitting here and can't be part of the fun

[sekanz]

I'm having this same problem with 12.30 (this is my first Factorio server) on a headless server - Linux box. I can play fine with my friend if i host from my PC. On the server however, the second person who tries to join the Linux box always crashes the 1st clients session with the error on the second joining client that "it can't contact the first client (and gives their IP)". Either of us can join and play by ourselves on the server without a problem. It's as though it's using peer-to-peer even though i dint enable that option while starting up the server instance. I also tried adding the --peer-to-peer option to see if it made a difference - same error occurred.

factorio --latency 18 --start-server MPgame (right? 300 ms is for my Japanese friend, which works perfectly fine when i host from my PC)

And I'm fairly sure it has nothing to do with my network as i'm also hosting a MineCraft server which works great (also Linux, and plugged into the same switch that MC is plugged into).

Any ideas?

****EDIT****
i found something out... if i join via local IP to my server, no issues. but if I join through my public IP, i get the problems. so, i have a work around for this.

[Halandar]

Hi,

i got pretty much the same problem here.
One headless "server". Runs on linux as a hosted server, no firewall whatsoever. It has a public IPv4 Address.

I have 3 different clients connection. Each each of those on different locations, networks etc. But all with LAN addresses behind a router.

Client A can connect to server an play alone -> no problem
Client B can connect to server an play alone -> no problem
Client C can connect to server an play alone -> no problem

Client A can connect to server, while Client B is already on the server and vice verca -> no problem

but now Client C:
Client C is on the server -> nobody can join
Client C can not join server if anybody else is on

I did a few packet traces and had a closer look (even if tracing UDP is a pain!)
The problem seems to be the router of Client C

Every router does port randomization on outbound NAT. So heres the working example for Client A and B:

Client A connect to server_ip:34192, while doing that it gets an outbound NAT port of 1837

So view from client A is
local_ip_A:34192 -> server_ip:34192

Server view is
server_ip:34192 -> public_ip_A:1837

This works fine, as the router handles the backconnect in the session.

-------

Now client B comes in and gets pretty much the same, but also gets the clients info of the other connected clients:

So view from client B is:

local_ip_B:34192 -> server_ip:34192
local_ip_B:34192 -> public_ip_A:1837

Server view is
server_ip:34192 -> public_ip_A:1837
server_ip:34192 -> public_ip_B:20542

And now client A:
local_ip_A:34192 -> server_ip:34192
local_ip_A:34192 -> public_ip_B:20542


In my case this still works, becourse the routers are smart engough and handle the (back)connect of multiple hosts to the same port (1837 and 20542)

----

Now Client C seems not to be that smart and does not allow a second connection to its generated port (3647)

If any client (not headless) tries to connecto to the public_ip_C:PORT it seems to get dropped (can not tell for sure, becourse of UDP)
But here comes a strange part for me: client C tries a conneciton to for example clients A puclic IP and known port, but it gets another port for outgoing. So instead of using the same outgoing port as client A and B did, it uses a different one (+1). But client A still tries to connect to the port it gets from the server:

so here the view for client C:

local_ip_C:34197 -> server_ip:34197
local_ip_C:34197 -> public_ip_A:1837
local_ip_C:34197 -> public_ip_B:20542

this should be ok, but the router does soething strange here:
public_ip_C:3647 -> server_ip:34197 (ok)
public_ip_C:3648 -> public_ip_A:1837 (differnt outgoing port, client A tries to contact him on 3647)
public_ip_C:3649 -> public_ip_B:20542

-----

I am not sure if any of this helps, or if I am totaly misleaded by any of that... I am not realy expirienced with P2P technology. But for my situation it comes down to a problem with the router of client C, as A and B work perfectly fine together. I had no possiblity to verfiy the problem, as these router do not allow outbound NAT rules (34197 always to 34197).

If you want any more details, explanation or maybe a tracefile itself just ask, would be glad to help and not only confiuse

[Halandar]

I also noticed that clients with face ip4 pub addresses have often problem connection to a running game.

What are fake ipv4 addresses:
they actually only have a ipv6 address, but the provider does a ipv6 to ipv4 tunneling, so that they still have an ipv4. Problem is, that this ipv4 Address is shared by dozends of users and they do not realy have contole over it. Therefore often NAT Problems occour.

[cube]

Thanks for the observations, this looks like we have a small problem somewhere in the networking code :-)
Could you please post a log file from the server and from the client that fails to connect from a session like that? I have a suspicion of whaat might cause this, but the logs would help.

Meanwhile I'm reopening this bug.

[cube]

Duplicate of this bug: 23301

[Halandar]

We switched to use IPv6 onyl and that works with the all the clients, so I am pretty sure the problem is at the providers side. The clients IP4 address is shared by multiple users.
But I will still try to get the logs this week.

[NoPantsMcDance]

Still having this issue. Player joined at line 1739 and left at line 1875. Then myself and another user got the "server not responding" message and were removed from the game and had to rejoin the server.

[cube]

Still having this issue. Player joined at line 1739 and left at line 1875. Then myself and another user got the "server not responding" message and were removed from the game and had to rejoin the server.

I assume that this problem happens to you regularly? It might be helpful to get logs from both the server, and the disconnected player. Also it might help to have the logs with verbose logging enabled (last checkbox in setting > others). If you also control the server you can enable it by setting variable "verbose-logging" in config file section [other].

Sorry this is taking so long, but I can't reproduce this bug and in the logs so far I have seen it happen but not the reason.

[Halandar]

Hey guys, sorry for the late reply. Here are the logs.
Client A connected first to the headless client, no problem, then client B tried and failed. Then I stopped all the clients and copied the logs. All shoul be on verbose. Version of the game is 0.12.33 Build 18092

[Halandar]

uhm also:
It does work with ipv4 in my case, if you disable peer-to-peer on the headless client

[cube]

uhm also:
It does work with ipv4 in my case, if you disable peer-to-peer on the headless client

Oh, that's actually very good to hear.
P2P mode will be removed in 0.13, because the assumptions it makes are overly optimistic. It is able to give you improvements in latency, but it silently fails in too many cases.

Now NoPantsMcDance has this sort of problems even with client-server connection ...

[NoPantsMcDance]

Sorry for the delay on getting back to you with logs. Client log and server log with verbose logging on attached.

[NoPantsMcDance]

This is still an issue. There was 8 players on the server and I joined. It kicked one player from the server. This player then rejoined and it kicked everyone else from the server. Maybe this is a problem on my end and if so what the hell is causing it. The server isn't run on my computer or even on my net. Logs attached from client and server.

[NoPantsMcDance]

As requested the server log, I turned verbose back off hope that's not a problem. It was making my log parsing script work much harder than it needed to.

[NoPantsMcDance]

Could be unrelated but shortly after this it went into a desync loop.