Launchers Not Obtaining A Complete List of Servers
Some users report that when they refresh the master server list, they only see a handful of servers or that some servers are not fully responding. The purpose of this bug is to find a trend that might lead us to figuring out if there is a specific reason this is happening. Please provide informative detail that might give us a lead into figuring out the problem!
Who is your ISP?
Do you use WIFI or a wired connection?
If WIFI, approximately how far are you from the router?
What background programs are running that could effect incoming packets?
Are you using a firewall?
What launchers have you tested this with? Do any work better than others? Do any give some kind of debugging info in the log?
What master(s) are you using?
One other helpful bit of info that could be provided is a trace of the route from the player to the server. With Windows, this can be done from the command-line with:
With my previous ISP, none of the NJ FunCrusher+ servers would respond to my queries from Odamex Launcher. My route to the FunCrusher+ servers went from California to the UK before going to New Jersey, which is odd to say the least.
My current suspicion for this issue is that current launcher query response packets from servers are very large (over 1500 bytes) and the packets get dropped somewhere between the server and the client's launcher. Reducing the number of cvars that are sent in a launcher query response will help some as will making sure cvars such as sv_motd, sv_hostname, sv_email, and sv_website are as short as possible. The query response packets should be under 1500 bytes to ensure most everyone can receive the response.
In the future, this problem should be handled more robustly by implementing a packet fragmenting scheme in Odamex, which will split packets into multiple parts if they are larger than a certain size.
I've got 5 servers (184.108.40.206:10666-10670) and the launcher was consistently not showing the second one.
I went and did some experimenting by changing the sv_motd length and found it *only* breaks when the response length falls in a specific range.
I've done 3 captures in Wireshark, two are either side of the problem range with 9/16 char long sv_motds, and one with a 15 char sv_motd which doesn't work.
I'm not entirely certain this is a network-side problem, since the 2 successful attempts here actually ended up fragmented anyway.