Pass user verification on the first connection attempt to public servers

[Hornwitser]

TL;DR

Pass user verification on the first connection attempt to public servers.

What ?

When connecting to a server in the public servers list the client first tries to connect without the credentials that prove it's a verified user. But public servers have to have user verification enabled to be listed, so this connection attempt always fails with the user verification missing status. Since we expect all the servers in the public list to require user verification it makes sense to always send the credentials when connecting to servers in the public server list.

Why ?

A friend of mine tried to connect to my game behind a NAT and it failed. I did a packet capture and it showed the NAT punching worked and two way communication was established, but the connection attempt failed because it didn't contain the user credentials. Now normally the client immediately does another connection attempt with credentials, but that attempt didn't reach through the NAT for some reason. I'm not sure why this was the case, multiple attempts at connecting all did this same thing, but I'm theorizing that if the first connection attempt had had the credentials in it it would have worked.

[ssilk]

This points in my eyes to a networking problem. It should not be workarounded (sending credentials without real need, security!), instead that problem should be fixed.

Please ask in the technical gameplay board for help to find the reason for this and eventually create a bug ticket.

[Hornwitser]

It should not be workarounded (sending credentials without real need, security!), instead that problem should be fixed.

User verification is a requirement for a server to be listed on the public server list. Connecting to public servers with user verification enabled requires the client sending the user verification credentials to the server. It is not a workaround to send these credentials on the first attempt, it removes 2 unnecessary round trips during the connecting process since we know connecting without the credentials (which the client tries to do first) will always fail.

[ptx0]

(sending credentials without real need, security!)

it's a token, not a username/password.

[ssilk]

Ok, I have no clue about multiplayer

If that is really like so, it sounds to me like a bug, even if Factorio behaves as intended, but useless network traffic is a bug.

Moved to bug reports.

[NotRexButCaesar]

it sounds to me like a bug, even if Factorio behaves as intended, but useless network traffic is a bug.

Is the definition of a bug not "an unintended behavior?" If the useless traffic reduces complexity, maybe the devs do not want to change it.

[ptx0]

the bug is that the NAT punching doesn't occur on the 2nd connection attempt

there's a implementation defect that it doesn't simply send credentials, requiring unnecessary round-trip.

please, just don't comment on something if you don't understand it, Rex.

[Rseding91]

Thanks for the report. As far as I can tell this is working as intended. The first connection attempt to the server prompts the server to send a hash back to the client. The client is then meant to send that hash + its local token to the auth server for verification. Once the auth server verifies the server hash and the token a key is sent back to the client which is then sent to the server. The server gets that key and uses it to verify the client has successfully authenticated with the auth server.

NAT punching not working is the main issue as far as I can see here. I know in the past there was an issue with NAT punching not working but it was fixed in version 1.1.31 that went out April 13th 2021 before this was posted. I don't know why the second connection attempt would fail within that tiny time window; the NAT punching logic is meant to keep the connection open for a much longer period than the time it would take for the second message to come back to the server. And in my testing it does just that; it NAT punches, the above process happens, and it connects.

It's possible something else is going wrong here but from what I am able to test so far it seems to work.

[Hornwitser]

I see, I misunderstood how the authentication worked, I thought it was related to the server ID.

Anyway what I noticed looking at the packet trace was that the second connection attempt was done with a new port on the client. So the previous NAT punch with established communication wouldn't be valid any more, the NAT would have to be punched again for communication to be established.

Well, that's a bit of an over simplification. There's a dozen ways to implement NAT and there's no golden standard for how its done. For some of the ways it can be implemented the NAT would have to be punched again for the new port on the client, for others it doesn't have to be punched again. But it's also possible to implement NAT in a way where a second port can't be punched open until the first port that was punched open expires in NAT table of the router.

I will have to be honest and say I don't know which kind of NAT is the most common one, or what kind of failure rate punching two ports will have compared to punching one port. Ideally the client would after successfully punching the NAT and establishing two way communication with the server stick to the same port.