Jump to content

Dedi web GUI not responding


Recommended Posts

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 by Swany

B. "Swany" Swanberg

Gigabyte Designare, Intel i9 9900KF (3.6, OC'd to 5.0)

32GB Patriot Viper Steel (black, non-RGB)

OS installed on a Samsung Evo 970 1TB SSD

DCS installed on a Samsun Evo 860 1TB SSD

EVGA 2080Ti 11GB

EVGA Supernova 720p 750w PS

3 Dell S2716DG monitors in Surround mode (7680x1440)

Oculus Rift S VR

Thrustmaster Warthog Throttle and Stick

Thrusmaster Rudder Pedals

assorted button boxes/Arduino boards

All drivers always kept up to date (30 days old, max)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

;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}}

Link to comment
Share on other sites

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?

Best regards

Link to comment
Share on other sites

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 by hlfritz
Link to comment
Share on other sites

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.

vCAPT Scott "LoVis" Gray

Chief of Naval Personnel

Virtual United States Navy - VUSN

vusn.org

Link to comment
Share on other sites

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 by hlfritz
Link to comment
Share on other sites

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.

attachment.php?attachmentid=217665&stc=1&d=1569253090

 

 

 

 

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.

DCS_dedicated_server.thumb.PNG.727ba83364a0406d2652ff3cf150e417.PNG


Edited by Madfish

Best regards

Link to comment
Share on other sites

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?

Tomcat, Tomcat über allen

Link to comment
Share on other sites

<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.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...