[0.12.6] Deserialisation error on connect to headless MP

[Rein]

I have a dedicated headless server running Factorio. Myself and one other are both able to connect and play without issue, but when a specific one of our other friends tries to connect (no matter how many people are on the server) he is unable. I don't know the error he gets offhand, but I know from looking at the terminal window on the server that it repeatedly throws the following error whenever he tries to connect:

Info Router.cpp:304: Deserialisation error (Couldn't read from input file. File could be corrupted.) when parsing message from 74.47.xxx.xxx:34197

Any idea what could be causing this?

[Rseding91]

Without logs from the person who can't connect there's not much that can be done.

[Rein]

roger that, I'll try and get them tonight.

[Oxyd]

Does the person unable to connect have the same version of Factorio as you guys have?

[Rein]

Does the person unable to connect have the same version of Factorio as you guys have?

Yes, same version. Just had another person connect successfully, so that one is the only outlier. The only major difference between him and the others is that he's in the middle of the woods on some dial-up level of internet.

[kovarex]

Does the person unable to connect have the same version of Factorio as you guys have?

Yes, same version. Just had another person connect successfully, so that one is the only outlier. The only major difference between him and the others is that he's in the middle of the woods on some dial-up level of internet.

Unless we get a log and desync report files I have no idea what to do with that. I'm moving it to pending until we get more info.

[Rivaryn]

I am also having this error with 12.7. Where can I find the error logs for the client side x64 windows version? They do not seem to be in my Factorio directory in Program Files, even though I used the zip file and by default it appears everything should be contained there. If it's a permissions issue, I did run the program as admin since it wouldn't run otherwise, even though UAC is supposedly off.

The server spits back the following:
Info Router.cpp:304: Deserialisation error (Couldn't read from input file. File could be corrupted.) when parsing message from [IP ADDRESS REMOVED]

[kovarex]

I am also having this error with 12.7. Where can I find the error logs for the client side x64 windows version? They do not seem to be in my Factorio directory in Program Files, even though I used the zip file and by default it appears everything should be contained there. If it's a permissions issue, I did run the program as admin since it wouldn't run otherwise, even though UAC is supposedly off.

The server spits back the following:
Info Router.cpp:304: Deserialisation error (Couldn't read from input file. File could be corrupted.) when parsing message from [IP ADDRESS REMOVED]

If you used the zip file, the logs should be in the root of the folder (as long as you didn't bring your old config files, as the location is actually specified there).

[Rivaryn]

Hmm, I seem to be unable to recreate the issue doing the same steps as before. When I ran it the first time after unzipping it, it had the little UAC shield on the icon, and failed to start at all. I then went to the program's properties and changed settings for all users to run as administrator. This is when I had the issue in this thread.

Now, it no longer has that UAC shield icon, and upon starting up I see the new background and I can log into the same server without an issue. I am not sure what changed - I'll see what I can do to recreate the issue. My guess is since it failed to write logs when also failing to connect, it had some odd permissions that let it run the game but not write to the directories it needed.

[Oxyd]

Throwing that kind of error because of file permissions would be certainly surprising. That doesn't mean it's impossible, of course. What that error is saying is that the server received a malformed packet from the client. (The error message is the same for malformed packets and for malformed files, which is why it talks about files. This is just to spice things up a bit by making things confusing.)

My initial thought here was that some firewall or some piece of network equipment changed the packet somehow and thus corrupted it. Would certainly explain why one person could connect just fine whilst the other would always get that error.

But I suppose an alternative scenario is also a possibility: The client attempts to read a file, fails but doesn't notice, puts the empty result of the unsuccessful read into the packet and the server interprets the packet as malformed. I'll have to explore this possibility tomorrow.