Network.player and its IPs

Hi,

Since 2.0.2 (I think, can't really recall ) we have Network.player, which is a NetworkPlayer, that has all the local player's info.

NetworkPlayer now has, besides ipAddress and port, externalIP and externalPort, which is great. I only have two problems with it.

First, when we print externalIP, it appears reversed! For example, 10.20.30.40 will appear as 40.30.20.10.

And second, for some reason (maybe someone can explain it to me), I get different values if I have the port blocked or not in the server. Let me explain all the way.
If I initialize the server with Network.useNat it will fill out the externalIP and externalPort by going to the facilitator, which is great and just as I thought.

But if the port that I use for the server is blocked in the router, I get in the externalIP my real IP (although, like I said, if I print it, it will be reversed), and if I open the port in the router so others can communicate with the server, the externalIP will be set with my LAN IP (e.g. 2.1.168.192, since it is printed in reverse). Since it goes to the facilitator both times, shouldn't it have always my "real" external IP?

Also, if the server hasn't contacted the facilitator yet, the externalIP and externalPort don't have always the same values. It would be good if this happened, that way we could find out if it had already contacted the facilitator (or have a OnConnectedToFacilitator).

Regards,
Afonso

 

Most of the times the IP is either 0x0(0) or 0xF(F), but sometimes it is not. And the port number if also inconsistent. For example, just tried to create the server and the IP is 0x0(0) but the port is 80. Is there a possibility that it is in the middle of updating the IP/Port while I do the print (i.e. not thread safe)?

As for the IP being the external/internal, I'll have to check again once I get home, because at the university I'm always getting the correct external IP.

But at home, I'm not blocking outgoing traffic, I'm only blocking incoming traffic. If I create a server with the port blocked (i.e., the clients cannot connect), I get the correct external IP. However, if I unblock the incoming port, which will then let the users connect to me, the external IP has the LAN IP, not the my real external IP.

I'll check again at home, maybe it's something about my modem. Since at the university I don't get this inconsistency, either the incoming ports are blocked here (I know outgoing aren't), or something is wrong with my modem/router at home.

 

I just tested with my dsl modem/router and I just found out that there are two ways to open ports.

First, which I always used (in the modem they call it "Applications", and they say that it is "Special Application is used to run applications that require multiple connections."), we just define a trigger port, which, after receiving a connection to it, will open a public port so people can access it. At least that's how I think it works! And it has been working, for example, that's how I open the ports so that I can be a server in blizzard's battle.net.

If I use this approach, whenever I create a server, it contacts the facilitator but the externalIP will have the internal IP. I don't know if this is a limitation of the network package you are using, but I it sounds like a bug to me.



Second, which is a approach that I particularly don't like (they call it Virtual Server, and say that it is "Virtual Server is used to allow Internet users access to LAN services."), although I think it might be a most used, is that we define the external port, define the internal IP and the internal port to which the connection will be forwarded. I don't like it because it locks to a specific internal IP, but it makes sense for a "real world servers".

With this approach, whenever I create a server, it contacts the facilitator and the externalIP will be mapped with my real external IP.

Has any of this info helped?

 

Well, I guess I just don't have any luck with routers.... I have a new router that I can't get it to work with Unity Network.

I create the server and it creates a game in the master server and connects to the facilitator.

In the router, I created a new "application" that has the port open (tried with both TCP+UDP and just UDP), and I connect my desktop to that application.

This router configuration works with other games, like Warcraft III, but it doesn't work with Unity games, the clients all get the message "couldn't connect to the game through the facilitator".

Are these known issues? The routers were both Thompsons, a speedtouch 546 and a wireless TG858.

Larus, if you need any more info let me know.

Regards,
Afonso

 

I have seen this issue as well, however I don't have the hardware info. At home my apps work fine through the facilitator, but at my university office I get the "Cannot connect through facilitator ...." error.

 

This is a DMZ issue. Port forwarding is blocked at the second firewall.

 

I don't have any firewalls I disconnected the ones from the router and also I don't have mac's firewall running.

 

I can try to make a bug report, but the problem is that you'd need to have these routers to test.

As for what I'm doing, when everyone starts the game I test the connection with the conn tester and determine if they have Nat access and set that. With the person i'm trying it with, we both get NAT to true.

Then, when the player wants to create a server it sets NAT to !HasPublicAddress() and then create the game and register it on master server.

The client gets a lists of game, and the client sets NAT according to the info from the NAT field on the HostData.

Am I doing things correctly?

What I saw from the tests I did was that if I had the server set to useNAT = false the clients always get "Couldn't connect to server", and if I set useNAT = true the clients always get "Couldn't connect through the facilitator", independently of the useNAT that the client had. I tested this by adding a button that enabled / disable NAT.

 

If someone is getting problems with routers please read on.

Larus helped me and was able to determine that my router uses something called symmetric NAT ( http://en.wikipedia.org/wiki/Network_address_translation#Different_types_of_NAT) that, if I understand correctly, every time I send a udp packet it will map on a different port on the router, and so the facilitator doesn't know how to make a client connect to my server because it sends him to a different port.

At the moment, Unity (2.1) doesn't have support for symmetric NAT.

To workaround this problem, you can open the ports from your router, and if you do so then turn off NAT on your server.

If someone has routers like the Thomsons I mentioned (546 and TG585), whenever opening up ports always open TCP and UDP. Although Unity only uses UDP, it seems that these routers have a bug in which only if you open both TCP and UDP will the ports be forwarded correctly.

Regards,
Afonso