Forced Termination (Login Expired) when Re-establishing Connection to Master Server

[Actium]

TL;DR: The DCS client/server terminates with a "Login session has expired" error popup only when reconnecting to the DCS master server after the connection had been lost for 30+ minutes. No error occurs, if the connection stays lost. This makes no sense and harms user-experience unnecessarily.

Technical Details

The DCS client* must authenticate with the DCS master server (api.digitalcombatsimulator.com) when starting. As part of a successful authentication, the client will receive a temporary session ID from the master server. The client uses that session ID to periodically check with the master server every ~10 minutes. Clients and master server communicate via encrypted HTTP. The periodic session check is an HTTP POST request to which the master server normally responds with status code 200 (OK).
*) Here and subsequently, "client" refers to a client of the master server. This includes the DCS dedicated server, which also performs authentication and periodic session checks with the master server.

The master server session cache expires within ~30 minutes: If the master server has not received session checks from a client for ~30 minutes, it will forget the respective session ID. Afterwards, the master server will respond with HTTP status code 401 (Unauthorized) to any session check from a client with an expired session ID. This will be logged in dcs.log as: ERROR   ASYNCNET (192): The session has expired (401). Exiting...
The affected DCS client will not try to reauthenticate, but instead terminate with a "Login session has expired" error popup.

This issue is likely not restricted to re-establishing connection with the master server and HTTP error 401. Other master server-side errors trigger the client-side termination, too. If the master server (or the reverse proxy it resides behind) temporarily responds with other error codes, e.g., 502 Bad Gateway, the client terminates itself, too. While I've not experienced this particular error code myself, it's been reported here.

Who is Affected / Why to Fix This

1. All players and servers: If the master server goes down and forgets all session IDs, all clients and servers will be forcibly terminated, too. This has happened on multiple occasions. Either scheduled or repeatedly unscheduled (1, 2, 3, 4). This issue frustrates customers. With the master server being a single point of failure, this presents a possible attack surface. I'll refrain from elaborating on this further to not give random script kiddies any bad ideas.
2. Players with a spotty internet connection (to the master server): Spotty internet connections are hard to debug and even harder to fix. Even if everything else works (e.g., playing DCS in multiplayer, streaming, downloads, etc.), an ISP's route to the single DCS master server may be sufficiently congested to affect the periodic session checks temporarily. Whereas DCS updates/downloads are handled via a globally distributed CDN, there's a only one master server that is located in Europe (ping/traceroute api.digitalcombatsimulator.com and cdn.digitalcombatsimulator.com). Players complaining about this in the forum are typically referred to customer service. A proper fix may pay for itself by less customer service tickets. I'd also expect far more players to be affected than there are reports on the forum (1, 2, 3, 4).
3. Casual single players or mission editors who want to suspend their computer mid-mission to resume another day: Suspending your computer for more than 30 minutes will also result in forced termination. With the DCS save feature not yet capable of resuming complex missions, this is a valid use case for casual DCS players.

Workaround (@Affected Players)

As the DCS client only terminates after reconnecting to the master server, the termination can be inhibited by preventing the reconnect. Do this at your own risk:

1. Start DCS.
2. Once in the main menu, the mission editor, or on a multiplayer server, inhibit further communication with the master server (api.digitalcombatsimulator.com), e.g., via firewall rules or by adding an invalid IP route with an administrator command prompt: route add 185.195.197.20/32 0.0.0.0
3. Go about your day, suspend/resume your computer, or connect to multiplayer servers via IP address. The multiplayer server browser will no longer work.
4. After closing DCS, remove the firewall rule or the invalid IP route: route delete 185.195.197.20/32 0.0.0.0

How to Fix This (@ED)

This issue could (and should) be addressed both at the client and the master server:

1. The master server session ID cache should not expire prematurely. Using the 72 hours saved authentication grace period for expiring sessions seems reasonable. This fix should be relatively straightforward to implement as a stopgap measure.
2. The client (and dedicated server) should always attempt to reauthenticate with the master server instead of just quitting immediately after a failed session check. Silently start the 72 hour saved authentication grace period once the connection to the master server is lost (or the master server experiences server-side errors, i.e., 500+) and only terminate the client if the master server hasn't been reached within that duration. Reset the grace period once the connection to the master server has been re-established. That should balance between user-experience (which ultimately pays ED salaries) and software piracy concerns.

How to Reproduce

1. Start DCS (in Online Mode), open the Mission Editor. Wait a minute.
2. Disconnect DCS from the master server api.digitalcombatsimulator.com (185.195.197.20). Either by disconnecting from the Internet, by using a firewall rule for the aforementioned IP, or by setting a non-existing network route via a command prompt with administrator privileges (route add 185.195.197.20/32 0.0.0.0). Alternatively, you can also just suspend your computer.
3. Keep DCS disconnect from the master server for 30+ minutes (less may suffice, too, but AFAICT it needs to miss more than just one session check).
4. Re-enable the connection to the master server. If you used the route method, delete the invalid route: route delete 185.195.197.20/32 0.0.0.0
5. Wait for DCS to quit within the next minute or so.

Edit: Updated post, added workaround. Original post in below spoiler.

Spoiler

  TL;DR: Not a crash, but a totally unnecessary forced termination: After having lost the connection to the master server temporarily, both DCS client and dedicated server will forcefully terminate with a Login session has expired popup message only when re-connecting to the master server.

IMHO it is very illogical to forcibly terminate the client only when the connection to the master server is re-established. Users' network connections may be intermittent. Additionally, the DCS master server is a global single point of failure with no redundancy (api.digitalcombatsimulator.com has a single A record). Outages have happened before. Either scheduled or repeatedly unscheduled (1, 2, 3). The latter have caused the described forced termination, dissatisfying customers.

This is a gigantic footgun simultaneously aiming at all customers' feet (a foot cluster bomb? a footnuke?). A short 20~30 minute master server outage will boot everyone from their game. Almost guaranteed to disgruntle those affected.

@ED: If you decide to fix this, please also consider enabling multiplayer access for sessions with saved authorizations. This would enable us the still play DCS in multiplayer (connect via IP), even if your master server goes down for more than just a few minutes, which can totally happen for lack of redundancy.

More Details

When DCS starts, it will authenticate with the master server. Afterwards, the client will periodically poll the master server in ~10 minute intervals. If the connection to the master server is lost, nothing happens, apart from more frequent attempts to reconnect. AFAICT, longer periods (tested for 1~2 hours) of a continuously unreachable master server have no direct consequences: DCS will stay connected to a multiplayer server, connect to new servers via IP, run the mission editor, etc. Obviously, the multiplayer server list will not populate.
However, as soon as the client re-establishes connection to the master server, DCS quits with the aforementioned popup message:

Steps to reproduce

1. Start DCS (in Online Mode), open the Mission Editor. Wait a minute.
2. Disconnect DCS from the master server api.digitalcombatsimulator.com (185.195.197.4). Either by disconnecting from the Internet, by using a firewall rule for the aforementioned IP, or by setting a non-existing network route via a command prompt with administrator privileges (route add 185.195.197.4/32 0.0.0.0). Alternatively, you can also just suspend your computer.
3. Keep DCS disconnect from the master server for 30+ minutes (less may suffice, too, but AFAICT it needs to miss more than just one periodic check-in).
4. Re-enable the connection to the master server. If you used the route method, delete the bogus route: route delete 185.195.197.4/32 0.0.0.0
5. Wait for DCS to quit within the next minute.

I've attached an exemplary dcs.log with DEBUG messages enabled. The connection was disabled ~1 minute after starting the game and re-enabled after an hour at exactly 09:59:13Z. DCS made the next reconnection attempt shortly after and then immediately exited with above popup.

 

Edited Monday at 02:04 PM by Actium

[BIGNEWY]

Hi, 

we have made a report for the team to check. 

I have moved out of crash and into core wish list for now.

thank you 

[Actium]

Thanks. I really do consider this a crash-like situation, as the game decides to intentionally terminate itself, for no logical reason whatsoever. While IMHO still entirely unreasonable(!) from a usability and stability perspective, it would have made more sense to terminate when losing the master server connection. However, terminating when regaining the master server connection appears so extremely illogical that it can only be a bug*. Hope the Devs agree

*) Even for an always online title, which DCS -- fortunately -- is not, termination after successful reconnection and reauthentification would not make sense, unless its intent were purely punitive in nature.

[Actium]

Master server was down unannounced this morning for ~29 minutes from 00:02Z to 00:31Z. See attached dcs.log excerpt and associated tcpdump.log. As described above, my dedicated server decided to die only after the master server came back up:

00:33:57 hostname dcs-watchdog.py[794795]: No response from server: [Errno 111] Connection refused
00:34:12 hostname dcs-watchdog.py[794795]: No response from server: [Errno 111] Connection refused
00:34:27 hostname dcs-watchdog.py[794795]: No response from server: [Errno 111] Connection refused
00:34:27 hostname dcs-watchdog.py[794795]: Terminating after 3 missed responses.
00:34:27 hostname systemd[1395]: Stopping dcs-server@server1.service - DCS Dedicated Server...
00:34:28 hostname sh[804672]: Close message sent to top-level windows of process with PID 19873904.
00:34:30 hostname systemd[1395]: Stopped dcs-server@server1.service - DCS Dedicated Server.
00:34:30 hostname systemd[1395]: Started dcs-server@server1.service - DCS Dedicated Server.
00:34:30 hostname systemd[1395]: Started dcs-watchdog@server1.service - DCS Dedicated Server Watchdog.

Same happened to all dedicated servers on all discords I checked (4YA, TDCS, DFA/Grayflag) as well as to presumably all clients [1, 2, 3, 4].

@BIGNEWY Bringing this to your attention again. This issue takes down all clients and servers absolutely unnecessarily. This is not a nice-to-have wishlist item, but an undeniably serious bug that affects all players and server admins. It is exacerbated on dedicated servers, by requiring manual acknowledgment of above Login session has expired error popup (also see here). This prevents most automatic crash recovery scripts from restarting the servers, because the server process is blocked on the popup message and does not crash/exit. The process terminates after acknowledging the popup.

Edited March 29 by Actium

[Flappie]

BIGNEWY won't be here next week. I relayed your message on the internal report.

[Special K]

Am 25.2.2025 um 11:08 schrieb Actium:

TL;DR: Not a crash, but a totally unnecessary forced termination: After having lost the connection to the master server temporarily, both DCS client and dedicated server will forcefully terminate with a Login session has expired popup message only when re-connecting to the master server.

IMHO it is very illogical to forcibly terminate the client only when the connection to the master server is re-established. Users' network connections may be intermittent. Additionally, the DCS master server is a global single point of failure with no redundancy (api.digitalcombatsimulator.com has a single A record). Outages have happened before. Either scheduled or repeatedly unscheduled (1, 2, 3). The latter have caused the described forced termination, dissatisfying customers.

This is a gigantic footgun simultaneously aiming at all customers' feet (a foot cluster bomb? a footnuke?). A short 20~30 minute master server outage will boot everyone from their game. Almost guaranteed to disgruntle those affected.

@ED: If you decide to fix this, please also consider enabling multiplayer access for sessions with saved authorizations. This would enable us the still play DCS in multiplayer (connect via IP), even if your master server goes down for more than just a few minutes, which can totally happen for lack of redundancy.

More Details

When DCS starts, it will authenticate with the master server. Afterwards, the client will periodically poll the master server in ~10 minute intervals. If the connection to the master server is lost, nothing happens, apart from more frequent attempts to reconnect. AFAICT, longer periods (tested for 1~2 hours) of a continuously unreachable master server have no direct consequences: DCS will stay connected to a multiplayer server, connect to new servers via IP, run the mission editor, etc. Obviously, the multiplayer server list will not populate.
However, as soon as the client re-establishes connection to the master server, DCS quits with the aforementioned popup message:

Steps to reproduce

1. Start DCS (in Online Mode), open the Mission Editor. Wait a minute.
2. Disconnect DCS from the master server api.digitalcombatsimulator.com (185.195.197.4). Either by disconnecting from the Internet, by using a firewall rule for the aforementioned IP, or by setting a non-existing network route via a command prompt with administrator privileges (route add 185.195.197.4/32 0.0.0.0). Alternatively, you can also just suspend your computer.
3. Keep DCS disconnect from the master server for 30+ minutes (less may suffice, too, but AFAICT it needs to miss more than just one periodic check-in).
4. Re-enable the connection to the master server. If you used the route method, delete the bogus route: route delete 185.195.197.4/32 0.0.0.0
5. Wait for DCS to quit within the next minute.

I've attached an exemplary dcs.log with DEBUG messages enabled. The connection was disabled ~1 minute after starting the game and re-enabled after an hour at exactly 09:59:13Z. DCS made the next reconnection attempt shortly after and then immediately exited with above popup.

 

There is a difference if your server went down or if the master server went down.

If your server / network connection goes down, the session is being invalidated, if you do not send heartbeats. This happens after a specific while and is quite normal (session termination). In such a case, when your client (or in this case the server that is a client) re-connects, your session token is invalid, causing the error.

This leads to a situation, that you try to talk to the server with an incorrect session token, which would not work.

I agree, that if the ED server goes down and there is in fact no session anymore, the error should be different. And I was in contact already with the guys, to look at the reconnect to recover that. What can not happen is that ED has to keep all sessions of people where it is not to be detected if your server has crashed, your network has vanished or you just decided to go on vacation. So the reconnect has to be a temporary solution to either cover singular heartbeat misses or login server outages.

[Actium]

Universal, straightforward solution: If the master server responds 401 – for whatever reason, e.g., an expired token – the client (or dedicated server) should simply try to log in again in the background (no interaction required), instead of terminating itself. The regular 3 day grace period should start automatically (i.e., no popups that need manual acknowledgment). Only after it expires without ever reaching the master server again, the client (or dedicated server) may terminate itself. The grace period should reset after successful (re-)login with the master server.

The current situation where when the network goes down on either end, all affected clients (or dedicated servers) will terminate themselves, results in a terrible user experience, which should IMHO be of utmost concern. Good user experience, leads to customers willing to spend money on the product, which is presumably the primary revenue source. An expired session token, which could simply be renewed by logging in automatically in the background, as suggested above, is no justification to unceremoniously terminate the game.

On 4/2/2025 at 5:20 PM, Special K said:

What can not happen is that ED has to keep all sessions of people where it is not to be detected if your server has crashed, your network has vanished or you just decided to go on vacation.

Irrelevant wrt. above suggested solution, but just for the sake of argument: Why not? A session token should take no more database space than a properly salted and hashed password. I see no technical difference between keeping session tokens for up to 30 minutes (should be in non-volatile memory, anyway, for the sake of master server crash resilience) or retaining the most recent session token for each account, indefinitely.

[Special K]

vor 12 Stunden schrieb Actium:

Universal, straightforward solution: If the master server responds 401 – for whatever reason, e.g., an expired token – the client (or dedicated server) should simply try to log in again in the background (no interaction required), instead of terminating itself. The regular 3 day grace period should start automatically (i.e., no popups that need manual acknowledgment). Only after it expires without ever reaching the master server again, the client (or dedicated server) may terminate itself. The grace period should reset after successful (re-)login with the master server.

The current situation where when the network goes down on either end, all affected clients (or dedicated servers) will terminate themselves, results in a terrible user experience, which should IMHO be of utmost concern. Good user experience, leads to customers willing to spend money on the product, which is presumably the primary revenue source. An expired session token, which could simply be renewed by logging in automatically in the background, as suggested above, is no justification to unceremoniously terminate the game.

Irrelevant wrt. above suggested solution, but just for the sake of argument: Why not? A session token should take no more database space than a properly salted and hashed password. I see no technical difference between keeping session tokens for up to 30 minutes (should be in non-volatile memory, anyway, for the sake of master server crash resilience) or retaining the most recent session token for each account, indefinitely.

What you ask for is a change in the game. I even wonder where you see all these session failures you are reporting here? I am admin in 2 of the largest servers (GS and HBCW) and we do not see that at least. I get occasional messages from the other server admins but not on a daily basis or in any means as frequent as you describe it here.

And the session token is kept for more than 30 mins already. Each account has multiple session tokens btw. You can run more than one session at a time (one client and up to 5 server sessions on each account).

Edited April 4 by Special K

[Special K]

Just checked, we had a total of 6 of these events in the past half year on GS which probably corresponds with the auth server outages that were there.

[Actium]

10 hours ago, Special K said:

What you ask for is a change in the game.

Exactly. I'd consider it a no-brainer to fix an issue that'll boot all clients and brick all servers if the master server takes a break.

11 hours ago, Special K said:

You can run more than one session at a time (one client and up to 5 server sessions on each account).

Good point. But still shouldn't be a problem to track these.

11 hours ago, Special K said:

Just checked, we had a total of 6 of these events in the past half year on GS which probably corresponds with the auth server outages that were there.

So that's once a month on average. I'd call that quite often. Too often to forcibly terminate all currently logged in sessions, IMHO.

[Special K]

Am 4.4.2025 um 23:48 schrieb Actium:

So that's once a month on average. I'd call that quite often. Too often to forcibly terminate all currently logged in sessions, IMHO.

Well, we're talking a game here and not a high available banking application. I think an outage once a month is quite a great availability. You do not even get that SLA from any of your internet providers, so you can not expect that from ED also. Anyway, your point is noted, BN already said that the team will look into it. So lets see what comes out of it.

[Actium]

This issue appears to have been bothering quite a few people, lately (1, 2, 3, 4).
I've rewritten the OP with additional information and a workaround. I do hope ED will find the time to fix this.

[Actium]

DCS apparently also terminates itself when the master server experiences server-side errors (500+ status codes). I haven't seen that myself, but it's been reported here. I've updated the first post accordingly.

[Dawgboy]

Realizing BigNewy said they are looking at it, I want to state this has occurred 4 times in the last month for me, which never happened before.  It's more than an inconvenience, especially if I'm working locally/alone on building missions and not even multiplayer flying.  I've lost changes to complex mission builds twice and twice during critical system tests that took me many minutes of flying to check multiple subsystems on a new build, only to have it crump to start over again.

It should have better built-in resiliency, especially when working locally/non-networked.

[algherghezghez]

Ok this is starting to be really annoying...

A few updates ago I was able to suspend the pc and continue a mission the next day, now, as other countless users reported this is not possible anymore because the login session will expire.

Adding to this problem now the login session apparently also expires during flight! I was flying a two hour long mission just for the game to kick me out in the middle of it. all of this while playing SP! 

dcs.log

[BIGNEWY]

Hi, 

please create a support ticket, the team can check the account. 

Give them as much information as possible and the dcs log. 

ERROR   ASYNCNET (19368): The session has expired (401). Exiting...

https://www.digitalcombatsimulator.com/en/support/

[skybaby68]

Me too. It's so frustrating. Especially when mission building. It's now a common occurrance and has been for around 3 weeks to a month now. 

[BIGNEWY]

do any of you have another pc where a session is active, or is it just one pc?

 

[algherghezghez]

2 minutes ago, BIGNEWY said:

do any of you have another pc where a session is active, or is it just one pc?

 

I only have one pc where dcs is installed/active. I never used my account on any other pc 

[BIGNEWY]

please create a support ticket and your dcs log from a session where it happens they will try to assist you 

thank you 

[Actium]

1 hour ago, algherghezghez said:

A few updates ago I was able to suspend the pc and continue a mission the next day, now, as other countless users reported this is not possible anymore because the login session will expire.

Now that requires offline-mode or whacky workarounds.

1 hour ago, algherghezghez said:

Adding to this problem now the login session apparently also expires during flight! I was flying a two hour long mission just for the game to kick me out in the middle of it. all of this while playing SP!

In your case, this was caused by an interruption in the connection to the master server (or more likely your entire internet connection went out for a while). Search for ASYNCNET errors/warnings in your dcs.log:

Spoiler

2025-06-27 08:01:24.944 INFO    ASYNCNET (19368): Login success.
2025-06-27 08:01:27.476 INFO    ASYNCNET (19368): Got auth data.
2025-06-27 08:01:27.729 INFO    ASYNCNET (Main): ProtocolVersion: 404
2025-06-27 08:01:27.729 INFO    ASYNCNET (Main): Adding LAN search interface 0: 127.0.0.1 "IPv4 Loopback"
2025-06-27 08:01:27.729 INFO    ASYNCNET (Main): Adding LAN search interface 0: 255.255.255.255 "IPv4 Broadcast"
2025-06-27 09:25:59.361 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 09:25:59.361 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 09:27:21.045 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 09:27:21.045 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 09:28:42.679 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 09:28:42.680 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:18:03.125 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:18:03.125 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:19:18.719 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:19:18.720 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:20:35.094 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:20:35.094 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:21:54.129 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:21:54.130 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:23:09.922 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:23:09.922 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:24:25.927 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:24:25.928 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:25:42.232 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:25:42.232 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:26:58.254 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:26:58.254 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:28:13.725 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:28:13.725 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:41:36.702 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:41:36.702 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:42:58.687 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:42:58.687 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:44:20.944 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:44:20.944 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:45:43.124 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:45:43.125 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:47:04.714 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:47:04.715 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:47:25.866 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:47:25.866 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:48:47.940 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:48:47.941 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:50:10.166 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:50:10.167 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:51:31.693 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:51:31.693 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:52:54.100 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:52:54.100 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:53:55.221 ERROR   ASYNCNET (19368): The session has expired (401). Exiting...
2025-06-27 10:53:57.203 ERROR   ASYNCNET (19368): The session has expired (401). Exiting...

Unfortunately, the DCS client will terminate itself after the connection to the master server had been lost for 30+ minutes, but only when ultimately reconnecting to the master server. This appears to be what happened here.

27 minutes ago, BIGNEWY said:

please create a support ticket and your dcs log from a session where it happens they will try to assist you

Nothing support can do about it. This needs to be fixed in the game as I've explained here: 

@BIGNEWY I understand you're afraid of accounts being used simultaneously, however, the current attempt at preventing that is frustrating legitimate customers.

[algherghezghez]

2 minutes ago, Actium said:

Now that requires offline-mode or whacky workarounds.

In your case, this was caused by an interruption in the connection to the master server (or more likely your entire internet connection went out for a while). Search for ASYNCNET errors/warnings in your dcs.log:

  Reveal hidden contents

2025-06-27 08:01:24.944 INFO    ASYNCNET (19368): Login success.
2025-06-27 08:01:27.476 INFO    ASYNCNET (19368): Got auth data.
2025-06-27 08:01:27.729 INFO    ASYNCNET (Main): ProtocolVersion: 404
2025-06-27 08:01:27.729 INFO    ASYNCNET (Main): Adding LAN search interface 0: 127.0.0.1 "IPv4 Loopback"
2025-06-27 08:01:27.729 INFO    ASYNCNET (Main): Adding LAN search interface 0: 255.255.255.255 "IPv4 Broadcast"
2025-06-27 09:25:59.361 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 09:25:59.361 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 09:27:21.045 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 09:27:21.045 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 09:28:42.679 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 09:28:42.680 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:18:03.125 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:18:03.125 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:19:18.719 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:19:18.720 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:20:35.094 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:20:35.094 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:21:54.129 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:21:54.130 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:23:09.922 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:23:09.922 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:24:25.927 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:24:25.928 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:25:42.232 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:25:42.232 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:26:58.254 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:26:58.254 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:28:13.725 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 6: Could not resolve hostname
2025-06-27 10:28:13.725 WARNING ASYNCNET (19368): Session check failed: -6
2025-06-27 10:41:36.702 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:41:36.702 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:42:58.687 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:42:58.687 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:44:20.944 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:44:20.944 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:45:43.124 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:45:43.125 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:47:04.714 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:47:04.715 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:47:25.866 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:47:25.866 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:48:47.940 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:48:47.941 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:50:10.166 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:50:10.167 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:51:31.693 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:51:31.693 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:52:54.100 ERROR   ASYNCNET (19368): HTTP request dcs:checksession failed with error 28: Timeout was reached
2025-06-27 10:52:54.100 WARNING ASYNCNET (19368): Session check failed: -28
2025-06-27 10:53:55.221 ERROR   ASYNCNET (19368): The session has expired (401). Exiting...
2025-06-27 10:53:57.203 ERROR   ASYNCNET (19368): The session has expired (401). Exiting...

Unfortunately, the DCS client will terminate itself after the connection to the master server had been lost for 30+ minutes, but only when ultimately reconnecting to the master server. This appears to be what happened here.

Nothing support can do about it. This needs to be fixed in the game as I've explained here: 

@BIGNEWY I understand you're afraid of accounts being used simultaneously, however, the current attempt at preventing that is frustrating legitimate customers.

Thanks actium for the detailed explanation! 
 

let me just understand something:

can I force the offline mode without disconnecting from internet or do I need to disconnect and launch dcs?
 

once in offline mode, reconnecting internet will force online mode or will I stay in offline mode until the next session?

Playing in offline mode at least for long campaign missions could be the momentary solution…

[BIGNEWY]

threads merged

[MAXsenna]

Thanks actium for the detailed explanation! 
 
let me just understand something:
can I force the offline mode without disconnecting from internet or do I need to disconnect and launch dcs?
 
once in offline mode, reconnecting internet will force online mode or will I stay in offline mode until the next session?
Playing in offline mode at least for long campaign missions could be the momentary solution…

When you enter offline mode, it will just go offline, and stay that forever, until you enter online. Then the game will restart and you are in online mode. Very handy actually.

Sent from my SM-A536B using Tapatalk

[Dawgboy]

2 hours ago, BIGNEWY said:

do any of you have another pc where a session is active, or is it just one pc?

 

For me, it's just one PC when this happens.  BTW, this happens to a freshly started DCS without a suspension, hibernate, etc.  Just logged in minutes before, go in to edit a mission or fly, and after maybe 10-15 mins, session expired and logs me off.  I'm back to Windows desktop with no recourse to stop the logoff, and I lose all of my work, etc.