Problem with server browser

There is no firewall or blocking going on at the server. What build/version of the client do you have? If you have a client that is out of date, I believe the server browser will show up empty for you.

The fact that you are able to reach the forums to post here means that you do not have any network problems reaching our servers (or shouldn't) - the forums are hosted in the same network as the master server and homepage.

We do not block ICMP ping to any servers - everyone should be able to ping master.kag2d.com and kag2d.com, as well as others like kagforum.com and kagwiki.com.


Can you do the following?
1) ping master.kag2d.com and paste the results here
2) tracert master.kag2d.and post the results here.

I will keep an eye on this thread and work with you to find the solution to this problem if it is a network issue.
edit:
Once I have this information, I may want to meet with you on IRC to have you do some testing while I gather data in real time on the server side to see if your master server requests are making it to our network or not

 

Please provide the information I requested

 

Please ping it again, and try using the in game browser to list the servers. I am actively collecting data for your IP address.

 

Yes, this will not fix it - I am just gathering information on what the problem may be.

Please try the server browser one more time, I need to capture a bit more data.

 

Thanks. I am going to analyze the data and speak to MM/Geti.

I see your IP address communicating with the master server, however I see an oddity in the network traffic which I need to discuss with the developers. I will post back here when I have something to share.

 

Please try again now

 

It won't, but if by some change it does please post in this thread or create a new one.

For those interested, here's what the problem was:
The master server is one of a few things I have which sit behind NAT (for IPv4 - not for IPv6). The problem was that the server browser generates a few 1400B or larger responses (but probably less than 1500B), which is why other people have not had this problem. When I had you test yesterday, I was doing packet captures so I could look in detail at the network traffic. Part of what I saw was this:


This is a capture on the Internet-facing interface of the firewall/router that sits in front of the master server. What this shows is the egress UDP traffic, that is- the response back to you, is being fragmented. This means there's probably a MTU bottleneck between the server network and you, so I used tracepath to find the path MTU and sure enough on one of the last hops it gets bottled down to 1400B:
15: drs20.o56.ru (79.140.16.90) 185.639ms pmtu 1400

The problem is that the fragments shown above are leaving our network without the source address being rewritten correctly to 67.23.118.180, so your computer will reject them (if they even make it that far without getting filtered on the Internet because 192.168.152.3 is a private address).

I had to go into the pf config on the firewall and add "scrub in all" to tell it to capture and reassemble fragments before it performs NAT. Now it will properly buffer the fragments, perform NAT, and refragment as necessary to send the response traffic back to you.

Since this is a one-time change, it should not break again. This will fix the server browser for you and anyone else who sits behind a slightly smaller than normal MTU