[0.13+] Games cannot be joined by IP when user verification is required

Bugs that we were not able to reproduce, and/or are waiting for more detailed info.
Post Reply
luc
Fast Inserter
Fast Inserter
Posts: 218
Joined: Sun Jul 17, 2016 9:53 pm
Contact:

[0.13+] Games cannot be joined by IP when user verification is required

Post by luc »

Steps to reproduce:

1. Host a Factorio server or find an existing one. Note its IP address and port.

2. Launch Factorio with `--mp-connect IP:port`

Expected result: Factorio will authenticate itself through the auth system and connects to the server.

Actual result: Factorio refuses to connect.

It seems the missing thing is the game_secret, as that is the only thing the game list provides that the command line cannot. As a workaround that can be implemented in 5 minutes (yeah it's more, I know), the game could accept an argument with the game secret.

Oxyd
Former Staff
Former Staff
Posts: 1428
Joined: Thu May 07, 2015 8:42 am
Contact:

Re: [0.13+] Games cannot be joined by IP when user verification is required

Post by Oxyd »

Which version of Factorio are you using? Can you reproduce this in 0.14.12? Post the log please.

luc
Fast Inserter
Fast Inserter
Posts: 218
Joined: Sun Jul 17, 2016 9:53 pm
Contact:

Re: [0.13+] Games cannot be joined by IP when user verification is required

Post by luc »

I tried yesterday with 0.13.20 (3 servers), 0.14.5 (1 server) and 0.14.12 (2 servers).

Only from 0.14.10 onwards does the require_user_verification flag work in the API data, so I cannot tell whether older servers have it turned on. However, for 0.14.12 there was only one server that had it disabled, so the vast majority has it enabled. This corresponds with my experience of 0.13.20 where I could not connect to any server using --mp-connect. They all say "could not connect": the game gets no response at all (this can be verified using Wireshark or another network monitor). Connecting from the server browser works just fine, that sends a completely different UDP packet (again, can be seen in Wireshark).

Trying to connect to that 0.14.12 server (that had user verification disabled) with --mp-connect worked: it returned an error "mod mismatch" instead of "could not connect".

The log is not relevant. If you mention this to whomever wrote the user verification system, they will know what I'm talking about.

kovarex
Factorio Staff
Factorio Staff
Posts: 8078
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: [0.13+] Games cannot be joined by IP when user verification is required

Post by kovarex »

luc wrote:Trying to connect to that 0.14.12 server (that had user verification disabled) with --mp-connect worked: it returned an error "mod mismatch" instead of "could not connect".
So the bug is fixed?

luc
Fast Inserter
Fast Inserter
Posts: 218
Joined: Sun Jul 17, 2016 9:53 pm
Contact:

Re: [0.13+] Games cannot be joined by IP when user verification is required

Post by luc »

No. I'm not sure I'm explaining it clearly.

The problem is that players cannot connect via the command line to servers that have user verification turned on. The server wants to know that I am really "luc" and requires verification. This is a feature built in since 0.13 and is turned on for almost every server online. It breaks --mp-connect because the client does not attempt to authenticate with the server, but instead sends a normal connection packet and, since the server doesn't respond to that, gives up trying to connect at all.

In the API data, there is a "game_secret" field which I assume is necessary for this authentication process. It cannot be supplied by the command line, and that is probably why connecting fails. I don't know whether this solves it because I don't know how the verification system works, but it seems that adding a command line argument called --game-secret would allow people to work around the problem.

Better yet, the client could detect that user verification is needed, then query the matching server to obtain any necessary information, and connect normally. But that is more work than just adding a command line argument, so as a simple workaround I propose the command line argument.

The reason I could connect to that 0.14.12 server is because it has user verification turned off. The bug I'm reporting is that you cannot connect to 0.13+ servers anymore because practically all of them have this verification turned on, and with verification turned on it cannot connect by IP:port.

luc
Fast Inserter
Fast Inserter
Posts: 218
Joined: Sun Jul 17, 2016 9:53 pm
Contact:

Re: [0.13+] Games cannot be joined by IP when user verification is required

Post by luc »

I tested some more with a local server. Even when connecting over LAN, the game can do user verification via the auth system. This is visible in the logs:

Code: Select all

 252.343 Joining game 192.168.56.1:34197
 252.344 Info PosixUDPSocket.cpp:50: Opening socket at port 0
 252.344 Info ClientMultiplayerManager.cpp:530: MapTick(-1) changing state from(Ready) to(Connecting)
 252.409 Connection refused
 252.415 Info ClientMultiplayerManager.cpp:177: Quitting multiplayer connection.
 252.415 Info ClientMultiplayerManager.cpp:530: MapTick(-1) changing state from(Connecting) to(Disconnected)
 252.444 Info HttpSharedState.cpp:44: Downloading https://auth.factorio.com/generate-user-server-key
 252.947 Info HttpSharedState.cpp:108: Status code: 200
 252.948 Info AuthServerConnector.cpp:132: Received key(Tm90IGEgcmVhbCBrZXk6KQ==) for username(luc) from auth server.
This authentication process does not happen when connecting by --mp-connect, causing the game to fail to connect. That is the bug.

Oxyd
Former Staff
Former Staff
Posts: 1428
Joined: Thu May 07, 2015 8:42 am
Contact:

Re: [0.13+] Games cannot be joined by IP when user verification is required

Post by Oxyd »

You did not answer my questions. Can you reproduce it in 0.14.12? And please post the full log, not a random excerpt.

luc
Fast Inserter
Fast Inserter
Posts: 218
Joined: Sun Jul 17, 2016 9:53 pm
Contact:

Re: [0.13+] Games cannot be joined by IP when user verification is required

Post by luc »

Okay I am not 100% certain anymore it's the game_secret that's the problem nor that the fault lays in the verification at all. Anyway, I tested some more, here are logs:

Connecting via --mp-connect IP:port

Code: Select all

   0.000 2016-10-08 11:25:47; Factorio 0.14.13 (build 25020, linux64, alpha)
   0.424 Operating system: Linux (Debian testing)
   0.425 Program arguments: "./bin/x64/factorio" "--mp-connect" "5.175.3.196:34197" 
   0.425 Read data path: /home/$user/Downloads/factorio-0.14.13/data
   0.425 Write data path: /home/$user/Downloads/factorio-0.14.13
   0.425 Binaries path: /home/$user/Downloads/factorio-0.14.13/bin
   0.448 System info: [CPU:       Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 8 cores, RAM: 7873MB]
   0.463 Display options: [FullScreen: true] [VSync: false] [UIScale: 100%] [MultiSampling: OFF] [Screen: 255]
   0.652 Available display adapters: 1
   0.652  [0]: resolution 1920x1080px at [0,0]
   0.652 Create display on adapter 0. Size 1280x720 at position [310, 162].
   0.954 Initialised OpenGL:[0] Mesa DRI Intel(R) Ivybridge Mobile ; driver: 3.0 Mesa 12.0.3
   0.991 Graphics options: [Graphics quality: normal] [Video memory usage: low] [Light scale: 25%] [DXT: false]
   1.156 Loading mod core 0.0.0 (data.lua)
   1.181 Loading mod base 0.14.13 (data.lua)
   1.441 Checksum for core: 1620335853
   1.441 Checksum for mod base: 286270215
   2.278 Info PlayerData.cpp:55: Local player-data.json available, timestamp 1475878657
   2.278 Info PlayerData.cpp:62: Cloud player-data.json unavailable
   2.535 Initial atlas bitmap size is 8192
   2.535 Created atlas bitmap 6229x96
   2.536 Created atlas bitmap 4096x968
   2.536 Created atlas bitmap 4096x3644
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
  20.474 Sprites loaded
  20.474 Convert atlas 4096x968 to: trilinear-filtering 
  20.513 Convert atlas 4096x3644 to: mipmap 
  20.638 Loading sounds...
  22.232 Custom inputs active: 0
  22.232 Info Updater.cpp:749: Downloading https://updater.factorio.com/get-available-versions?username=luc&token=<private>&apiVersion=2
  23.087 0 packages available to download (experimental updates enabled).
  23.154 Factorio initialised
  23.154 Joining game 5.175.3.196:34197
  23.154 Info PosixUDPSocket.cpp:50: Opening socket at port 0
  23.155 Info ClientMultiplayerManager.cpp:538: MapTick(-1) changing state from(Ready) to(Connecting)
  25.716 Error ClientMultiplayerManager.cpp:90: MultiplayerManager failed: multiplayer.not-received-connection-accept-reply
  25.717 Info ClientMultiplayerManager.cpp:538: MapTick(-1) changing state from(Connecting) to(InitializationFailed)
  30.267 Info ClientMultiplayerManager.cpp:177: Quitting multiplayer connection.
  30.267 Info ClientMultiplayerManager.cpp:538: MapTick(-1) changing state from(InitializationFailed) to(Disconnected)
  30.268 Info PosixUDPSocket.cpp:154: Socket closed
  33.321 Goodbye
Result: "unable to connect" error. This is what I meant earlier, it seemed to happen only for games with user verification. And as you can see, nowhere does it prompt the auth server for a token.

Connecting via the in-game browser:

Code: Select all

   0.000 2016-10-08 11:26:23; Factorio 0.14.13 (build 25020, linux64, alpha)
   0.231 Operating system: Linux (Debian testing)
   0.231 Program arguments: "./bin/x64/factorio" 
   0.231 Read data path: /home/luc/Downloads/factorio-0.14.13/data
   0.231 Write data path: /home/luc/Downloads/factorio-0.14.13
   0.231 Binaries path: /home/luc/Downloads/factorio-0.14.13/bin
   0.240 System info: [CPU:       Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 8 cores, RAM: 7873MB]
   0.242 Display options: [FullScreen: true] [VSync: false] [UIScale: 100%] [MultiSampling: OFF] [Screen: 255]
   0.416 Available display adapters: 1
   0.416  [0]: resolution 1920x1080px at [0,0]
   0.416 Create display on adapter 0. Size 1280x720 at position [310, 162].
   0.694 Initialised OpenGL:[0] Mesa DRI Intel(R) Ivybridge Mobile ; driver: 3.0 Mesa 12.0.3
   0.724 Graphics options: [Graphics quality: normal] [Video memory usage: low] [Light scale: 25%] [DXT: false]
   0.794 Loading mod core 0.0.0 (data.lua)
   0.808 Loading mod base 0.14.13 (data.lua)
   0.922 Checksum for core: 1620335853
   0.922 Checksum for mod base: 286270215
   1.265 Info PlayerData.cpp:55: Local player-data.json available, timestamp 1475915178
   1.265 Info PlayerData.cpp:62: Cloud player-data.json unavailable
   1.418 Initial atlas bitmap size is 8192
   1.421 Created atlas bitmap 6229x96
   1.421 Created atlas bitmap 4096x968
   1.421 Created atlas bitmap 4096x3644
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
  16.445 Sprites loaded
  16.445 Convert atlas 4096x968 to: trilinear-filtering 
  16.479 Convert atlas 4096x3644 to: mipmap 
  16.599 Loading sounds...
  18.056 Custom inputs active: 0
  18.056 Info Updater.cpp:749: Downloading https://updater.factorio.com/get-available-versions?username=luc&token=<private>&apiVersion=2
  18.882 0 packages available to download (experimental updates enabled).
  18.959 Factorio initialised
  29.008 Info PosixUDPSocket.cpp:50: Opening socket at port 0
  35.642 Info PosixUDPSocket.cpp:154: Socket closed
  35.644 Joining game 5.175.3.196:34197
  35.644 Info PosixUDPSocket.cpp:50: Opening socket at port 0
  35.644 Info ClientMultiplayerManager.cpp:538: MapTick(-1) changing state from(Ready) to(Connecting)
  35.698 Warning ClientRouter.cpp:115: Received NatPunch from 5.175.3.196:34197 as a client
  35.959 Warning ClientRouter.cpp:115: Received NatPunch from 5.175.3.196:34197 as a client
  36.009 Connection refused
  36.010 Info ClientMultiplayerManager.cpp:177: Quitting multiplayer connection.
  36.010 Info ClientMultiplayerManager.cpp:538: MapTick(-1) changing state from(Connecting) to(Disconnected)
  36.012 Info PosixUDPSocket.cpp:154: Socket closed
  42.546 Goodbye
Here it does something with nat punching and tells me mod mismatch (which is correct), but at least I get a response. So perhaps NAT is the issue instead of user verif?

This server has no user verif and connects fine. Or perhaps it's not behind NAT, who knows?

Code: Select all

   0.001 2016-10-08 11:32:22; Factorio 0.14.12 (build 24932, linux64, alpha)
   0.340 Operating system: Linux (Debian testing)
   0.342 Program arguments: "./bin/x64/factorio" "--mp-connect" "94.23.199.191:34197" 
   0.342 Read data path: /home/$user/Downloads/factorio-0.14.12/data
   0.342 Write data path: /home/$user/Downloads/factorio-0.14.12
   0.342 Binaries path: /home/$user/Downloads/factorio-0.14.12/bin
   0.364 System info: [CPU:       Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 8 cores, RAM: 7873MB]
   0.394 Display options: [FullScreen: true] [VSync: false] [UIScale: 100%] [MultiSampling: OFF] [Screen: 255]
   0.555 Available display adapters: 1
   0.555  [0]: resolution 1920x1080px at [0,0]
   0.555 Create display on adapter 0. Size 1280x720 at position [310, 162].
   0.940 Initialised OpenGL:[0] Mesa DRI Intel(R) Ivybridge Mobile ; driver: 3.0 Mesa 12.0.3
   1.063 Graphics options: [Graphics quality: normal] [Video memory usage: low] [Light scale: 25%] [DXT: false]
   1.257 Loading mod core 0.0.0 (data.lua)
   1.269 Loading mod base 0.14.12 (data.lua)
   1.594 Checksum for core: 1620335853
   1.594 Checksum for mod base: 2833886813
   2.876 Info PlayerData.cpp:55: Local player-data.json available, timestamp 1475695697
   2.876 Info PlayerData.cpp:62: Cloud player-data.json unavailable
   3.124 Initial atlas bitmap size is 8192
   3.125 Created atlas bitmap 6229x96
   3.125 Created atlas bitmap 4096x968
   3.125 Created atlas bitmap 4096x3644
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
  19.035 Sprites loaded
  19.035 Convert atlas 4096x968 to: trilinear-filtering 
  19.079 Convert atlas 4096x3644 to: mipmap 
  19.192 Loading sounds...
  20.775 Custom inputs active: 0
  20.776 Info Updater.cpp:749: Downloading https://updater.factorio.com/get-available-versions?username=luc&token=<private>&apiVersion=2
  21.604 1 packages available to download (experimental updates enabled).
  21.663 Factorio initialised
  21.665 Joining game 94.23.199.191:34197
  21.665 Info PosixUDPSocket.cpp:50: Opening socket at port 0
  21.665 Info ClientMultiplayerManager.cpp:530: MapTick(-1) changing state from(Ready) to(Connecting)
  21.752 Info ClientSynchronizer.cpp:33: Initialized Synchronizer local peer(1) latency(32).
  21.753 Info ClientMultiplayerManager.cpp:530: MapTick(-1) changing state from(Connecting) to(ConnectedWaitingForMap)
  21.753 Info ClientRouter.cpp:217: ConnectionAccepted
  25.038 Info ClientMultiplayerManager.cpp:660: Received mapReadyForDownload
  25.038 Downloading file /home/$user/Downloads/factorio-0.14.12/temp/mp-download.zip (25490227 B, 50677 blocks)
  25.040 Info ClientMultiplayerManager.cpp:530: MapTick(-1) changing state from(ConnectedWaitingForMap) to(ConnectedDownloadingMap)
  25.857 Info ClientMultiplayerManager.cpp:129: Disconnecting multiplayer connection.
  25.857 Info ClientMultiplayerManager.cpp:530: MapTick(-1) changing state from(ConnectedDownloadingMap) to(DisconnectScheduled)
  25.888 Info ClientMultiplayerManager.cpp:530: MapTick(-1) changing state from(DisconnectScheduled) to(WaitingForDisconnectConfirmation)
  26.038 Info ClientMultiplayerManager.cpp:530: MapTick(-1) changing state from(WaitingForDisconnectConfirmation) to(Disconnected)
  26.038 Info ClientMultiplayerManager.cpp:763: Disconnect notification for peer (8)
  26.038 Info ClientSynchronizer.cpp:191: nextHeartbeatSequenceNumber(1118228207) cannot process synchronizer action(MapDownloadingProgressUpdate)
  26.038 Info PosixUDPSocket.cpp:154: Socket closed
  27.348 Goodbye
Note that both servers have been running since October 3rd (I'm testing with the same one as I originally tested with) so you can probably do your own tests with these same servers.
Oxyd wrote:You did not answer my questions. Can you reproduce it in 0.14.12? And please post the full log, not a random excerpt.
From my tests it seemed as if it was a clear-cut case, where the game neglected to obtain a token if you used the command line instead of the server browser. I thought that whoever made the verification system would recognize "oh yeah, that's true, let me fix that" and that logs were not needed. Looks like my tests were inconclusive! Sorry about that :)

To answer your question directly: yes, it still happens in the latest experimental version as you can see in the first log.

Post Reply

Return to “Pending”