Server doesn't handle multiple interfaces properly
Status: Pre-Alpha
Brought to you by:
darkschneider2
The situation is as follows :
Internet <---> Server <---> Client
(The server is running both the control server and the data server in this case.)
If the server is set to use the internet address, the client on the other side of the net will be able to connect, but the data server will fail to send data to it complaining about local error.
Setting the server up to use its internal ip instead will make it possible for the client to connect, but then it'll most likely cause problems for clients connecting to the other interface instead (I haven't tried that).
Logged In: YES
user_id=1576176
Originator: YES
Better setup description :
The LW servers are running on a computer with an external (internet) ip and an internal (lan) ip.
If the data server is set to using the external (internet) ip in lwserver.cfg, it is possible for a client on the lan to connect, but the data server will not be able to send data to it (regardless of whether the client is connecting to the servers lan ip or internet ip).
If the data server is set to using the internal (lan) ip in lwserver.cfg, it is possible for the client to connect and the server will be able to send data to it properly. However, then it'll (most likely) not be possible to use the server properly from internet.
Logged In: YES
user_id=1101616
Originator: NO
Okay, I think we will add a config entry like "public_address" to the dataserver.
So you can use localhost for the controlserver to connect and the public_address
will be distributed to the clients to connect to the dataserver.
Logged In: YES
user_id=1101616
Originator: NO
Okay it seems these are two different problems.
Your problem was a local client connecting to a dataserver that is listeing to the
external interface and complaining about not being able to send data to the
local client.
Logged In: YES
user_id=1101616
Originator: NO
I could not reproduce this issue.
I created a dataserver, listening on the external IP. I could connect to it
from localhost and another computer in the local network. And the dataserver
could send to the client.
Maybe it was a firewall issue?
Logged In: YES
user_id=1576176
Originator: YES
How very odd.
I tried it again, and this time it worked for me too (as long as I connected to the servers internal ip, trying the external ip still fails, which is the same as the behavior with teamspeak etc).
I'm going to try it again with a controlserver somewhere else on the net and the dataserver on my local server, to see if the problem still exists in some form (a local controlserver and a remote dataserver should also be tested).
My best guess as to why is that some other change in the code "accidentally" fixed it. Either that or someone fixed it and forgot to mention it, because I haven't changed the firewall settings since then.
Logged In: YES
user_id=1576176
Originator: YES
Hmm... this is weird...
I did some more testing, and it actually stopped working for a while for me again. Then it started to work again, regardless of whether I used the external or the internal ip on the server.
Logged In: YES
user_id=1576176
Originator: YES
A workaround that appears to be working every time :
1. Connect to the controlservers internal ip
2. Create a new room on the dataserver, but with the internal ip instead of the external one. (This is actually possible, I assume that the control server doesn't know about every interface the dataserver has.)
3. Set the codec to the same as the external version of the room, then continue as usual
Now, there are at least 2 ways of fixing this "properly" (and perhaps both should be considered) :
1. The dataserver lets the controlserver know which addresses it can listen to, making it possible for the client to select which it wants to connect to
2. Let the client do an address override for specific dataservers, letting it connect through the internal address without annoying the rest of the net by listing addresses that they won't be able to connect to