Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008409opensim[GRID] Robust Serverpublic2018-11-14 12:032018-11-15 10:48
ReporterFerd Frederix 
Assigned ToFerd Frederix 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionwon't fix 
PlatformgatekeeperOSWimdowsOS Version32/64
Product Version0.9.0.1 
Target VersionFixed in Version 
Summary0008409: Failure to verify (foreign grid versus 127.0.0.1)
DescriptionMany home routers (approx 2/3'rds in my experience) do not hairpin Opensim traffic. This is a well known-issue. One simple solution that works on all three client platforms is to edit the etc/hosts file to point the DNS name to localhost (127.0.0.1). This fixes it, but the user must run the viewer on the server. No other LAN PC's can connect. This is expected behavior.

However, there is a problem with using the same viewer to log into a remote grid, such as osGrid. Once you are at the remote grid, any attempt to teleport to your local grid will fail. This should be allowed. It is common for people to want to meet and share goods with their other avatars.

It appears that the Gatekeeper is incorrectly comparing using the DNS name of 127.0.0.1 instead of the actual DNS. This may be coming froma reverse DNS lookup somewhere at the local grid. See log file below.
Steps To Reproduceedit /etc/hosts on your server
add an entry for your grid name and localhost such as my example:

127.0.0.1<tab>www.outworldz.com

Save it.
This takes effect immediately.
Log into OsGrid or any foreign grid.
Try to teleport to your grid
Additional Information
13:06:40 - [REMOTE SIMULATION CONNECTOR]: Creating agent at http://[Proper [^] DDNS name]/
13:06:40 - [GATEKEEPER SERVICE]: Login presence XXXX YYYY is ok
13:06:40 - [USER AGENT SERVICE]: Gatekeeper sees me as 127.0.0.1
13:06:41 - [USER AGENT SERVICE]: Verifying Client session a1c38a94-e229-437f-95d6-1ef8ba074c31 with reported IP (Proper External IP).
13:06:41 - [USER AGENT SERVICE]: Comparing (Proper External IP) with login IP 192.168.1.1 and MyIP 192.168.1.1; result is False
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Environment.NET / Windows64
Mono VersionNone
Viewer
Attached Files

- Relationships
related to 0007405closedMata Hari Unable to HGTP home to a self-hosted region 

-  Notes
(0033495)
BillBlight (developer)
2018-11-14 12:22

First off this is a two fold issue, the viewer would have to determine your real ip to pass it to the server, instead of the server just looking at where you are coming from.

Second this is an issue that does not just affect opensimulator and companies with millions of dollars have not been able to fix it, because, "this is just the way networking works"

Hosting public game servers on the internet has always suffered from this issue, but for most it is not an issue because you never leave your own server as we do on Opensimulator to go to others worlds.

Without a central hub to register your worlds to (such as HiFidelity uses) there is no central place for everyone to already know your public IP.

A server on the web is never going to be able to talk to you inside your network on 127.0.0.1 .

To establish a connection to you it has to come from the outside on a public address and without that two way communication cannot be established.

It sucks, but it is the way it works, this is and example of poor router design and an attempt to fix cheap or wrongly configured hardware with a software fix.

Better idea is to educate users on how to actually setup a network and buy proper hardware if they intend to host a "home server".
(0033496)
Ferd Frederix (reporter)
2018-11-14 13:24
edited on: 2018-11-14 13:37

The remote server knows where you come from. You are coming from their grid.
 
That grid was asked by the viewer to connect to your server by DNS name, (not localhost). The protocol exchanges a lot of data... The viewer then connects to your grid using the correct Public IP. Opensim tries to compare the DNS name passed by the viewer to 127.0.0.1. So why does opensim incorrectly use 127.0.0.1? This is likely is because there is special code in there to take care of the 127.0.0.1 situation that would arise when logging into a home server using localhost instead of the local LAN IP..

Robust does not even know of localhost! It's only set for a domain name.

My best guess is Opensim is doing a reverse lookup of its domain name. Why? Shouln't it be just doing the string compare of the DNS name found in BaseURL versus the DNS name it got from the viewer?

From robust.hg.ini:

; The URL of the Robust server
BaseURL=http://www.outworldz.com [^]

(0033497)
BillBlight (developer)
2018-11-14 14:14

partially correct, but it falls back to your login IP , if your local server gets 127.0.0.1 then that is where your home server is going to assume you want to be from on your home server. You can see this when you login to your grid/standalone, it will show you the IP it thinks/knows you are coming from.

And if this is 127.0.0.1 it will never end well ..

If your home regions are talking to your server over 127.0.0.1 it will not end well.

Because when you try to jump home from a HG grid, it is going to tell that grid to take you "Home" and if that home is 127.0.0.1 , because that is what the viewer thinks your home is, it is not going to get you there.
(0033498)
BillBlight (developer)
2018-11-14 14:16

having local DNS/hosts mismatch pubic dns is a bad situation to be in
(0033499)
BillBlight (developer)
2018-11-14 14:27
edited on: 2018-11-14 14:34

In your example you also show 192.168.1.1 as the ip that is trying to connect to an external host, this is typical of the loopback issue, the foreign server did not actually get your public IP, so it is going to fail ..

192.168.1.1 is not as we know, NOT a public IP and only pubic IP's can talk to PUBLIC IP's .. Without being behind a NAT router, which is what is happening , the NAT has a loopback issue.

When you go OUT the server sees you coming from the outside of your router, but when you come back in all your home servers see you as a private IP.

Again, get proper hardware, proper network, and this is not an issue.

(0033500)
Ferd Frederix (reporter)
2018-11-14 14:48

Bill, the IP that is connecting to the remote grid is the Public IP of the router. 192.168.1.1 (the gateway on the LAn side) is not connecting to anything but the LAN IP of the server/viewer. All that works perfectly, the viewer works on all grids normally. Except to itself.

2) Opensim says "Comparing (Proper External IP) with login IP 192.168.1.1. Where did it get that? Thats a gateway address.

3) Robust only knows the DNS name.

For some reason, it is using the Gateway (router) address from deep inside the system networking stack. Why? If it simply used the Robust name as it must, it would work.
(0033501)
BillBlight (developer)
2018-11-14 15:00

Again this is a router issue, some routers do loopback on the wrong interface , they do it on the internal and not the external, this is a hardware issue.
(0033502)
Ferd Frederix (reporter)
2018-11-14 15:17

Its obviously a software issue. If you type in a web browser http://DNSname:8002, [^] you get Opensim's web page. Works perfectly. Any server-side viewer can log into this Opensim and travel the Hypergrid and come home. Works perfectly. Any HG visitor can reach the system and also leave. 100% perfect.

You just cannot reach your own system because somewhere the server (or viewer) is incorrectly programmed to use the LAN IP and not the DNS name in this one special case.

Probably here at line 373 in UserAgentService.cs in public bool VerifyClient(UUID sessionID, string reportedIP)

bool result = travel.ClientIPAddress == reportedIP || travel.MyIpAddress == reportedIP; // NATed

m_log.DebugFormat("[USER AGENT SERVICE]: Comparing {0} with login IP {1} and MyIP {1}; result is {3}",reportedIP, travel.ClientIPAddress, travel.MyIpAddress, result);


But other places that HG access client verification is performed use the DNS names, not the IP, which would work.
(0033503)
BillBlight (developer)
2018-11-14 15:23
edited on: 2018-11-14 15:24

Try it and find out ... Is all I can say ...

The loopback issue is still going to be a problem, regardless of that "verify" ..

You do realize that NOTHING on the internet actually works on names right??

The name points to an IP, the server runs on an IP, your router runs on an IP, the issue with the loopback is internally it does not report the external ip to the loopback ..

And when you start trying to screw with DNS to make it different on the inside than the outside, you are asking for trouble anyway ..

I did enterprise and ISP networking for 25+ years, there is no software substitute for proper network configuration .

(0033504)
BillBlight (developer)
2018-11-14 15:29
edited on: 2018-11-14 15:31

you can verify it is a loopback issue, by configuring everything using external IP's and not names ...

Regions and Robust, if you still have the issue, names are not the problem ..


In other words, setup the grid, using the external ..

put the external IP as the address in the grid manager ...

if you can't login to the grid from the same machine running it, 99% of the time if it is not a configuration issue, it is a loopback issue ..

(0033505)
BillBlight (developer)
2018-11-14 15:33

and to your example of course the http works from both ...

you set the hosts to 127.0.0.1 so from the inside it hits it ..

From another server it hits it using public DNS (as long as that is right)

But those two are not equal to each other, and that has bad practice written all over it ..
(0033506)
Ferd Frederix (reporter)
2018-11-15 09:30

I have a nice workaround for it now so I'll be closing this.
(0033507)
Ferd Frederix (reporter)
2018-11-15 10:48

Opensim uses IP from reverse DNS lookup. So etc/hosts patch does not work in one case. Use a Windows loopback driver to solve this..

- Issue History
Date Modified Username Field Change
2018-11-14 12:03 Ferd Frederix New Issue
2018-11-14 12:22 BillBlight Note Added: 0033495
2018-11-14 13:24 Ferd Frederix Note Added: 0033496
2018-11-14 13:37 Ferd Frederix Note Edited: 0033496 View Revisions
2018-11-14 14:14 BillBlight Note Added: 0033497
2018-11-14 14:16 BillBlight Note Added: 0033498
2018-11-14 14:27 BillBlight Note Added: 0033499
2018-11-14 14:34 BillBlight Note Edited: 0033499 View Revisions
2018-11-14 14:48 Ferd Frederix Note Added: 0033500
2018-11-14 15:00 BillBlight Note Added: 0033501
2018-11-14 15:17 Ferd Frederix Note Added: 0033502
2018-11-14 15:23 BillBlight Note Added: 0033503
2018-11-14 15:24 BillBlight Note Edited: 0033503 View Revisions
2018-11-14 15:29 BillBlight Note Added: 0033504
2018-11-14 15:31 BillBlight Note Edited: 0033504 View Revisions
2018-11-14 15:33 BillBlight Note Added: 0033505
2018-11-14 15:42 BillBlight Relationship added related to 0007405
2018-11-15 09:30 Ferd Frederix Note Added: 0033506
2018-11-15 10:48 Ferd Frederix Note Added: 0033507
2018-11-15 10:48 Ferd Frederix Status new => resolved
2018-11-15 10:48 Ferd Frederix Resolution open => won't fix
2018-11-15 10:48 Ferd Frederix Assigned To => Ferd Frederix


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker