You can try editing config.ini on the computer you're trying to play on (not the server). Change the port value to something other than the default – for instance, set port=34198. You might have to set up port forwarding to forward 34198 to your computer.
And yes, this seems to be yet another limitation of our multiplayer architecture. :/
[0.12][cube] Headless server not working with more than one
Re: [0.12] Headless server not working with more than one player
I've found the problem. Well, at least my problem, maybe not OPs.
I've set up my modem/router so that all traffic on port 34197 UDP+TCP is going to my PC, and I thought it worked because TCP worked just fine when testing, I just didn't know how to test UDP (that's what factorio uses).
It seems my router doesn't handle UDP traffic particularily well, because factorio didn't work.
I've found out that my router has a DMZ setting where all traffic coming in is by default routed to one specified PC. Additionally, it actually assigns the external IP you get from your provider to that PC. After I enabled that, Factorio worked like a charm in multiplayer. I was able to connect to my server and had a fun time just marveling about what other players have created on it.
PLEASE NOTE: Should you have the same problems as me and your router has the same settings, be aware that not only does it forward traffic for Factorio, it forwards ALL the traffic coming in to your PC. Make sure you have a properly configured firewall and anti-virus on your PC.
The only thing that bugs me is that the error message is Following peers are not responding: unknown username, ...
Then the dialog pops up and says Failed to establish connection with peer x.x.x.x:x
It makes it look like the server is running but other peers are not responding, although the problem lies on your end.
I've suggested before that after connecting the server should check whether the client's port is open before proceeding any further.
EDIT: to clarify, the server is not on my network, in fact it is hosted in France, while I'm in Austria. So changing port doesn't apply here.
I've set up my modem/router so that all traffic on port 34197 UDP+TCP is going to my PC, and I thought it worked because TCP worked just fine when testing, I just didn't know how to test UDP (that's what factorio uses).
It seems my router doesn't handle UDP traffic particularily well, because factorio didn't work.
I've found out that my router has a DMZ setting where all traffic coming in is by default routed to one specified PC. Additionally, it actually assigns the external IP you get from your provider to that PC. After I enabled that, Factorio worked like a charm in multiplayer. I was able to connect to my server and had a fun time just marveling about what other players have created on it.
PLEASE NOTE: Should you have the same problems as me and your router has the same settings, be aware that not only does it forward traffic for Factorio, it forwards ALL the traffic coming in to your PC. Make sure you have a properly configured firewall and anti-virus on your PC.
The only thing that bugs me is that the error message is Following peers are not responding: unknown username, ...
Then the dialog pops up and says Failed to establish connection with peer x.x.x.x:x
It makes it look like the server is running but other peers are not responding, although the problem lies on your end.
I've suggested before that after connecting the server should check whether the client's port is open before proceeding any further.
EDIT: to clarify, the server is not on my network, in fact it is hosted in France, while I'm in Austria. So changing port doesn't apply here.
Re: [0.12] Headless server not working with more than one player
I would just like to mention that my friends and I have set up a dedicated headless server that is off-site and we've run into this same issue as well. None of us are on LAN with each other or the server and some are unable to do port forwarding, and even some of the ones who *do* have their ports forwarded correctly can't join. It's a miracle if we can get even two people in the game together.
I know multiplayer was an afterthought but peer-2-peer is not a viable solution. When this game launches on Steam people are immediately going to try to play with each other and the immense difficulty (and luck!) involved in doing so will be a major problem. I know that re-doing the netcode will be a major effort. Personally I think it would be worth it for you guys to do so, but I'm not privy to the inner-workings of your team so I can only suggest that you cease all non-networked development for the time being and just focus on getting the game's multiplayer functioning up to the standards people on Steam are used to.
The alternative is to remove multiplayer functionality entirely. I really like this game and I want to see it succeed, but a broken multiplayer experience will turn a lot of people away.
Best of luck.
I know multiplayer was an afterthought but peer-2-peer is not a viable solution. When this game launches on Steam people are immediately going to try to play with each other and the immense difficulty (and luck!) involved in doing so will be a major problem. I know that re-doing the netcode will be a major effort. Personally I think it would be worth it for you guys to do so, but I'm not privy to the inner-workings of your team so I can only suggest that you cease all non-networked development for the time being and just focus on getting the game's multiplayer functioning up to the standards people on Steam are used to.
The alternative is to remove multiplayer functionality entirely. I really like this game and I want to see it succeed, but a broken multiplayer experience will turn a lot of people away.
Best of luck.
Re: [0.12][cube] Headless server not working with more than one
Please can you verify if this is caused by at least one peer being connected through an internal IP (typically 10.0.something or 192.168.something) and one through the internet?
I attempted to write a little explanation how things (don't) work in this case: https://forums.factorio.com/forum/vie ... =10#p93014
I attempted to write a little explanation how things (don't) work in this case: https://forums.factorio.com/forum/vie ... =10#p93014
Re: [0.12][cube] Headless server not working with more than one
No peers are connected through an internal IP. The server is located in a data center in California while the three players (including myself) we tested the most thoroughly with were in Texas, Virginia, and Pennsylvania. None of us were using a VPN of any sort.
The Texas player and the Virginia player both had their ports forwarded correctly. The Pennsylvania player did not have the ability to forward ports.
We tested as such:
Pennsylvania joins first -> Success
Pennsylvania joins first, Virginia joins second -> Success (but failed in 1/3 attempts. Nothing was done differently)
Pennsylvania joins first, Virginia joins second, Texas joins third -> Failure
Pennsylvania joins first, Texas joins second -> Failure
Texas joins first -> Success
Texas joins first, Pennsylvania joins second -> Failure (but did succeed in one attempt. Nothing was done differently)
Texas joins first, Virginia joins second -> Failure
Virginia joins first -> Success
Virginia joins first, Pennsylvania joins second -> Success (also failed in 1/3 attempts. Nothing was done differently)
Virginia joins first, Pennsylvania joins second, Texas joins third -> Failure
Virginia joins first, Texas joins second -> Failure
Each one of these steps was attempted several times each.
It seems pretty obvious that Texas is the problem child here, but that player double and triple-checked that his ports were forwarded and he had done everything short of setting his desktop as the DMZ (which would have been an exceptionally bad idea). Also he is a Tier 2 IT Support, so I trust that he knows what he's doing.
EDIT: We had a couple other players on from various locations/countries and with varying degrees of success for each, but for the duration of the testing described above it was only the three players (plus the headless server of course).
The Texas player and the Virginia player both had their ports forwarded correctly. The Pennsylvania player did not have the ability to forward ports.
We tested as such:
Pennsylvania joins first -> Success
Pennsylvania joins first, Virginia joins second -> Success (but failed in 1/3 attempts. Nothing was done differently)
Pennsylvania joins first, Virginia joins second, Texas joins third -> Failure
Pennsylvania joins first, Texas joins second -> Failure
Texas joins first -> Success
Texas joins first, Pennsylvania joins second -> Failure (but did succeed in one attempt. Nothing was done differently)
Texas joins first, Virginia joins second -> Failure
Virginia joins first -> Success
Virginia joins first, Pennsylvania joins second -> Success (also failed in 1/3 attempts. Nothing was done differently)
Virginia joins first, Pennsylvania joins second, Texas joins third -> Failure
Virginia joins first, Texas joins second -> Failure
Each one of these steps was attempted several times each.
It seems pretty obvious that Texas is the problem child here, but that player double and triple-checked that his ports were forwarded and he had done everything short of setting his desktop as the DMZ (which would have been an exceptionally bad idea). Also he is a Tier 2 IT Support, so I trust that he knows what he's doing.
EDIT: We had a couple other players on from various locations/countries and with varying degrees of success for each, but for the duration of the testing described above it was only the three players (plus the headless server of course).
Re: [0.12][cube] Headless server not working with more than one
quote
Could you please post server and texas log form texas joining second?Re: [0.12][cube] Headless server not working with more than one
I'm 'Texas' from Rein's comment, and also the owner/operator of the server in question. The server is physically located in Las Vegas, Nevada; it's out of state for everyone involved, no local networks involved at all.
As requested, I pulled the logs from both the server and my client. Neither was set for verbose logging, and I'm not 100% sure anymore that these are matching logs. We can and will perform the tests again and provide better match-sets of logs for you to look over, but we won't be able to do that until later tonight when everyone involved is available.
Full logs are attached to this post; the client log was too big for pastebin and similar sites.
I noticed a specific segment that seems to be the source of the problem, and it doesn't *look* like it's port forwarding related at all, but something else going wrong. I could be incorrect, of course, but as said before I've verified multiple times that port forwarding is correct. And in advance, no, I will not set my computer to DMZ to verify this. Anyways. What I noticed (this is on my client side) is that after the map is downloaded, state changes are completed, and it's then trying to add peer 2 (Pennsylvania) to my client's game, the client mixes up peer 2 with the server:
Initially I thought maybe it was a CRC error with the map download, but during the dropout of peers, the game confirms that CRC matches the expected value.
After dropping peer 2, it does the same thing for peer 1 (Virginia), saying it's getting the server's IP instead of the expect value.
Just to forestall statements of 'oh you just don't have port forwarding setup right', I took screenshots:
(For clarity, 34197 | 34198 is the port range, start | end. I cut that part off in the screenshot. I have more than one server running, to test things, but these logs and tests were done on the main non-testing server instance)
As requested, I pulled the logs from both the server and my client. Neither was set for verbose logging, and I'm not 100% sure anymore that these are matching logs. We can and will perform the tests again and provide better match-sets of logs for you to look over, but we won't be able to do that until later tonight when everyone involved is available.
Full logs are attached to this post; the client log was too big for pastebin and similar sites.
I noticed a specific segment that seems to be the source of the problem, and it doesn't *look* like it's port forwarding related at all, but something else going wrong. I could be incorrect, of course, but as said before I've verified multiple times that port forwarding is correct. And in advance, no, I will not set my computer to DMZ to verify this. Anyways. What I noticed (this is on my client side) is that after the map is downloaded, state changes are completed, and it's then trying to add peer 2 (Pennsylvania) to my client's game, the client mixes up peer 2 with the server:
Verified with the user that 69.249.xxx.xxx is indeed our Pennsylvania player, and I verified myself that 23.226.xxx.xxx is my server. From what I see in the log, and my admittedly basic understanding of how the networking is handled, it looks like my client is mixing up the server and our Pennsylvania player. I have no idea why that might happen.124.972 Info MultiplayerManager.cpp:1160: networkTick(3218) mapTick(1260413) stopping mapAlign
124.972 Info MultiplayerManager.cpp:1654: performing map align task (SendPlayerJoinGameAlignTask)
124.972 Info MultiplayerManager.cpp:848: networkTick(3218) mapTick(1260413) changing state from(InGameWaitingForOthers) to(InGame)
124.972 Info MultiplayerManager.cpp:1470: networkTick(3218) mapTick(1260413) peerID(1) fullStateLog: local state(InGame) local peers(((peerID(0) state(InGameWaitingForOthers) mapAlignTick(-1))
((peerID(1) state(InGameWaitingForOthers) mapAlignTick(-1))
)
125.044 Info MultiplayerManager.cpp:989: networkTick(3224) mapTick(1260418) received stateChanged peerID(0) oldState(InGameWaitingForOthers) newState(InGame)
125.044 Info MultiplayerManager.cpp:989: networkTick(3224) mapTick(1260418) received stateChanged peerID(1) oldState(InGameWaitingForOthers) newState(InGame)
125.099 Info NetworkInputHandler.cpp:703: mapTick(1260422) networkTick(3228) connecting to player(creodor).
125.099 Info NetworkInputHandler.cpp:561: assigning playerIndex(0) to peer(1)
125.099 Info GameActionHandler.cpp:1913: MapTick(1260422) processed PlayerJoinGame peerID(1) playerIndex(0) mode(connect)
175.444 Info Router.cpp:648: networkTick(6235) adding peer(2) address(69.249.xxx.xxx.34197) sending connectionAccept(false)
175.444 Info Synchronizer.cpp:491: networkTick(6235) adding peer(2) success(true).
175.535 Warning Router.cpp:202: Parsed peerID(2) expected address(69.249.xxx.xxx.34197) doesn't match received address(23.226.xxx.xxx:34197)
175.564 Warning Router.cpp:202: Parsed peerID(2) expected address(69.249.xxx.xxx:34197) doesn't match received address(23.226.xxx.xxx:34197)
175.570 Warning Router.cpp:202: Parsed peerID(2) expected address(69.249.xxx.xxx:34197) doesn't match received address(23.226.xxx.xxx:34197)
Initially I thought maybe it was a CRC error with the map download, but during the dropout of peers, the game confirms that CRC matches the expected value.
After dropping peer 2, it does the same thing for peer 1 (Virginia), saying it's getting the server's IP instead of the expect value.
Just to forestall statements of 'oh you just don't have port forwarding setup right', I took screenshots:
(For clarity, 34197 | 34198 is the port range, start | end. I cut that part off in the screenshot. I have more than one server running, to test things, but these logs and tests were done on the main non-testing server instance)
- Attachments
-
- server-factorio-current.log
- Server Log
- (167.97 KiB) Downloaded 273 times
-
- creo-client-factorio-current.log
- Texas Client Log
- (2.46 MiB) Downloaded 282 times
Re: [0.12][cube] Headless server not working with more than one
just out of curiosity, which port is your client using? As you mentioned you have other servers running for test purposes - does shutting them down and ensuring your client is the only active game on your local network have any effect ont he outcome at all? (just throwing it out there, not really expecting it to have an impact but who knowscreodor wrote:(For clarity, 34197 | 34198 is the port range, start | end. I cut that part off in the screenshot. I have more than one server running, to test things, but these logs and tests were done on the main non-testing server instance)
)Hosting a factorio server? Take a look at this || init script ||.
Re: [0.12][cube] Headless server not working with more than one
I just have both ports forwarded for occasions where I run and connect to the test server instance. While diagnosing this, only client/server instances using port 34197 were running; 34198 was unused during all of this, I was merely clarifying why that port was in the open range.
Re: [0.12][cube] Headless server not working with more than one
Cube: We have redone our testing and saved logs for each test. Note that the Server was restarted after each test. The label format is as such: [Test #] - [Log source] - [Order of joining map 1st-2nd-3rd]
These are the users, their locations, IPs, and the number of times their IP showed up in all 20 files:
Creodor (Texas): 64.92.xxx.xxx - 33 hits 14 files
Rein (Virginia): 100.36.xxx.xxx - 2433 hits in 10 files
Dakkan (Pennsylvania): 69.249.xxx.xxx - 2434 hits in 9 files
Server (Nevada): 23.226.xxx.xxx - 4844 hits in 14 files
Below are the logs for our tests as well as the number of times each IP shows up in each file:
Test 1 - Creodor - Dakkan-Rein-Creodor http://pastebin.com/UdL7xuxF (Server:1210, Dakkan:605, Rein:605, Creodor:0)
Test 1 - Dakkan - Dakkan-Rein-Creodor http://pastebin.com/WmN133NS (Server:2, Dakkan:0, Rein:1, Creodor:1)
Test 1 - Rein - Dakkan-Rein-Creodor http://pastebin.com/ZqJCrjEw (Server:1, Dakkan:0, Rein:0, Creodor:1)
Test 1 - Server - Dakkan-Rein-Creodor http://pastebin.com/TnREWC8T (Server:0, Dakkan:4, Rein:4, Creodor:4)
Test 2 - Creodor - Dakkan-Creodor http://pastebin.com/ZVZWWqrb (Server:607, Dakkan:607, Creodor:0)
Test 2 - Dakkan - Dakkan-Creodor http://pastebin.com/W9ULyPGk (Server:3, Dakkan:0, Creodor:2)
Test 2 - Server - Dakkan-Creodor http://pastebin.com/1yciRvqW (Server:0, Dakkan:4, Creodor:4)
Test 3 - Creodor - Creodor-Dakkan http://pastebin.com/BseZa0C9 (Server:601, Dakkan:601, Creodor:0)
Test 3 - Dakkan - Creodor-Dakkan http://pastebin.com/m2Tr8Fz9 (Server:1, Dakkan:0, Creodor:1)
Test 3 - Server - Creodor-Dakkan http://pastebin.com/h2MhSdeK (Server:0, Dakkan:4, Creodor:4)
Test 4 - Creodor - Creodor-Rein http://pastebin.com/M1aF2DaR (Server:601, Rein:601, Creodor:0)
Test 4 - Rein - Creodor-Rein http://pastebin.com/cgSPbqxP (Server:1, Rein:0, Creodor:1)
Test 4 - Server - Creodor-Rein http://pastebin.com/FtpaP2bV (Server:0, Rein:4, Creodor:4)
Test 5 - Creodor - Rein-Dakkan-Creodor http://pastebin.com/tQB0zqJY (Server:1209, Dakkan:604, Rein:605, Creodor:0)
Test 5 - Dakkan - Rein-Dakkan-Creodor http://pastebin.com/WsjHbFTN (Server:2, Dakkan:0, Rein:0, Creodor:1)
Test 5 - Rein - Rein-Dakkan-Creodor http://pastebin.com/1AV8Gnz7 (Server:1, Dakkan:1, Rein:0, Creodor:1)
Test 5 - Server - Rein-Dakkan-Creodor http://pastebin.com/CLGimLXU (Server:0, Dakkan:4, Rein:4, Creodor:4)
Test 6 - Creodor - Rein-Creodor http://pastebin.com/f8ZDFrCA (Server:604, Rein:604, Creodor:0)
Test 6 - Rein - Rein-Creodor http://pastebin.com/ys5A37m1 (Server:1, Rein:0, Creodor:1)
Test 6 - Server - Rein-Creodor http://pastebin.com/mT6UdtnC (Server:0, Rein:4, Creodor:4)
Also, Creodor has supplied screenshots of his IP forwarding setup, which are attached.
These are the users, their locations, IPs, and the number of times their IP showed up in all 20 files:
Creodor (Texas): 64.92.xxx.xxx - 33 hits 14 files
Rein (Virginia): 100.36.xxx.xxx - 2433 hits in 10 files
Dakkan (Pennsylvania): 69.249.xxx.xxx - 2434 hits in 9 files
Server (Nevada): 23.226.xxx.xxx - 4844 hits in 14 files
Below are the logs for our tests as well as the number of times each IP shows up in each file:
Test 1 - Creodor - Dakkan-Rein-Creodor http://pastebin.com/UdL7xuxF (Server:1210, Dakkan:605, Rein:605, Creodor:0)
Test 1 - Dakkan - Dakkan-Rein-Creodor http://pastebin.com/WmN133NS (Server:2, Dakkan:0, Rein:1, Creodor:1)
Test 1 - Rein - Dakkan-Rein-Creodor http://pastebin.com/ZqJCrjEw (Server:1, Dakkan:0, Rein:0, Creodor:1)
Test 1 - Server - Dakkan-Rein-Creodor http://pastebin.com/TnREWC8T (Server:0, Dakkan:4, Rein:4, Creodor:4)
Test 2 - Creodor - Dakkan-Creodor http://pastebin.com/ZVZWWqrb (Server:607, Dakkan:607, Creodor:0)
Test 2 - Dakkan - Dakkan-Creodor http://pastebin.com/W9ULyPGk (Server:3, Dakkan:0, Creodor:2)
Test 2 - Server - Dakkan-Creodor http://pastebin.com/1yciRvqW (Server:0, Dakkan:4, Creodor:4)
Test 3 - Creodor - Creodor-Dakkan http://pastebin.com/BseZa0C9 (Server:601, Dakkan:601, Creodor:0)
Test 3 - Dakkan - Creodor-Dakkan http://pastebin.com/m2Tr8Fz9 (Server:1, Dakkan:0, Creodor:1)
Test 3 - Server - Creodor-Dakkan http://pastebin.com/h2MhSdeK (Server:0, Dakkan:4, Creodor:4)
Test 4 - Creodor - Creodor-Rein http://pastebin.com/M1aF2DaR (Server:601, Rein:601, Creodor:0)
Test 4 - Rein - Creodor-Rein http://pastebin.com/cgSPbqxP (Server:1, Rein:0, Creodor:1)
Test 4 - Server - Creodor-Rein http://pastebin.com/FtpaP2bV (Server:0, Rein:4, Creodor:4)
Test 5 - Creodor - Rein-Dakkan-Creodor http://pastebin.com/tQB0zqJY (Server:1209, Dakkan:604, Rein:605, Creodor:0)
Test 5 - Dakkan - Rein-Dakkan-Creodor http://pastebin.com/WsjHbFTN (Server:2, Dakkan:0, Rein:0, Creodor:1)
Test 5 - Rein - Rein-Dakkan-Creodor http://pastebin.com/1AV8Gnz7 (Server:1, Dakkan:1, Rein:0, Creodor:1)
Test 5 - Server - Rein-Dakkan-Creodor http://pastebin.com/CLGimLXU (Server:0, Dakkan:4, Rein:4, Creodor:4)
Test 6 - Creodor - Rein-Creodor http://pastebin.com/f8ZDFrCA (Server:604, Rein:604, Creodor:0)
Test 6 - Rein - Rein-Creodor http://pastebin.com/ys5A37m1 (Server:1, Rein:0, Creodor:1)
Test 6 - Server - Rein-Creodor http://pastebin.com/mT6UdtnC (Server:0, Rein:4, Creodor:4)
Also, Creodor has supplied screenshots of his IP forwarding setup, which are attached.
- Attachments
-
- 2015-07-23_18-26-04.png (14.59 KiB) Viewed 17527 times
-
- 2015-07-23_18-24-35.png (18.98 KiB) Viewed 17527 times
Re: [0.12][cube] Headless server not working with more than one
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).
Re: [0.12][cube] Headless server not working with more than one
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!
Re: [0.12][cube] Headless server not working with more than one
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:
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.
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.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.
Re: [0.12][cube] Headless server not working with more than one
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:
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 :-)
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
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 :-)
Re: [0.12][cube] Headless server not working with more than one
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
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
Re: [0.12][cube] Headless server not working with more than one
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.
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.
Re: [0.12][cube] Headless server not working with more than one
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
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
Re: [0.12][cube] Headless server not working with more than one
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.
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.
Re: [0.12][cube] Headless server not working with more than one
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.
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.
Re: [0.12][cube] Headless server not working with more than one
Duplicate of this bug: 23301