This morning a webplayer that worked perfectly on friday is now broken. Good way to start the week :evil:.
Here’s my procedure: I deploy a webplayer on the Apache of my dev machine, then I run it in the editor as a server, and from another computer (in the same local network) as a client (in a browser).
This morning, my client still sees the server, but it has 3 IPs :shock:, and it won’t connect (NATTargetNotConnected, see screenshot).
It works the other way around though, if my client becomes the host: my dev machine only sees one IP, and connects without problem.
Now, the first of these IPs (192.168.1.10) is the one I usually see, the IP of the server in my local network.
The other 2 however (172.16.192.1 and 172.16.43.1), are not seen from my client machine.
The server sees them (well, he sees himself sort of), and redirects to .local, so I guess it’s totally internal, like a localhost 127.0.0.1.
After a few years of dealing with DSL boxes I came to consider these 172.x.x.x IPs as “fake” IPs, connection errors or such, but networking ain’t exactly my field of expertise…
Now, why it changed over the week-end I have no idea, so I’m inclined to blame Unity Technologies for it 8): did you guys change anything in the master server or facilitator or what-the-what?
No changes have been made to the master server nor facilitator.
NATTargetNotConnected means the target machine was not connected to the facilitator while attempting a NAT punchthrough. The IP addresses you mention are all private addresses so I suspect the problem here is that the master server has detected that the server and client are behind the same router, and thus gives the client the servers private IPs. However, when the client tries to connect he still tries NAT punchthrough, when he should not as the are private addresses. You could double check this by checking both server and client logs to see exactly what they were doing, how they interacted.
Btw, multiple IPs are only returned from the master server when he detects same-router internal connections between server and client. He then gives out all the internal IPs of the server which the client checks in turn. This is done internally when multiple IPs are given in the Connect function. Using all the server addresses is just a bullet proof way of using the right internal address (one of them must be the active one).
Ok, I think I understood all you’ve said, that’s a start !
I’ll study the logs, see if I can work out what happens.
BTW I’m using the unmodified networking demo: doesn’t the code detect if it should or shouldn’t do NAT punchthrough? What I mean is, is the demo already supposed to disable NAT in a local network, or should I code that myself?
Also, yes all 3 ips are private. The 192.168.x.x one is the correct one (what you call the “active one”?)
What I find surprising is the 172.x.x.x ones are “so private” that only the host sees it (itself), none of the other computers in the network can resolve it. Why would they show up? In that case, 127.0.0.1 should show up too, shouldn’t it?
!