Hi to All,
I have reported this problem before. This version and the version of
OpenSim before does NOT allow Full Qualified Domain Name in the
Region.ini file. I think it should be. The problem is gone when you fill
in the IP address there.
Specially for big company networks (schools, businesses etc.) who use
Firewall in combination with split DNS it is wonderful if FQDN is
supported in Region.ini. On this moment every request will need the
firewall external IP address to be in the Region.ini so the Grid is also
reachable from the outside. With a forward rule in the Firewall to
server that serviced the specific region it will work from the inside
campus network and also from the outside (Internet).
I have this configuration working on a campus grid with more the 1200
regions and a number of servers in the internal network. I like to
reduce traffic so if this problem can be fixed and FQDN addresses are
accepted so the combination of split DNS, Firewall and Region.ini works
I will great-full!
short time solution is to put in the Region.ini the IP address instead
of the FQDN for the ExternalHostName.
With regards,
Johan Taal
tring...@gmail.com schreef op 2017-05-23 18:29:
> Fred,
>
> I read your response with great interest. I also have TP problems on a
> frequent basis, and I switched away from Frontier and the actionteck modem
> and went back to Brighthouse/Spectrum which uses a true pass-through modem
> and I use my WRT1200AC V2 modem running standard Linksys firmware.
>
> Things run much better, but I still have TP problems myself. Visitors have
> no issues at all.
>
> My regions run on four Fedora linux servers here on my local network.
>
> I have felt the issue was how things are configured as the TP issue is random
> like this original post talks about.
>
> Here is how my region INI files are all set up is this correct?
>
> InternalAddress = 0.0.0.0
> InternalPort = 9182
> AllowAlternatePorts = False
> MaxPrims = 100000
> ExternalHostName = tsim.us.to
> RegionType = "Archipelago - Tropical"
>
> I use a dynamic name service for my domain of tsim.us.to
>
> I have not tried your debug suggestion yet, as I have no idea what I should
> be looking for.
>
> I see different results when I TP sometimes I arrive with no troubles,
> sometimes my viewer simply closes, and I have to relog, and sometimes I wait
> for a long time and then end up not TP's. Many times if I first go to LBSA
> and then back to one of my regions everything usually works, but not always.
>
> I am convinced it has something to do with loopback, but the WRT1200AC
> supports that function.
>
> Tom
>
> -----Original Message----- From: Fred Beckhusen
> Sent: Tuesday, May 23, 2017 10:56 AM
> To: opensim-users@opensimulator.org
> Subject: [Opensim-users] Problems with teleporting in grid mode from
> simulator, instance to another instance? (Ferd)
>
>> 1. Re: Problems with teleporting in grid mode from simulator
>> instance to another instance? (Chris)
> It appears to me that your LAN dest region did not handshake properly,
> somewhere at the Agent creation process, and the CAPS seed process found
> the destination socket was not available.
>
> I wonder how reliable it is in general. Have you been able to bulk
> upload a couple dozen textures reliably, or does it crash out partway
> through? That's a sure sign that loopback is failing. You xxx'd your
> IP addresses, so I believe you are using a Public WAN IP and therefor a
> router is involved and loopback is necessary. There are many reasons
> loopback can go wrong or be flaky. Perhaps posting your router
> brand/model number to us for future reference will help us, and maybe we
> can spot something for you. If this turns out to be the router, please
> help us update the page on the Opensimulator.org web site that we use to
> track which routers work and which do not. It is at
> http://opensimulator.org/wiki/NAT_Loopback_Routers
>
> Troubleshooting: Check that all IP addresses in your INI files start
> with http:// and make sure none of the regions have http:// in them.
>
> Go to the destination region and type into the console "debug http all
> 5". This will print out more details of the handshake that you now
> cannot see. You can go to level 6, but that's really verbose. The
> command "debug http all 0" will turn it off again.
>
> A good way to find out if it is loopback is to set your Public IP in the
> Opensim.INI to be the LAN IP of the server. You will also need to set
> your grid parameters to point to it in the viewer to be able to log in.
> When all Private LAN IP's are used, your router will not be involved in
> anything at the TCP/IP level and all traffic will be
> machine-to-machine. This applies to any IP's in the range of
> 172.16.*.*, 192.168.*.* or 10.*.*.*. The Ethernet switch is still
> involved, though it is unlikely to be the problem as it works with a
> totally different protocol that carries the TCP/IP inside it.
>
> I have collected about a thousand Opensim stats on this. Current count
> is 784 home routers failed loopback on first try, and only 125 passed.
> Reasons vary: mostly loopback is just missing, but I have remoted in to
> some machines and seen some very troubling things. I have continually
> been surprised by the flakiness of some, and also surprised by how well
> a cheap one from Comcast worked.
>
> Some examples: TCP appears to loop back, but not UDP. A major brand,
> Actiontech, widely used by FIOS, cannot loop back reliably from LAN
> IP:port to a different LAN IP:port (which sounds like your situation),
> but will loop back to the same machine very reliably. There are European
> ISPS that charge extra fees for loopback, (and require you to pay them
> to set up port forwarding, too). Some ISP's loopback at the Central
> Office and lose a lot of packets in the process. There are routers with
> only a 1K UDP loopback buffer appear to work but are flaky on teleports
> and bulk uploads.
>
> Some routers block the Public IP:PrivatePort ( typically 8003)
> configuration by looping back outside on the WAN side of the firewall,
> thus hitting the router firewall that should be blocking port 8003. As a
> result, Groups, XBakes and Profiles will not work. This took me many
> months to find as I am stupid about some things and believe the
> documentation. You cannot fix it by moving the Private port (8003) to a
> different port, either. I've seen several people "solve it" by opening
> Port 8003 to the public, which is a Bad Idea. Use LAN IP: Private Port
> everywhere you see PublicPort: Private IP in Groups, Xbakes and
> Profile. Or use http://localhost:Private Port for standalones.
>
> Fred Beckhusen/Ferd Frederix
> Outworldz, LLC
> www.outworldz.com [1]
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users@opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users@opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Links:
------
[1] http://www.outworldz.com
_______________________________________________
Opensim-users mailing list
Opensim-users@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
