Some other ideas for solutions have occurred to me...
First some background for those who care about such things.
MapTool has a problem when starting up a server, since it cannot know which IP address to listen on. A single machine could have multiple wired network interfaces, multiple wireless networks, and other "unusual" network interfaces as well. The approach that MapTool used to take is to simply bind port 51234 (by default) to which network interface the operating system wanted to provide.
That technique has problems, since the choice could easily be wrong. Phergus documented an webcam that creates a NIC (network interface card) and gives itself IP address 0.1.0.4 (!) and it's possible for MapTool to try to use it. That's obviously going to be meaningless.
The technique added in 1.3.b50 (I think it was b50) is for MapTool to open a UDP socket to "www.rptools.net". The socket connection will fail (since there is no server at www.rptools.net
), but success or failure doesn't matter -- MapTool can now query the IP address used on the local machine in order to make the outbound request and it know which IP address to bind to!
Hamachi and other software VPN solutions (or any peer-to-peer tunneling application) will create a new NIC. When MapTool uses the above test to obtain an IP address, it won't be the IP address that corresponds to the VPN NIC. So the MapTool server will end up listening on an IP address other than the one the VPN is using, preventing other players from connecting.
There are multiple solutions. The first is to back out the new test added in b50 and go back to the old way of letting the OS choose. The user simply needs to be sure that the interfaces are specified in the correct order so that OS chooses the one MapTool needs. This is fine in theory, but can users be expected to know that? (Heck, I'm not sure I know how to do that on my Mac and I've been running OSX for 18 months now.)
Another solution would be to allow the user to specify which host should be used for the test connection. It could default to www.rptools.net
and the user could fill in a different IP address or hostname, if desired. This would require a message to the user describing how to choose such an address -- likely not something that could be explained in a single sentence or two. Or, allow the user to simply input the IP address they want MapTool to bind to. This also requires that the user know what they're doing and is likely too techie for most people.
Another solution would be to replace the default route
of the user's primary NIC with one that routes packets over the VPN NIC. It doesn't matter that the packet delivery doesn't work, since MapTool doesn't use it anyway. However, changing the default route means that other applications (web browser, etc) would not longer be able to access the Internet, so after starting the MapTool server, the default route would ave to be set back to its original value. This is unacceptable, IMO.
The only practical solution I can see at this point is to reverse out this patch and put the old code back in until a better solution can be found. I'm going to contact Trevor about it. In the mean time, if anyone else has additional thoughts on the issue, I'd love to hear them.