search

TrueOsiris / docker-vrising

Container for V-Rising dedicated server
229 stars 60 forks source link

'Continue' button non-functional #71

Open FunkFrog opened 3 months ago

FunkFrog commented 3 months ago

Hey! I got this docker image set up a few days ago and it works flawlessly, with the exception that the 'continue' button on the main menu does not work for reconnecting to the server for any player, so unless you connect via "Load Game" or the server list, it just times out.

Here's my docker-compose.yml:

services:
  vrising:
    image: trueosiris/vrising
    environment:
      - TZ=America/Chicago
      - SERVERNAME=HIV Vampires
      - GAMEPORT=27015
      - QUERYPORT=27016
    volumes:
      - type: bind
        source: /home/vrising/server
        target: /mnt/vrising/server
        bind:
          create_host_path: true
      - type: bind
        source: /home/vrising/persistentdata
        target: /mnt/vrising/persistentdata
        bind:
          create_host_path: true
    ports:
      - '9876:9876/udp'
      - '9877:9877/udp'
      - '27015:27015/udp'
      - '27016:27016/udp'
    restart: unless-stopped
    network_mode: bridge

And my ServerHostSettings.json:

{
  "Name": "V Rising Server",
  "Description": "",
  "Port": 27015,
  "QueryPort": 27016,
  "MaxConnectedUsers": 45,
  "MaxConnectedAdmins": 4,
  "ServerFps": 60,
  "LowerFPSWhenEmpty": true,
  "LowerFPSWhenEmptyValue": 10,
  "SaveName": "world1",
  "Password": "",
  "Secure": true,
  "ListOnSteam": true,
  "ListOnEOS": true,
  "AutoSaveCount": 20,
  "AutoSaveInterval": 120,
  "CompressSaveFiles": true,
  "GameSettingsPreset": "",
  "GameDifficultyPreset": "",
  "AdminOnlyDebugEvents": true,
  "DisableDebugEvents": false,
  "API": {
    "Enabled": false
  },
  "Rcon": {
    "Enabled": false,
    "Port": 25575,
    "Password": ""
  }
}

Any leads on a solution would be greatly appreciated. Thank you so much!

Chudz commented 3 months ago

I don't think MaxConnectedUsers higher than 40 is supported so maybe that's it? Try changing it to 40.

DervilRus commented 3 months ago

I confirm. For some reason I can’t log in into the server via CONTINUE. At the same time, I have another server on Windows, everything is ok with it.

James-Whitney commented 3 months ago

I'm also seeing this issue,

I don't think MaxConnectedUsers higher than 40 is supported so maybe that's it? Try changing it to 40.

My config has 40 set, so I think we can rule this out.

If someone has a known working continue button and could post their ServerHostSettings.json and/or ServerGameSettings.json we might be able see what setting is breaking this.

EDIT: for anyone coming here thinking their server is broken, direct connecting works every time even when continue doesn't.

Barborica-Alexandru commented 3 months ago

Yes the problem is that most of the time but not always, the steamipv4 will be reported as 0.0.0.0 and that is why continue does not work. 10% of the time the address will be reported correctly (the external IP address of the server) and that is when continue will work. I have no idea why this happens.

James-Whitney commented 3 months ago

i can confirm this is the issue, you can edit your continue settings which was located here for me: "C:\Program Files (x86)\Steam\userdata\MY_STEAM_ID\1604030\remote\v3\ServerHistory.json" my server's IP was listed as 0.0.0.0, setting it to the correct IP allowed me to connect once via continue. Unfortunately the game immediately sets it back to 0.0.0.0 as soon as you connect again.

1qw223 commented 3 months ago

i can confirm this is the issue, you can edit your continue settings which was located here for me: "C:\Program Files (x86)\Steam\userdata\MY_STEAM_ID\1604030\remote\v3\ServerHistory.json" my server's IP was listed as 0.0.0.0, setting it to the correct IP allowed me to connect once via continue. Unfortunately the game immediately sets it back to 0.0.0.0 as soon as you connect again.

In fact, the root cause of the problem is very simple, that is, Steam cannot obtain server data. It is wrong to only focus on ServerHostSettings.json, because I have discovered through my own experience and research that when you check the logs of a dedicated server folder, there will be a connection_log_time.txt file in it. Since this project lacks openssl iproute2 ca-certificates, it is unable to connect to Steam's CM verification server, so my solution is to add it to the Dockerfile Added apt-get install -y openssl iproute2 ca-certificates &&, then open it again and check the connection_log_time.txt file. As long as RecvMsgClientLogOnResponse appears in it, it means that the Steam server has received your data. Check it now and you will find it. Your IP can be displayed correctly in ServerHistory.json. Since my English is not very good, I use a translator to communicate. If you have any questions, please reply to me.

Barborica-Alexandru commented 3 months ago

i can confirm this is the issue, you can edit your continue settings which was located here for me: "C:\Program Files (x86)\Steam\userdata\MY_STEAM_ID\1604030\remote\v3\ServerHistory.json" my server's IP was listed as 0.0.0.0, setting it to the correct IP allowed me to connect once via continue. Unfortunately the game immediately sets it back to 0.0.0.0 as soon as you connect again.

In fact, the root cause of the problem is very simple, that is, Steam cannot obtain server data. It is wrong to only focus on ServerHostSettings.json, because I have discovered through my own experience and research that when you check the logs of a dedicated server folder, there will be a connection_log_time.txt file in it. Since this project lacks openssl iproute2 ca-certificates, it is unable to connect to Steam's CM verification server, so my solution is to add it to the Dockerfile Added apt-get install -y openssl iproute2 ca-certificates &&, then open it again and check the connection_log_time.txt file. As long as RecvMsgClientLogOnResponse appears in it, it means that the Steam server has received your data. Check it now and you will find it. Your IP can be displayed correctly in ServerHistory.json. Since my English is not very good, I use a translator to communicate. If you have any questions, please reply to me.

Yes this seems to solve the problem.

James-Whitney commented 3 months ago

I've tried a build with RUN apt install -y openssl iproute2 ca-certificates added without success, if you have a working Dockerfile or built image I'd be happy to test it out to see if there is a separate issue with my setup.

1qw223 commented 3 months ago

I've tried a build with RUN apt install -y openssl iproute2 ca-certificates added without success, if you have a working Dockerfile or built image I'd be happy to test it out to see if there is a separate issue with my setup.

Well, I also noticed this issue because it is sporadic, with a probability of about 50%. I don't know if you have a deeper understanding of Steam's CM server. When I use my Wine to start the server, there is a 50% probability that I won't be able to connect to the CM server connected through WebSocket. If I connect to the CM server through Udp, the IP will be displayed normally. This will be displayed in the specific connection'log_time.txt. If OpenSSL is not installed, I won't be able to connect to the CM server at all, and the IP will not be displayed. However, through my testing, both the stable and latest versions of Wine cannot connect to the CM server properly. Steam's CM server (Websocket), but I tested it on a physical machine and found no problem connecting to the CM server, So I feel that the SSL connection may not be able to connect due to Wine or other reasons. If it is a UDP connection, then the display is normal and the continue button can be used

James-Whitney commented 3 months ago

I've tried a build with RUN apt install -y openssl iproute2 ca-certificates added without success, if you have a working Dockerfile or built image I'd be happy to test it out to see if there is a separate issue with my setup.

Well, I also noticed this issue because it is sporadic, with a probability of about 50%. I don't know if you have a deeper understanding of Steam's CM server. When I use my Wine to start the server, there is a 50% probability that I won't be able to connect to the CM server connected through WebSocket. If I connect to the CM server through Udp, the IP will be displayed normally. This will be displayed in the specific connection'log_time.txt. If OpenSSL is not installed, I won't be able to connect to the CM server at all, and the IP will not be displayed. However, through my testing, both the stable and latest versions of Wine cannot connect to the CM server properly. Steam's CM server (Websocket), but I tested it on a physical machine and found no problem connecting to the CM server, So I feel that the SSL connection may not be able to connect due to Wine or other reasons. If it is a UDP connection, then the display is normal and the continue button can be used

Looked into wine ssl issues and found a recommendation to install libldap, ive got an image with openssl iproute2 ca-certificates libldap-2.5-0 installed and all of my connection_log_9878.txt errors are gone and Continue is working.

1qw223 commented 3 months ago

I've tried a build with RUN apt install -y openssl iproute2 ca-certificates added without success, if you have a working Dockerfile or built image I'd be happy to test it out to see if there is a separate issue with my setup.

Well, I also noticed this issue because it is sporadic, with a probability of about 50%. I don't know if you have a deeper understanding of Steam's CM server. When I use my Wine to start the server, there is a 50% probability that I won't be able to connect to the CM server connected through WebSocket. If I connect to the CM server through Udp, the IP will be displayed normally. This will be displayed in the specific connection'log_time.txt. If OpenSSL is not installed, I won't be able to connect to the CM server at all, and the IP will not be displayed. However, through my testing, both the stable and latest versions of Wine cannot connect to the CM server properly. Steam's CM server (Websocket), but I tested it on a physical machine and found no problem connecting to the CM server, So I feel that the SSL connection may not be able to connect due to Wine or other reasons. If it is a UDP connection, then the display is normal and the continue button can be used

Looked into wine ssl issues and found a recommendation to install libldap, ive got an image with openssl iproute2 ca-certificates libldap-2.5-0 installed and all of my connection_log_9878.txt errors are gone and Continue is working.

I'm very happy to cooperate to solve this problem. I will try this method tomorrow. I have checked a lot of information about wine's SSL failure and can't find it. Your appearance has helped me a lot.

James-Whitney commented 3 months ago

Actually, I don't think it fixed the issue, i just got lucky when the server started up correctly several times in a row. Other than the UDP default, another difference between successful launches I've noticed is in the ConnectionCompleted(), the local addresses are different, which might be the result of a NAT issue.

broken: [2024-05-23 00:05:57] [Connecting, 4, 3] [A:1:0:0] ConnectionCompleted() (162.254.195.71:27019, WebSocket) local address (172.16.0.53:35549) working: [2024-05-23 00:13:03] [Connecting, 4, 2] [A:1:0:0] ConnectionCompleted() (162.254.195.71:27018, UDP) local address (0.0.0.0:46963)

FunkFrog commented 3 months ago

Actually, I don't think it fixed the issue, i just got lucky when the server started up correctly several times in a row. Other than the UDP default, another difference between successful launches I've noticed is in the ConnectionCompleted(), the local addresses are different, which might be the result of a NAT issue.

broken: [2024-05-23 00:05:57] [Connecting, 4, 3] [A:1:0:0] ConnectionCompleted() (162.254.195.71:27019, WebSocket) local address (172.16.0.53:35549) working: [2024-05-23 00:13:03] [Connecting, 4, 2] [A:1:0:0] ConnectionCompleted() (162.254.195.71:27018, UDP) local address (0.0.0.0:46963)

I can confirm that this doesn't work all the time, in two restarts I haven't been able to get it to function correctly. Both connections have completed the connection via WebSocket and not UDP.

I tried this with RUN apt install -y openssl iproute2 ca-certificates libldap-2.5-0, the end of my connection_log_27015.txt is as follows:

[2024-05-23 00:09:01] [Connecting, 4, 3] [A:1:0:0] ConnectionCompleted() (155.133.253.50:27023, WebSocket) local address (<my public IP (server is in DMZ)>)
[2024-05-23 00:09:01] [Connecting, 4, 3] [A:1:0:0] Client thinks it can connect via: UDP - yes, TCP - yes, WebSocket:443 - yes, WebSocket:Non443 - yes
[2024-05-23 00:09:01] [Connected, 4, 3] [A:1:0:0] Logging on [A:1:0:0]
[2024-05-23 00:09:01] [Logging On, 4, 3] [A:1:0:0] RecvMsgClientLogOnResponse() : [A:1:1381374999:29445] 'OK'

Could there be some way to force the UDP connection to Steam?

1qw223 commented 3 months ago

Actually, I don't think it fixed the issue, i just got lucky when the server started up correctly several times in a row. Other than the UDP default, another difference between successful launches I've noticed is in the ConnectionCompleted(), the local addresses are different, which might be the result of a NAT issue. broken: [2024-05-23 00:05:57] [Connecting, 4, 3] [A:1:0:0] ConnectionCompleted() (162.254.195.71:27019, WebSocket) local address (172.16.0.53:35549) working: [2024-05-23 00:13:03] [Connecting, 4, 2] [A:1:0:0] ConnectionCompleted() (162.254.195.71:27018, UDP) local address (0.0.0.0:46963)

I can confirm that this doesn't work all the time, in two restarts I haven't been able to get it to function correctly. Both connections have completed the connection via WebSocket and not UDP.

I tried this with RUN apt install -y openssl iproute2 ca-certificates libldap-2.5-0, the end of my connection_log_27015.txt is as follows:

[2024-05-23 00:09:01] [Connecting, 4, 3] [A:1:0:0] ConnectionCompleted() (155.133.253.50:27023, WebSocket) local address (<my public IP (server is in DMZ)>)
[2024-05-23 00:09:01] [Connecting, 4, 3] [A:1:0:0] Client thinks it can connect via: UDP - yes, TCP - yes, WebSocket:443 - yes, WebSocket:Non443 - yes
[2024-05-23 00:09:01] [Connected, 4, 3] [A:1:0:0] Logging on [A:1:0:0]
[2024-05-23 00:09:01] [Logging On, 4, 3] [A:1:0:0] RecvMsgClientLogOnResponse() : [A:1:1381374999:29445] 'OK'

Could there be some way to force the UDP connection to Steam?

I can provide you with an idea. If you have an idea to get it, when the game is started, the game will send a request to SteamWebApi to obtain a list of all CM servers. The address is this https://api.steampowered.com/ISteamDirectory/GetCMListForConnect /v1/, and then you will see that most of the types are websocket instead of netfilter, so as long as you write an intermediate layer that can filter all types of websocket and only keep netfilter, then this problem can be solved. What can I do? I don’t have any ideas on how to implement it

1qw223 commented 3 months ago

Actually, I don't think it fixed the issue, i just got lucky when the server started up correctly several times in a row. Other than the UDP default, another difference between successful launches I've noticed is in the ConnectionCompleted(), the local addresses are different, which might be the result of a NAT issue.

broken: [2024-05-23 00:05:57] [Connecting, 4, 3] [A:1:0:0] ConnectionCompleted() (162.254.195.71:27019, WebSocket) local address (172.16.0.53:35549) working: [2024-05-23 00:13:03] [Connecting, 4, 2] [A:1:0:0] ConnectionCompleted() (162.254.195.71:27018, UDP) local address (0.0.0.0:46963)

Yes, the root cause may lie in Wine, which seems to be unable to issue WebSocket requests normally. I searched a lot, but could not find a specific solution. It may be due to Wine's imperfection of the WebSocket library.

abelvazquez4a commented 3 months ago

Do you guys have any updates on this?

Barborica-Alexandru commented 3 months ago

Unfortunately since this is most likely a wine issue, chances of getting fixed past the 50% occurrence threshold seems unlikely. I remember having a similar issue with wine quite a few years ago where the only way to fix the problem was to apply a user submitted patch to the wine source code and then build wine with the patch. The patch itself was more of a bandaid or hack rather than an actual fix to the issue so it was not approved by the wine team for upstreaming. This issue could potentially be fixed if first the issue is clearly located in the wine component, a bandaid fix is made and then wine is compiled with the patch as part of the docker container build process. But this seems like kind of a hassle considering we aren't even sure where the problem is within wine. I could take a guess and say that it is SO_SNDBUFF components (socket buffer) but I have no idea and am just vaguely trying to remember what my similar issue was years ago so take this guess with a grain of salt.