Troubles with Seeing Server
Hi guys, I use to run a dedicated server called Devastation. I ran it for years before T2 slowly died. I remember 1500 servers running at one point. Anyway, I ran it on a homebuilt server running Windows 2000 Pro, yes its been a while. I cant get any updates needless to say, so I copied all of my tribes files onto a newer computer running Windows Vista. LOL yes newer is a relative term. I got the ispawn.exe file to run, it looks like it loads all of the files correctly and even gets a confirmed heartbeat. The trouble is, it doesnt show up on the server lists. I know that its probably a firewall. My set up is as follows, comcast cable comes into the house, goes directly to a linksys switch, then goes up to the Comcast router from which the "newer" server has access to the internet. I have ESET mart Security on all my comps, and Comcast has its own firewall. Ive disabled both firewalls and th windows firewall but it does not help. ANy suggestions or help would be appreciated. Thanks in advance.
Zamo
Zamo
Comments
http://www.howtogeek.com/howto/uncategorized/how-to-create-exceptions-in-windows-vista-firewall/
It looks like the master endpoint tries to send multiple responses at once, even if they conflict or are just repeats. On my own network I have it telling me all in one response that my server can't be reached, the heartbeat was confirmed and the server was added to the list so I'm left wondering how the heartbeat can be confirmed if my server can't be reached, especially considering that the end result is the server not being listed:
That is what happens when I have my Tribes 2 server behind a routing box that is masquerading the incoming connections. This also causes the MITM check to fail when people try to join (via direct IP since the server isn't listed) and crash clients because of the way masquerading works and the fact that Tribes 2 has a crash bug related to dialogs being displayed too quickly. So even if the server showed up correctly under this situation, nobody can join.
(In the \r\n\r\n1\r\n2\r\n0\r\n\r\n you see 1,2,0 appearing in that order for the endpoint response codes)
When I rework my network to not use the masquerading and purposely make the server not reachable, I get just the server can't be reached and the server was added to the list responses, and the "Server can't be reached" response is duplicated twice.
(In the \r\n\r\n1\r\n1\r\n0\r\n\r\n you see 1,1,0 appearing in that order for the endpoint response codes)
When I setup the non-masquerading network correctly, I get the same exact endpoint response as I did under the masquerading configuration but the server is actually listed correctly.
To test the masquerading setup to be absolutely sure that the server is actually reachable, I've also setup a simple local UDP server on the machines that normally would be running the game and they are indeed receiving UDP data from the TribesNext master server probing for a live game server. Just instead of it receiving from the TribesNext server prober, it receives from my masquerading router box. The inconsistent reporting behavior is at the least pretty confusing and makes it quite a ways harder to debug and both the MITM checks & server list not working correctly on networks that might be "masqueraded" is causing headaches for people that end up in these situations.
However, given the original poster's setup above the only relation this may have to the issue at hand is that the router isn't actually forwarding but masquerading (hence why I asked to see what happens if he has someone connect directly).
What you're describing sounds like an internal networking issue wherein you cannot query the external address from within your network. To get around this, you can simply hit your "Insert" key and manually type in the LAN address of your server to have it attempt to query -- and if successful, mark that server as a favourite in your list. You can also attempt to query it by opening your console (~) and typing queryLANServers(28000);
The leading and trailing lines in DX's post are chunked encoding indicators, which should be ignored, and aren't related to any operations the master server is performing; they're simply used for transaction handling and shouldn't be in use by the game code. The actual state enums in use are in the middle in those quoted responses, and indicate in the first that the heartbeat was accepted, and the second that either no response was received in time, or that it was incorrect in some way. In any case, Zamo's server did respond to the queries, and was added to the list without issue, so while it is an effect of the networking configuration, it's not related to the external visibility.