Dedi web GUI not responding

[DFA]

USA, West Coast.

 

 

For me booting it without the web gui works, I just needed to adjust the serversettings.lua to make sure it was reading the correct miz file. Not as nice as having the gui to pause,ban,restart within a couple clicks though.

[icemaker]

can you place here your serversettings.lua? and the path you put it?

[Montrose]

The server is up and running however the GUI doesn't see the server so you can't add or change missions without editing the lua - this is a pain!

[Montrose]

USA, West Coast.

 

 

For me booting it without the web gui works, I just needed to adjust the serversettings.lua to make sure it was reading the correct miz file. Not as nice as having the gui to pause,ban,restart within a couple clicks though.

 

Yes and not all of my group has access to the actual server which means changing, adding missions, restarting etc falls back on someone having to edit the lua and put the mission you wasn't run in the #1 spot. It was working great a few patches ago!

[hlfritz]

any updates on this issue since the recent patch?

[yohji]

can you place here your serversettings.lua? and the path you put it?

 

Hello IceMaker,

I'm in France and have the same problem too, serveur is working but no access to the webgui

:mad::mad::mad:

[ShadowVonChadwick]

Same issue here. Can't control the server either local or remotely.

 

 

Has there been official acknowledgement of the issue ?

 

 

Found it under Bugs & problems ..........

Edited June 27, 2019 by ShadowVonChadwick

[Loophole]

I'm still encountering this problem - but weirdly, only on one of two PCs. On one PC I can run up the dedicated server, then start the WebGUI and connect to it just fine. On the other PC I start the dedicated server and the WebGUI, but the WebGUI reports "Server not responding". As far as I can tell the two systems are identically configured; nothing I have tried has been able to get the WebGUI to connect to its local Dedicated Server on the second PC.

[hlfritz]

it is all working for me, on two different machines with two different dcs accounts. both the local gui and the remote control via dcs world login. also for both release install and openbeta installs on each of the machines.

[deyneko]

We have the same problem. The web remote interface sees our server but it says, "Server not responding".

Hope DCS will fix it soon... because it is very important to our group (remote control).

Does SLMOD work well with DCS dedicated server?

[hlfritz]

ensure you have BOTH TCP and UDP ports open in your firewall for the server port. The web control port only needs TCP, but the control app will not work if all ports/protocols are not open to the server.

[PSYKOnz]

WebGUI - DCS Server "Not Responding"

 

 

Hi there.

 

This Thread/Post is an attempt to do a few things.

 

One:

To get ED's attention for this issue

 

Two:

To bring everyone from the following threads who has the issue into one thread solely about the WebGUI not connecting, rather than 2 general server ones both talking about the same thing

https://forums.eagle.ru/showthread.php?t=233486&page=61

https://forums.eagle.ru/showthread.php?t=239614&page=18

 

Three:

To help solve the issue.

 

it's at the stage now where it's clear there is nothing we can do about it, the bug/issue is inconsistent and none of the workarounds work in any significant quantity

 

Heres what we do know:

- All of our servers work, can be seen, connected to and played on no problem

- all of our ports are open, forwarded and working fine

- some of us (using DS) have been able to connect in the past, until the bug

- some of us have never been able to connect

- cant connect in any way, local, LAN, internet

- It works on some browsers and not others on some computers

OR It doesn't work on any browser on other computers

- some of the ones not using the ds version can connect but only if they use -norender some not

 

 

Does anyone have any idea what to do to get the WebGUI working?

[Napalm Nick]

Same here

[Loophole]

My issue is connecting locally to my dedicated server.

 

 

Examining the http transactions done by the WebGui, I find it is getting a "422" error on its second transaction to the Dedicated Server. I'll do some research and see if I can identify what this error means.

 

 

It is significant that the first transaction to the server succeeds - meaning communication *is* working at that point.

 

 

 

 

 

 

Comparing this to another system that works, I see the second (POST) request coming back with a "200" success code - but the but the "Transferred" size is larger - 171 Bytes - in the successful transaction.

 

 

The initial (OPTIONS) transaction is identical on both systems.

 

 

I'm hoping that the web developer at Eagle Dynamics might be able to look at this and know immediately what the problem is!

Edited August 26, 2019 by Loophole

[Loophole]

FYI: "The HyperText Transfer Protocol (HTTP) 422 Unprocessable Entity response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions."

 

 

Which I think is telling us that the issue is at the Dedicated Server end - it got the message, understood it, but could not process it. That might be related to the packet being smaller (107 bytes) than the successful example (171 bytes).

[Loophole]

It could be an error in the javascript at the WebGui end - with it not formulating the data packed correctly for the second request, but sadly the javascript has been obfuscated, making debugging it client-side very difficult.

[Loophole]

It looks like the data sent in the erroring request is a JSON structure containing two encrypted or compressed name-value pairs:

 

 

e.g.

{"ct":"0zO+husJE8oGJkvPRmrjixGE6o3XowL522XOJr8+mn8=","iv":"Q6J4kce9IeNLeB2DrcaViA=="}

[Loophole]

Both the successful and the failing examples send an 85-byte block structured as per the above example. So: the data sent by the failing request looks to be basically correct; possibly it is compressing or encrypting incorrectly at the WebGui end due to some bug in the javascript, or incorrectly decompressing/decrypting at the Dedicated Server end due to a bug in the server logic.

[PSYKOnz]

Wow amazing work mate!

 

So it’s as we had feared something we can’t fix ourselves let’s hope your work can help the devs to fix the problem so we can start using it again.

 

Thank you so much for your time and work on this bro. It’s really good to have some concrete and verified information, legend

[USSR_Rik]

Loophole

Thanks for analysis, will repost to programmers.

[Loophole]

Thank you, Rik. If the programmers need anything tested on a "failing" system, just let me know - I'm happy to assist.

[hlfritz]

Be advised that the html error codes presented by a web server can be customized, even on a per web site (or even web page) basis. Not saying that is what has been done here, but it is possible. Most often custom error codes are added to the defaults, but sometimes the defaults are hijacked and reused for a custom error. Supposedly this is done to help debug when things go wrong. ;)

[Swany]

Using the stand alone server software

 

My issue is I can connect locally with the local web link with no problems at all, but when I try and connect via the DCS website for remote connection, it doesn't even show my server.

 

As stated above, my server IS up and running, I can see it within the game and can connect to it, 8088 is open and being forwarded correctly as well as 10308 (as stated with the I can see it from in-game), and it will show back up in the profile page of the DCS site when I restart the server

 

I can manage by logging into my local server (it's in the room with me) but this makes it difficult (read that as impossible) for my cohorts to manage the server.

Edited August 31, 2019 by Swany

[hlfritz]

just in case - make sure tcp and udp are open in firewall for port 10308 in addition to port forwarding.

[Swany]

DCS by default throws a UDP and TCP rule in place that opens all ports for the DCS.EXE. However, I went ahead and added a TCP and UDP for 10308 and a TCP for 8088 just to see how it pans out