Dedi web GUI not responding

[hlfritz]

you may have another firewall, not just on your PC. you may have a router with a firewall as well, or if it is doing NAT the ports and protocols need to be forwarded to the proper computer as well.

[Swany]

Router does have a firewall, it is using NAT, ports are forwarded correctly. All in all, everything was/is set correctly, adding the specific ports, in theory, wasn't necessary, but, Windows. So far, as of the time I'm writing this reply, it's still accessible via the DCS website, so I'll say again, Windows ;)

 

Appreciate you saying something, other wise, I would have just gone on thinking "Well, all ports are already open....."

Edited September 7, 2019 by Swany

[hlfritz]

no worries.

[eScourge]

I Have just installed the dedi server on a separate machine, have opened all ports on router and firewall and also am having the same problem.

[hlfritz]

just in case, as stated, not just ports but protocols as well. both tcp and udp need to be opened for 10308 (unless you change that port). also both on local machine and in firewall.

[eScourge]

just in case, as stated, not just ports but protocols as well. both tcp and udp need to be opened for 10308 (unless you change that port). also both on local machine and in firewall.

 

Yes confirmed I have tried with protocols inbound/outbound set to allow for specific ports or for program to be allowed and with/without manual port forwarding and with/without upnp port forwarding and any possible combination for all of these.

 

Currently on my main machine I can host a server and connect to it and have my friends connect to it using --norender --server --w launch parameters from regular client. I cannot replicate this on my server machine nor can I get the open beta server software to host correctly. When I host with my server machine using open beta server I can see the server at https://www.digitalcombatsimulator.com/en/personal/server/

the server has its IP listed correctly here but has the port as N/A and I cannot connect through the webGUI

[hlfritz]

i think i had the same thing happen to me and i had forgotten for forward/allow for udp on the server port (tcp i did).

[eScourge]

Its a very strange thing indeed that is happening.

 

On my gaming machine when I run the server my router automatically opens the ports required 8088 TCP and 10308 TCP/UDP and everything works flawlessly. On the server machine only port 8088 TCP is opened, and again manually opening of ports is offering no result.

I have reinstalled windows and the server software to no joy.

Windows is creating correct protocol rules during install process.

[hlfritz]

sounds like you might have some type of upnp enabled on the router. i usually find it is a good idea to turn that off and manage things manually. i usually turn off the firewall on my windows machine since it is always sitting behind my router/firewall, but that should not be necessary as long as you get the prompts to allow the application when it runs. usually a router will only allow ports to be forwarded to one system at a time as well. sorry i do not think i have any hints or suggestions.

[eScourge]

Yeah i have enabled Upnup. Its the only way i can get ports 8088 and 10308 to open. manually opening ports is not working.

 

I have managed to get the server up and running and had some mates join in to test.

I used this guide https://thefraternitysim.com/how-to-properly-setup-a-dcs-world-dedicated-server/

 

I stil cant get the webgui to respond. so all changes I have to make using the serversettings.lua

[SMH]

;3942806']Exactly, servers are working fine, it's just the GUI not being reachable, which probably has to do with an outdated encryption key for the webgui app.

 

 

You can still run your server like we used to do before the GUI.

Just make sure you change the mission in the serversettings.lua and start with --server --norender so it starts with the first mission in the missionlist.

 

What is the syntax for that, exactly? Rik mentions it but his instructions seem to assume we're either psychic or that it's in the file by default, which it isnt. The only thing in there is:

 

cfg={advanced={resume_mode=1}}

[SMH]

It's okay, I found it https://forums.eagle.ru/showthread.php?t=157580

[Wood]

Sorry to say but it’s pretty pathetic that this webgui issue has been going on for months now with no resolve.

[PSYKOnz]

would be nice if it could be fixed, now that we know what the problem is. its a real pain in the but having to drop the server, change the mission manually then restart it every time

[CHPL]

I had 2 servers responding and one not on the same machine. So I deleted the one that gets no contact and installed him again. Now all 3 servers get contact with the same WebGui.

[PSYKOnz]

can anyone else confirm that a reinstall works?

[yohji]

Could you explain how do you uninstall it? Do you uninstall the game completely?

[eScourge]

I have tried reinstalling windows,

 

I have tried reinstalling The Dedi server software.

 

I have tried reinstalling the base game and using --server --no render.

 

Nothing has worked

[Madfish]

There could be a slim chance on a reinstall for some applications but it doesn't make much sense if done correctly. What should be different?

I did that dozens of times with no success what so ever.

 

BUT there is something interesting:

A striking difference I noticed however that I would like you guys to check:

are you running the servers on a native bare-metal system or are you running it virtualized on a hypervisor?

 

 

While:

• I can run it 100% working on a virtualization running on native OS (e.g. VMware Workstation on a "normal" Windows Computer)
  
• I can replicate the bug 100% when running it virtualized on a hypervisor (e.g. Proxmox, Xen or similar)
  

So maybe that is the root cause here to some degree or it's just another bug that has the same symptom?

[hlfritz]

I am running mine on a Debian host using KVM-qemu with virtualized win10 successfully.

 

I cannot stress enough I had similar control problems until I properly forwarded UDP. Local control (loggged into the virtualized Windows OS via remote desktop) worked, but control through the ED account login/my servers portal did not work until I had UDP forwarded along with TCP. It would show up in my servers when logged in to my account, but control would fail (could not connect). Once I forwarded/allowed UDP as well it functioned just fine.

Edited September 22, 2019 by hlfritz

[sgray]

I guess the real issues is for those of us that had it working without issue before an update around April/May, then it stopped working. Why would we need to change anything (although I am sure everyone has since check and forwarded both IUP/UDP)? Certainly seems that something else has definitely changed on EDs end and not on the end users. Disappointing that something was provided (which everyone is thankful) but then nothing seems to be done about it for over five months.

[hlfritz]

yes, also agreed. it seems to be related to some security cert or other and maybe reinstalling will replace it, at other times it does not. i installed after that time period so perhaps mine is working as a new install as well. maybe there is something in the os certificate manager that could be sussed out.

 

i see on my laptop where i tested the dedicate server i have two certificates (one 3rd party root and one intermediate) by thawte which correspond to the cert used when connected to digitalcombatsimulator.com (eagle.ru has a sepearate cert from the same thawte auhority). i also have a thawte timestamping cert. not sure if these are used for the remote control app at all, but all of their validity dates are current.

 

this applet can be opened by typing certmgr.msc in the run window or at a command prompt. not sure if looking at these on the servers will help, but just an idea since some have mentioned a security type of issue.

Edited September 22, 2019 by hlfritz

[Madfish]

I am running mine on a Debian host using KVM-qemu with virtualized win10 successfully.

 

I cannot stress enough I had similar control problems until I properly forwarded UDP. Local control (loggged into the virtualized Windows OS via remote desktop) worked, but control through the ED account login/my servers portal did not work until I had UDP forwarded along with TCP. It would show up in my servers when logged in to my account, but control would fail (could not connect). Once I forwarded/allowed UDP as well it functioned just fine.

 

 

 

yes, also agreed. it seems to be related to some security cert or other and maybe reinstalling will replace it, at other times it does not. i installed after that time period so perhaps mine is working as a new install as well. maybe there is something in the os certificate manager that could be sussed out.

 

i see on my laptop where i tested the dedicate server i have two certificates (one 3rd party root and one intermediate) by thawte which correspond to the cert used when connected to digitalcombatsimulator.com (eagle.ru has a sepearate cert from the same thawte auhority). i also have a thawte timestamping cert. not sure if these are used for the remote control app at all, but all of their validity dates are current.

 

this applet can be opened by typing certmgr.msc in the run window or at a command prompt. not sure if looking at these on the servers will help, but just an idea since some have mentioned a security type of issue.

 

Great points. But just to be clear: there is the possibility of this bug having the same symptoms for different root causes.

 

 

What I can say is there seem to be two main issues:

1) "Only" the remote DCS Server Dashboard saying "Server not responding"

2) the LOCAL DCS Server Dashboard saying "Server not responding"

 

 

If you are having issue #1 it IS fixable (e.g. with opening / forwarding ports)

If you are having issue #2 it is likely NOT fixable and is an issue that came with patch 2.5.5.31917. It is also likely NOT on your end - it's a DCS issue. I can reproduce this 100%.

 

However, for my situation it's not related to either Certs or UDP ports being open.

 

Let me explain why.

 

 

Certs:

• When I install DCS ded srv on my Windows 8 / Windows 10 machine I can run it fine
  
• When I install DCS ded srv inside a Oracle Virtual Box VM on my Windows 8 / Windows 10 machine I can run it fine
  
• When I install DCS ded srv inside a VMware VM on my Windows 8 / Windows 10 machine I can run it fine
  
• When I install Windows server natively on the server and install DCS ded srv I can run it fine
  
• When I install Windows 10 or Windows Server 2019 inside a Proxmox VM on my machine I can't run it fine - It gives me the "Server not responding" bug
  
• When I install Windows 10 or Windows Server 2019 inside a Proxmox VM on dedicated server machine I can't run it fine - It gives me the "Server not responding" bug
  

Also tested Xen with the same result. This can't be cert related.

 

 

 

 

Ports being open or not

 

 

Even if I block access inside Windows firewall I can't reproduce the bug. In fact I can run DCS ded srv fine even if I disable all of my network connections alltoghether.

 

 

 

 

Conclusions

What I can safely say is that DCS ded srv does not work if the Windows (7 / 8 / 10 / Windows Server 2019 etc.) is running on a server with a hypervisor anymore since exactly patch 2.5.5.31917. This can be reproduced 100%

Steps to reproduce:

• Grab a computer
  
• Install Proxmox VE (free, based on Debian)
  
• Install a Windows of your preferred flavor > DCS ded srv interface breaks locally AND remotely (Server not responding)
   
  Whatever was done in patch 2.5.5.31917 broke it.
   
   
  What didn't help:
  
• Multiple Windows flavors, including different builds, languages and territory settings.
  
• Installed Windows patches or not.
  
• No mods / mods installed
  
• Firewall On/Off
  

Nothing changed the fact that since 2.5.5.31917 bare metal hypervisors are broken.

 

That is why I was asking if those, with the LOCAL DCS Server Dashboard broken, are eventually running their OS inside a VM on a hypervisor (Proxmox, VMware ESXi, Xen etc.) as it is 100% reproducable.

Edited September 24, 2019 by Madfish

[PSYKOnz]

Lather rinse repeat

 

Mine is a local DCS Server that's broken, has been since the patch broke it. worked fine before then

 

it's starting to get stupid now, we all know its an issue with DCS, why have we not had a fix yet or at very least had some information or notice from ED on it?

 

all that seems to happen is that this thread gets longer with more and more people having the issue and nothing getting done about it. the last thread got to 50+ pages, and nothing happened is that what's going to happen here?

 

why can't we get a fix or at least something to show that ED are at least working on it?

[TrollingThunder]

<snip>

 

That is why I was asking if those, with the LOCAL DCS Server Dashboard broken, are eventually running their OS inside a VM on a hypervisor (Proxmox, VMware ESXi, Xen etc.) as it is 100% reproducable.

 

Don't know if it would help in anyway, but I run a dedicated server in a VM that runs just fine with both local and remote server dashboard. Host is Ubuntu, using standard libvirt and qemu stuff. The guest is just a Windows 10 (1903?) image.