RPTools.net

Hi to all,
i'm trying to figure out how to start a server while i'm in my home network.
My ISP provider id Fastweb, an italian ISP.
They give me a NAT connection, and my ip address is invisible from the outside.
I always used Hamachi to get rid of this problem, but with MapTool it seems that the old good Hamachi can't save me.
I moved Hamachi as the first network adapter in the list, but MapTool still takes the LAN adapter by default... i dunno why.

Is there a way to make my MapTool server work?

thank you in advance

Welcome to RPTools, Mephiston!


Oh, I know why.

There is some code in MapTool that attempts to create a route to www.rptools.net (which then fails) but the adapter that the OS chooses to make that route is the one MapTool uses for starting the server. This prevents MapTool from having to guess which adapter to route over.

It sounds like we're going to need a patch for this, Trevor, before 1.3 freezes. The only quick solution I can see is to allow the user to specify which IP address they want to use for the test, with www.rptools.net being the default. With a Hamachi setup, the user would enter the IP address of the other host. We need a better way to handle this, though.


It might not be possible. Is there a way to leave Hamachi enabled but somehow tell the OS not to use the network adapter?

If there isn't, the only choice I can see is to add a default route through the hamachi interface, start MapTool, then remove that default route.

Are there any other hamachi users out there that are having problems? This really should be an issue for anyone using any kind of VPN software...

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.

Can we have a drop-down of IPs in the Start Server screen?

Can we listen to all of them?

IMarv

yes, this is what i had in mind...
otherwise it could be a good idea to let the user select the method:
1. auto-select IP address
2. type in your ip address

that should be fair enough

Given the large number of problems people have had with the most recent builds I would say pulling/disabling that code is a good idea for now.

As for what IP address to bind to, why not just present a list of interfaces for the user to choose from:

http://java.sun.com/docs/books/tutorial ... eving.html

Already done.


Yeah, I've got some code now that enumerates the available interfaces. But this whole thing is only a problem for people using some type of VPN or tunneling software. So where should the dropdown box go? I hesitate to put it right smack on the Start Server dialog or it'll blow away people who don't know what to select. Although I suppose the first (and default) entry could be "Let MapTool choose..."

yes Azhrei,
i think that "Let MapTool choose..." must be the first and default choice.

I have to say that after the reboot of my pc, MapTools is working...
I'm able to start a server using hamachi.

I'm assuming that the reboot allowed the OS to correctly order the NICs as i setted.

At the moment i'm waiting for players to test the connection. I'll keep you update

Wow, yes -- please do!

For it to all of a sudden start working, makes me wonder whether the new approach was really the problem? Especially since we haven't been hearing from other people using VPN software about having problems running a server.

TO ANY AND ALL USING HAMACHI: Please post here if you are using Hamachi or some other VPN/tunneling software and report whether you've had any issues running a server and players connecting. And if so, did a reboot fix the problem?

Ok, i played last night without problems.
I think the reboot fixed the problem.
Since my last reboot i'm able to open Map Tools and start a server when i want.
The palyers enjoyed our last session

All seems to be ok, thank you very much for the support!

Ok, I think I'm using VNP/Tunneling. Here's my story:

1.3b53
-I start a server and click the usually trustworthy "Test Conection" button. I get the positive "Success! I could..." reply.
-My friend tries to connect and gets the "Could not load campain." dialogue.
-I open another instance of Maptool, try to connect, and get the same "Could not load campain."
-Using my 2nd instance of Maptool I try the direct connect via external address. It fails.
-Using my 2nd instance of Maptool I try the direct connect via local address. Success!

My home network is a little excentric. I'm running Windows XP on my PC.

The internet comes into house to the Cable modem, then goes to the Hub, then goes to a Mac (running OS-X v10.4.11) which has "internet sharing" enabled. Then it goes back to the Hub and over to my computer.

This setup requires that I open up Port 51234 on the Mac's firewall for the "Test Conection" button to give me a positive responce.

To test to make sure it wasn't just my computer causing problems I removed the Mac from the network so that it was just:
Cable Modem -> Hub -> My PC
This works!

Back to the original setup. I tried restarting my PC, this does not solve the problem. File Sharing is enabled on the Mac (I read somewhere that was causing people problems).

My server is still running; It's called "notWorking" incase anyone wants to try connecting. I'll unfortunately be flying to a different city tomorrow, so today is the only day I can run tests. I'll try and be responsive today at least incase anyone has questions/suggestions.

Yarg, I just tried connecting and got the "could not load campaign" response. I'm not sure I have any suggestions, though. If I understand right, the Mac is acting as your router?

If so, and you've opened up port 51234, have you doublechecked that the IP address your computer (the one that will run the MT Server) has is the one that 51234 is forwarding to?

The reason I asked is that I had the "can't load campaign" error last weekend, and it turned out that while the port was open, and I got "I can see your computer!", the internal IP was wrong - I had port forwarding configured to direct Maptool traffic to 192.168.1.5, and my computer had recently refreshed it's IP and was talking on 192.168.1.3.

Thanks for testing it Rumble.

What I did was create an exeption for the firewall on the Mac for port 51234. As far as I know this just meens it allows all traffic through this port (I could certainly be wrong about this). Prior to creating this exception the "test connection" would fail.

If this is directing Maptool trafic to the wrong internal IP, I'm not sure how to test for it.

Oh, apparently there's a Window's File sharing option on the Mac. I've now enabled this, but I still can't connect to my own server.

Connecting in this way is not likely to work and isn't intended to be used for local connections. There you should use the LAN tab or the Direct tab with your local IP.



So your PC is fine.

Test Connection was also working fine when connected through your Mac. So it sounds like you had the Mac correctly configured. I would recommend either dropping back to b50 or moving up to b54. There was some network code put in that has since been removed (as of b54 IIRC) that may be affecting you.

If you are still having problems, post what your Mac thinks its IP and default Gateway is. What Windows thinks your IP and default gatway is and finally what MapTool reports as your Local & External IP addresses are.

I don't know much about how the firewall works on OSX in relation to the GUI Preferences panel. I do know that the underlying software allows incoming and outgoing ports to be filtered separately and I know that packets coming into the machine are routed through a "forwarding" layer and then back out, so there are three levels of filtering (input, forward, output) and all three must be properly configured, but I don't know the details of what the "Internet Connection Sharing" actually does.

It would be unusual for a home user to have two computers connected to a hub and use connection sharing on one of them. Since both are connected to the hub, both can reach the outside world directly. In fact, Linux systems will actually report a bogus routing table entry if you ping a machine on the same physical network when the packet is routed through another machine on that same network. (Essentially, it's reporting a misconfigured LAN.)

I'm also wondering if you really meant "router" when you wrote "hub", and when you said the connection came into the Mac and then back to the hub and to the PC, that doesn't make a lot of sense (two wires from the hub to the Mac?!) so I mostly ignored that part.