We're running a vanilla/test server on "vanilla.cube-nation.de" which is a DNS SRV record pointing to "cube-nation.de:22296" internally.
Using the later one still works fine while using the SRV record stopped working since out update to the pre-release today. The server added to the client is shown as "offline" and connecting to it times out after a while.
So there seems to be some issue/bug here.
Hope you can still fix this for the official release, since that would break a lot of "multi server" concepts.
Regards
DerFlash/Björn
Attachments
Comments 5
Interesting, you're right (but not completely g).
I think you've found some hint for the issue itself here.
You're right with the fact that the server is (actually) working. It seems to be because I've removed the iptables rule preventing access to the port directly from outside. This is to prevent people from even knowing that the server is running on this port. So they just know that its running at vanilla.cube-nation.de. This worked fine with all versions for now and is how SRV records should be used.
But somehow the 1.6 seems to use the redirection address for further communication instead of still the SRV record, so the connection will timeout/disconnect as soon as the iptables rule for direct access is in place.
So to sum it up:
if you've access to both (vanilla.cube-nation.de + cube-nation.de:22296) it works although the client should never use later address since I've given him the first one
if you're blocking the direct access to cube-nation.de:22296, the SRV record vanilla.cube-nation.de pointing to this address stops working
PS: As you may notice, the iptables rule is in place again. Feel free to check again - server should not "really" respond anymore.
Hope that may help to find the exact problem here.
Connect to vanilla.cube-nation.de and cube-nation.de:22296 works.
Wrote that in the chat & left message @ 204 / 72 / 109
Client>
Client> 2013-06-27 00:25:07 [CLIENT] [SEVERE] Realms: Invalid session id
Client> 2013-06-27 00:25:53 [CLIENT] [INFO] Connecting to cube-nation.de, 22296
Client> Setting up custom skins
Client> 2013-06-27 00:26:13 [CLIENT] [INFO] [CHAT] <Kumasasa> connected to cube-nation.de:22296
Client> 2013-06-27 00:26:21 [CLIENT] [SEVERE] Reached end of stream for cube-nation.de/176.9.22.143
Client> 2013-06-27 00:26:40 [CLIENT] [INFO] Connecting to cube-nation.de., 22296
Client> Setting up custom skins
Client> 2013-06-27 00:26:48 [CLIENT] [INFO] [CHAT] <Kumasasa> connected to vanilla.cube-nation.de
Client> 2013-06-27 00:27:01 [CLIENT] [SEVERE] Reached end of stream for cube-nation.de./176.9.22.143
Client> 2013-06-27 00:27:02 [CLIENT] [INFO] Stopping!
Client>Hmm... I did some more digging into how SRV records work. It really seems to be my own fault at the end! Ticket can stay closed and I apologize for the confusion 😉
Just as a little explain what happened:
Setting up and using an SRV record indeed tells the client to use the real address behind the record. Blocking this would result in the described error.
What I mixed up here was the need to block this "internal" port. This is NOT needed when you're not using a proxy (which is doing the authentication, while the server itself then would need to run in offline mode).
Regards
DerFlash
Cannot confirm. Server works.