MudSpikers - I’m back in the forum after some time off to move to Nevada and get settled in, and it took a while to find decent wireless internet at my home.
@Sryan and I have still been flying on Sundays, but we’d like to try running our own server for some specific missions and training. However - I can’t seem to conquer this. We’ve tried it through OpenBeta, now through OpenBeta Server, and the Local Web GUI… I’ve even downloaded SkateZilla’s app, with no luck.
Is anyone available for a paid Zoom Chat to help me figure out how to properly run a server on my PC? It should work - I’m following all the steps… It’s just not, and I know it’s a setting somewhere that I’m missing.
DCS server uses port 10308 by default, if I recall correctly you need both TCP and UDP. It also can negotiate UPNP, if you have that enabled. If not, port forward to your server.
Also, your server requires it’s own unique DCS account. No licenses are needed for terrains IF you run the actual dedicated server.
Ensure your server machine cannot change it’s IP address by using a static IP in Windows OR setting a DHCP reservation from your DHCP server (usually the router).
My server for example is LAN 192.168.1.63
Router port forward rule is as follows:
Source IP: Any
Destination IP: 192.168.1.63
Your own server should be visible to you in the server browser from it’s LAN IP address. Others should see it in the listing within a couple minutes of startup. You can also do a manual WAN IP connect to verify connectivity, as sometimes DCS master server (that generates the server list) has problems. It recently was down or reset within the past couple days.
Feel free to bug me on Discord about it between the hours of 2020-09-01T22:30:00Z → 2020-09-02T03:00:00Z (ignore the date, just used the date tool so as to convert timezones for ya!) any weekday, I am usually free if I am not riding my motorcycle. That timeslot covers the time between home from work & bed time haha. I can stretch it a bit to just past midnight my time (I am EST / UTC -4 now -5 winter) if needed as well.
I have no problem testing & helping configure if needed. Cheers!
Bryan was looking for it - we kept it public and simple just to see if we could accomplish the task, but no luck.
I’m vexed. I can’t tell it it’s the firewall, hardware, or me.
And the Damned MegaGig OpenBeta Server… Wow - all I get is a Square White Box after the auto-login. Nothing. That’s an exercise in futility right there… I feel like Charlie Brown at Halloween. Tricked.
I am impartial in a sense - we use Microsoft Teams in the office! Other than that I have not done much screen share support since 1080p became mainstream. I think with friends I last used Skype mainly.
I have used Discord screen share once in the past week, but it’s limited to 720P and I was host so I didn’t see how it looked. Should be sufficient anyway!
I figured I would submit a summary of results should anyone else run across this:
DCS OpenBeta server operational on local machine with WebGUI for administration.
Settings configured in SavedGames\DCS.OpenBeta_Server\config with the following files:
serverSettings.lua - the main config file
nicknames.lua - configures the server’s player name.
autoexec.cfg - configures some runtime parameters such as disabling track files and automatically submitting error reports to ED.
Port forwarding confirmed valid at the router level and no local firewalls appeared to be setup to block access.
The problem sits at the ISP level as @whareagle‘s internet access comes from a microwave relay. His router is given a WAN address in the 100.64.X.X range which is actually a private range for ISPs to use for these types of relays - meaning the address isn’t “public” it’s the equivalent of 192.168.X.X or 10.X.X.X range addresses for your home LAN, just at the ISP level. His actual public IP ends up being in another range entirely, that is registered to his ISP.
The result is a two fold issue. The router can present NAT between LAN and the 10.64.X.X address, which DCS picks up and listens on. The DCS master server registers him on the list under his public IP - so we have a mismatch already. The other problem is that while his router can port forward from LAN to 10.64, we don’t know if from the 10.64 range to public is open or not, and I suspect not. Normal basic firewall setup would allow outbound connections, but not inbound which could be the problem as servers requires open connections for a client (player) to be able to initiate.
Before checking that out with the ISP, two things have to be covered:
-Check your WAN IP as stated by your router (which it may label as “public” as in it’s view, that is external)
-Check your actual public IP (you can google “what is my IP” for that)
That sounds standard - my ISP won’t offer a static address. Technically speaking, you don’t need a static IP.
Your IP should not change while the connection is active and the DHCP lease should renew perpetually. Loss of connectivity could cause a new lease and IP to appear - which would prevent your server from appearing in the DCS list, until you restart it (full exit of DCS server). That’s a trivial nuisance for $10 a month.
On fibre here my public IP changes at worst twice a year. Even after power outages I often retain my IP - and we are DHCP from the ISP as well.
That won’t solve the problem of ports not being open from the 10.64 to public range though (and that is still our best working theory) however it would be required to enact that otherwise every time your public IP changes you’d have to talk to tech support at the ISP to re-map them.
Just the same as you would have to remap it in your router if your computer’s LAN IP (192.168) address changed.
So while it may be a requisite, it’s not likely the full solution. Push for a technical answer because I’d not offer a dime unless the explanation is included.
As to my reference above about theory - we have no access or control to network devices beyond your router so we can’t know exactly where the block is but the evidence seems to suggest that’s the spot.
So the final result was that the ISP’s prior setup constituted carrier grade NAT. Wiki covers that and the exact issue we had here in their article:
So the issuance of a static IP address as described to @whareagle was in fact a static Public address, which was needed.
The final step was to remove the bind address from serverSettings.lua to allow the software to discover the public IP address automatically in the odd event it changes for some reason. Also one less property to manage & diagnose.
Tested complete and connected.
The only downside is we’ve contributed to IPv4 address exhaustion.