Recently I've set up a server with linux and have installed Pol 96.3 on it. My server is behind a router at the moment and I portforward the client correctly.
My problem, whenever Pol is running people can log in for a while. After a moment all clients lose connection and cannot log in again. When I check out the server Pol is still running, sometimes I can log in myself sometimes I can't. Note that this is on my local connection though I still try to connect thru the WAN-IP and not the LAN-IP.
When I shutdown Pol, start it back up again everyone can connect again. The problem -always- happends when im not connected to the local network with my laptop. I don't think there's a correlation but still its strange.
Thanks in advance
Issue with Pol 96.3 on a linux box.
-
innominabile
- Adept Poster
- Posts: 85
- Joined: Wed Aug 30, 2006 5:24 pm
-
Marilla
Here's something I've noticed which may or may not be of assistance to those using NAT routers. I haven't seen this mentioned much, but it's been a prevalent problem with my test servers until I hooked the appropriate packet(s) in 096+.
To help with connectivity through dynamic IP connections, many people use DynamicDNS systems, so that their servers.cfg file can have a static value in it instead of needing to be updated with the new IP each time the connection's IP changes. They figure this solves the problem. However, it does not.
The reason it does not is that it POL's login server always sends the IP address, not the host name that may be set in servers.cfg. But that's not all - it appears that POL loads the servers.cfg on startup, and gets the IP address for the hostname and caches it then, and then never seems to check that value again after that.
So even though you think you've solved the problem by putting a dynamic DNS host name in your servers.cfg file, POL seems only to read that value on startup. So, when the IP changes while the server it up, POL will still gleefully send along it's old, cached IP result.
So, people will connect and see the 'server list' fine, because the connection to the login server portion of POL is all based on the client's information, which will be dynamically checked each time the client connects. However, once connected to the POL login server, the POL login server will send it's 'cached' result for it's host name that it got on startup.
If you are connecting locally (behind the NAT), and have a separate servers.cfg entry for local connections, you'll never have a problem with that, of course. But attempting to connect to any servers.cfg entry that has a host name may fail when the IP address behind that host name changes.
--------------------------------------------------------
The fix for this not-quite-dynamic-DNS thing was to use packet hooks on the 'connect to server' packet that POL sends out, telling the client what the IP is of the server that the client selected. Then, one needs a dynamic DNS client written that, in addition to checking and updating the dynamic DNS info itself, must inform POL of the new IP, via an AUX or WWW script. The AUX or WWW script should save the bytes of the new IP in a global prop, and that global prop should be used to override the IP information sent to the client to connect to, if present.
When starting up the shard, this isn't needed, because right at startup, POL will resolve the host name in servers.cfg and get the correct, current IP. So the Global prop mentioned above can be a temporary one (prefixed with #). When the dynamic DNS client detects an IP change, it would call whatever AUX/WWW interface POL has to set the new IP (POL has no way of knowing what the IP of the NAT's outside interface is, so an external program must do this), and that script would set the temp global prop, which would let the hook know that instead of passing the server info straight through, it must alter it.
----------------------------
I have an 096 WWW script that handles setting the global prop, a hook for the connect to server packet, and a C# dynamic DNS client which includes code to notify a local (LAN) POL server of such a change; If anyone else has issues with this with a test server that they need people to connect to from outside (or if they have a smaller production server that just happens to be on a dynamic IP setup, too), I could probably produce a separate 'drop-in' package for the WWW and hook scripts, and provide a .NET executeable that can use app.config to let someone enter their own server info, where to check the IP from (I use my own web server to detect current IP, which is not an option for anyone else to use... but there are plenty of public sites you can call pages on to get your current IP)... So, if there is interest in this, I'll provide something for folks!
To help with connectivity through dynamic IP connections, many people use DynamicDNS systems, so that their servers.cfg file can have a static value in it instead of needing to be updated with the new IP each time the connection's IP changes. They figure this solves the problem. However, it does not.
The reason it does not is that it POL's login server always sends the IP address, not the host name that may be set in servers.cfg. But that's not all - it appears that POL loads the servers.cfg on startup, and gets the IP address for the hostname and caches it then, and then never seems to check that value again after that.
So even though you think you've solved the problem by putting a dynamic DNS host name in your servers.cfg file, POL seems only to read that value on startup. So, when the IP changes while the server it up, POL will still gleefully send along it's old, cached IP result.
So, people will connect and see the 'server list' fine, because the connection to the login server portion of POL is all based on the client's information, which will be dynamically checked each time the client connects. However, once connected to the POL login server, the POL login server will send it's 'cached' result for it's host name that it got on startup.
If you are connecting locally (behind the NAT), and have a separate servers.cfg entry for local connections, you'll never have a problem with that, of course. But attempting to connect to any servers.cfg entry that has a host name may fail when the IP address behind that host name changes.
--------------------------------------------------------
The fix for this not-quite-dynamic-DNS thing was to use packet hooks on the 'connect to server' packet that POL sends out, telling the client what the IP is of the server that the client selected. Then, one needs a dynamic DNS client written that, in addition to checking and updating the dynamic DNS info itself, must inform POL of the new IP, via an AUX or WWW script. The AUX or WWW script should save the bytes of the new IP in a global prop, and that global prop should be used to override the IP information sent to the client to connect to, if present.
When starting up the shard, this isn't needed, because right at startup, POL will resolve the host name in servers.cfg and get the correct, current IP. So the Global prop mentioned above can be a temporary one (prefixed with #). When the dynamic DNS client detects an IP change, it would call whatever AUX/WWW interface POL has to set the new IP (POL has no way of knowing what the IP of the NAT's outside interface is, so an external program must do this), and that script would set the temp global prop, which would let the hook know that instead of passing the server info straight through, it must alter it.
----------------------------
I have an 096 WWW script that handles setting the global prop, a hook for the connect to server packet, and a C# dynamic DNS client which includes code to notify a local (LAN) POL server of such a change; If anyone else has issues with this with a test server that they need people to connect to from outside (or if they have a smaller production server that just happens to be on a dynamic IP setup, too), I could probably produce a separate 'drop-in' package for the WWW and hook scripts, and provide a .NET executeable that can use app.config to let someone enter their own server info, where to check the IP from (I use my own web server to detect current IP, which is not an option for anyone else to use... but there are plenty of public sites you can call pages on to get your current IP)... So, if there is interest in this, I'll provide something for folks!