Private Hive Server - Will Not Appear in Steam Browser

[rn_max 202]

I've been configuring my DayZ Mod private hive sandbox server to use the dev branch of ArmA 2 OA (a.k.a. the "new" beta).

ArmA 2 OA 1.63.124879
DayZ Mod 1.8.1
Pwnoz0r Server Pack 2.6.0 (DayZ 1.8.1)

I'm banging my head on the keyboard with this chestnut.  My build works just fine with beta expansion 1.63.116523, appearing on LAN and reporting through GameSpy to appear on the internet.  However, I can't get any joy with the Address:Steam tab of the server browser in that version, or with the Steam master server browser in the Steam client (which blows goats).

 

When I switch to ArmA 2 OA 1.63.124879, the new dev branch (instead of the "obsolete" beta expansion) my build appears on LAN, but not in the Adddress: Internet (Steam only) browser tab at all.  Of course, GameSpy is removed from that version.

 

The snippets of fragmented information available on the various forums is not helping matters.  it is small wonder that there are only 19 servers listed so far on Steam in game out of the thousands running.  Neither does it help that the Steam server browser system leaves a lot to be desired.

 

One useful tool I did find, was this Steam API page that checks for server response, from which the plot thickens:

http://api.steampowered.com/ISteamApps/GetServersAtAddress/v0001?addr= [your server ip address here]

 

 

 

{ "response": { "success": true, "servers": [ { "addr": "xxx.xxx.xxx.xxx:27016", "gmsindex": 65534, "appid": 33930, "gamedir": "arma2arrowpc", "region": -1, "secure": false, "lan": false, "gameport": 2302, "specport": 0 } ] } }

 

 

 

My server is responding to the check, so why isn't it appearing in the Steam server list?  Good fecking question.  Inbound and outbound firewall ports are open, the server process has been tried on two separate machines, with and without Steam running, launched as a Steam app and as a Windows program.

 

All I know is that using the 116523 beta expansion my server build appears on the internet via GameSpy and using the 124879 dev branch it does not appear on the internet via Steam.

 

A week of trial-and-error from ineffective fragments of conflicting suggestions has worn my patience rather thin.

[kichilron 8550]

Did you add the Steamquery ports to the server.cfg?

[rn_max 202]

Yes kichi,

 

steamport 8766 and steamqueryport 27016.

 

UDP 2300-2305, 8766, 27000-27030 opened inbound with edge traversal and opened outbound in the firewall rules.

 

The API page is still returning a checked response.  TCP-UDP Endpoint Viewer is showing sent and received traffic on 2302 and 8766

 

 

Time for bed, maybe some random inspiration will strike tomorrow.

Edited June 16, 2014 by RN_Max

[rn_max 202]

Well, it appears that the Steam based server browser system is even more of a throwback than I anticipated.  This evening has been an exercise in regressive time travel.  I didn't bump into Charlton Heston, Racquel Welch or any large stop-motion lizards, but I'm could have sworn I passed a certain Mr Berners-Lee with a new discovery at one point.

 

 

The simple change from GameSpy to Steam server communication appears to have come at the expense of uPnP port management, which could be from the loss of the reporting address mechanism, acting as a fixed network tether for servers reporting through router firewalls.

 

It could also be the primitive nature of the Steam server communication ... and perhaps the fact that this change is, for now at least, a kludge band-aid solution on ArmA 3 ports.

 

I had to add every required port to my router by manual forwarding, including those normally traversed automatically to communicate with GameSpy.  Plus some other "This software is too primitive to manage ports" tweaks.

 

Now I can go about the rest of my server twiddling and tweaking, safe in the knwoledge there is no magic feather ... just a ropey internet server communication solution from the distant past.

Edited June 17, 2014 by RN_Max

[rn_max 202]

Whilst sorting out this bundle of string scraps, I used Sysinternals TCPView, a network TCP-UDP endpoint viewer and invaluable tool for network monitoring.

 

Once I had my server up and running online, I had another look at the connections and traffic.  In addition to the server UDP ports, I noticed the local TCP ports between MySQL and the server process, connecting the hive.

 

Underneath the hive ports, almost unnoticed, was another TCP connection on a similar 49000 range port ... but this was connected to an external IP.  Now that was strange, because I had no outbound TCP ports mapped.

 

 

ARMA2OASERVER.exe    5012    TCP    [*local host*]    49974    221.228.193.179    27017    ESTABLISHED    89    7,740    14    3,000

              

 

My first thought was to kill the connection and see what happened, after copying the details of course.  It re-established itself, four times, so I shut down the server, which severed it.

 

One tracert and whois later, it appears my unannounced visit was from a residential connection on the CHINANET jiangsu province network.  Curious.  Now that connection may actually have been benign, but I have no idea at first glance and am not happy about having to punch holes in my firewall with a brick anyway.

 

 

Just my two penn'th ... the requirement to have the equivalent of a door wedge permanently jammed in a sophisticated network security device, just to connect a game server to the outside world, stopped being an acceptable measure years ago.

 

Brute force port management and deliberate leakage by edge traversal may overcome bad network communication design, but there is no real excuse for having to resort to it in the first place.  All very unnecessary in this uPnP compliant day and age.

 

GameSpy is better than most people ever gave it credit for, even when it has been reduced to an unmaintained walking corpse.

 

[TG ! Jimmy 216]

...

 

Just my two penn'th ... the requirement to have the equivalent of a door wedge permanently jammed in a sophisticated network security device, just to connect a game server to the outside world, stopped being an acceptable measure years ago.

 

Brute force port management and deliberate leakage by edge traversal may overcome bad network communication design, but there is no real excuse for having to resort to it in the first place.  All very unnecessary in this uPnP compliant day and age..

 

 

Couldn't have said it any better.  It is entirely asinine; we are being forced to throw security out the window to allow people to simply find the game server.  It's about a step and a half better than forcing clients to bring their PC's to my server room and plug into a rusty old 10baseT hub if they care to game at all.

 

Cheers,

Jimmy

Edited June 23, 2014 by TG ! Jimmy