@Josh: I think you absolutely forget that some things may just be rare instead of practically usable and therefore SHOULD be expensive! And for not being able to repair some enchanted swords: where's the fun or competition(SMP) when every user will have nearly unlimited "really good swords"?
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.
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).
Björn
MC-19132
We can confirm this bug. It seems that sometimes it repairs, sometimes it doesn't.
@Josh: I think you absolutely forget that some things may just be rare instead of practically usable and therefore SHOULD be expensive! And for not being able to repair some enchanted swords: where's the fun or competition(SMP) when every user will have nearly unlimited "really good swords"?
dublicates https://mojang.atlassian.net/browse/MC-1580
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:
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.
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
Same here on OS X 10.8.4 in both, window mode and fullscreen.
May be related to
MC-22033Thanks for the hint. It's still a concern, versions updated.
Replacing the LWJGL libs didn't work for me.