Re: [Opensim-users] Problems with teleporting in grid mode from simulator, instance to another instance? (Ferd)
try to fill in the IP address instead of the domain name in the Region.ini for ExternalHostName. It helped in my configuration but it seems that everybody is thinking that the resolving of the domain name is resolved. I think there is still problem with that... 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 = 10 > 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
Re: [Opensim-users] Problems with teleporting in grid mode from simulator, instance to another instance? (Ferd)
The router I am using is a NETGEAR WNDR3700v4; Gigabit router. It's not
using stock firmware though as I have replaced it with DD-WRT v24-sp2
(04/01/15) std.
Initially the DD-WRT firmware didn't support loopback out of the box so
I had to enable it with a firewall rule as per the DD-WRT wiki on
enabling loopback connections:
insmod ipt_mark
insmod xt_mark
iptables -t mangle -A PREROUTING -i ! `get_wanface` -d `nvram get
wan_ipaddr` -j MARK --set-mark 0xd001
iptables -t nat -A POSTROUTING -m mark --mark 0xd001 -j MASQUERADE
Note that the loopback has been enabled in this fashion the entire time
I've been having these problems. But I don't know if it's because I have
it enabled like this that it's a problem or... The router just doesn't
fully support loopback hardware-side... I would assume that if it didn't
then it would just not work 100% of the time instead of sometimes it
works fine and sometimes it just hates me which the latter seems to be
my case lol.
Running through my config files I have come up with these settings:
For my regions the Region.ini files follow this pattern:
[Monte Cristo]
RegionUUID = ded5de05-aef9-4c07-a08c-b317c025c0b0
Location = 1000,1000
InternalAddress = 0.0.0.0
InternalPort = 9000
AllowAlternatePorts = False
ExternalHostName = 68.1.XXX.XXX
For OpenSim.ini on each simulator:
[Const]
BaseURL = http://127.0.0.1
PublicPort = "8002"
PrivatePort = "8003"
I'm using local host for this configuration because everything all runs
on the same machine; And selectively expose the services needed to
operate over WAN with the WAN address such as map tile URL, login
services etc. But things like asset services, inventory services, etc
use local host so that requests for these things don't go out over WAN
only to be told that they need to come right back home for the services
(There is quite a bit of latency when this happens I've observed; Thus
my using local host for these things)
For GridCommon.ini on each simulator:
[GridInfo]
GridInfoURI = "http://68.1.XXX.XXX:8002";
Everything else is left as (Config Name) =
"${Const|BaseURL}:${Const|PrivatePort}" or (Config Name) =
"${Const|BaseURL}:${Const|PublicPort}"
In Robust.ini:
[Const]
BaseURL = "http://127.0.0.1";
PublicPort = "8002"
PrivatePort = "8003"
Using local host in the same manner as OpenSim.ini
In Robust.ini LoginService section MapTileURL = "http://68.1.XXX.XXX:8002/";
In Robust.ini GridInfoService section login = http://68.1.XXX.XXX:8002/
Everything else is left as (Config Name) =
"${Const|BaseURL}:${Const|PrivatePort}" or (Config Name) =
"${Const|BaseURL}:${Const|PublicPort}"
For what it's worth I have also tried with BaseURL = http://LAN IP,
BaseURL = http://WAN IP, and BaseURL = http://FQDN instead of local
host. Not those values literally but the respective values that would be
there in an actual configuration. But the issue still persists in all
those cases.
It's a very random issue though. I can connect fine and every one else
can connect fine through WAN and everything works. Teleports seem to be
about a 50/50 chance of success.
___
Opensim-users mailing list
Opensim-users@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Re: [Opensim-users] Problems with teleporting in grid mode, from simulator instance to another instance? (Ferd)
FQDN on externalhostname should be working Make sure you did not set a option ResolveAddress to true Btw this was broken by mistake, but only for a few hours on master Think the issue did not reach any RC From: opensim-users-boun...@opensimulator.org [mailto:opensim-users-boun...@opensimulator.org] On Behalf Of taalj Sent: Tuesday, May 23, 2017 20:36 To: opensim-users@opensimulator.org Cc: Fred Beckhusen Subject: Re: [Opensim-users] Problems with teleporting in grid mode, from simulator instance to another instance? (Ferd) Hi Fred / et all, My Grid configuration is running behind a company firewall. So all service we provide are serviced by the company firewall. We dont want to advertise our internal IP addresses to the outside world. So we run an internal DNS server with all the internal network and an external DNS server to provide services to users on the internet. The Split DNS concept. In this way we make our Network configuration more secure beside all other security measures we do on the FW of course. By port forwarding we redirect the traffic from Internet to the right ports on the Grid or Region server. When I started to configure OpenSim I first use FQDN (host.domain.nl) and got the same result as mentioned by Tom. After monitoring the network I saw package that could not be resolved. For the internal network users and the users from internet you want the configuration to be transparent without have to use different configuration. The only solution to use OpenSim Grid in combination with split DNS and a FW is to use FQDN. Then the resolving of the internal and external DNS will result respectively in the internal IP address for internal users (for instance an address like 192.168.0.1) and the FW IP address for external users (for instance 47.185.237.187) with forwarding of ports to the internal servers. This configuration works for all services we provide but not for OpenSim's Region.ini. This configuration will only work when you put in the FW IP address. Somehow there is something wrong in the resolving and accepting the FQDN in the Region.ini I think more and more OpenSim network will be behind FW and security system with split DNS and use internal un-routable IP ranges (class A: 10.x.x.x and class B: 192.168.x.x). Normally this configuration can work stand-alone. But when my FW is down the standalone grid will not work because of the external IP address in the Region.ini. When FQDN in the Region.ini are correctly resolved then internal users can work on the grid because it doesn't need the FW to connect to but use the internal DNS that resolve the FQDN to the internal IP address. So the FQDN in the Region.ini does not lead to the right IP (in this case internal IP address) it will result in a TP that is not working because the Regio Server can not be found. with regard, Johan Taal Fred Beckhusen schreef op 2017-05-23 20:36: Johan Taal: You have an interesting comment that the FQDN should not be used on regions. Are you saying that the DNS system at the far end may have issues resolving it to an IP? Or that the LAN user cannot get to the region because their DNS server is not resolving, thus occasionally leading to Thomas Ringates flaky tp problem? Tom: Your region file looks fine.The Outbound Disallow looks correct, too. That's a good catch - an exception should be made to the use http:// 'rule'. One minor point: I believe Maxprims = 1 is meaningless without an economy module. It only reports that number to a osSL function for prims can check parcel limits. And the viewer stops at 45,000 no matter what you type in. I have the same Linksys, too, and it works great for me. Fred ___ 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
Re: [Opensim-users] Problems with teleporting in grid mode, from simulator instance to another instance? (Ferd)
Hi Fred / et all, My Grid configuration is running behind a company firewall. So all service we provide are serviced by the company firewall. We dont want to advertise our internal IP addresses to the outside world. So we run an internal DNS server with all the internal network and an external DNS server to provide services to users on the internet. The Split DNS concept. In this way we make our Network configuration more secure beside all other security measures we do on the FW of course. By port forwarding we redirect the traffic from Internet to the right ports on the Grid or Region server. When I started to configure OpenSim I first use FQDN (host.domain.nl) and got the same result as mentioned by Tom. After monitoring the network I saw package that could not be resolved. For the internal network users and the users from internet you want the configuration to be transparent without have to use different configuration. The only solution to use OpenSim Grid in combination with split DNS and a FW is to use FQDN. Then the resolving of the internal and external DNS will result respectively in the internal IP address for internal users (for instance an address like 192.168.0.1) and the FW IP address for external users (for instance 47.185.237.187) with forwarding of ports to the internal servers. This configuration works for all services we provide but not for OpenSim's Region.ini. This configuration will only work when you put in the FW IP address. Somehow there is something wrong in the resolving and accepting the FQDN in the Region.ini I think more and more OpenSim network will be behind FW and security system with split DNS and use internal un-routable IP ranges (class A: 10.x.x.x and class B: 192.168.x.x). Normally this configuration can work stand-alone. But when my FW is down the standalone grid will not work because of the external IP address in the Region.ini. When FQDN in the Region.ini are correctly resolved then internal users can work on the grid because it doesn't need the FW to connect to but use the internal DNS that resolve the FQDN to the internal IP address. So the FQDN in the Region.ini does not lead to the right IP (in this case internal IP address) it will result in a TP that is not working because the Regio Server can not be found. with regard, Johan Taal Fred Beckhusen schreef op 2017-05-23 20:36: > Johan Taal: You have an interesting comment that the FQDN should not be used > on regions. Are you saying that the DNS system at the far end may have > issues resolving it to an IP? Or that the LAN user cannot get to the region > because their DNS server is not resolving, thus occasionally leading to > Thomas Ringates flaky tp problem? > > Tom: > > Your region file looks fine.The Outbound Disallow looks correct, too. > That's a good catch - an exception should be made to the use http:// > 'rule'. > > One minor point: I believe Maxprims = 1 is meaningless without an > economy module. It only reports that number to a osSL function for prims can > check parcel limits. And the viewer stops at 45,000 no matter what you type > in. > > I have the same Linksys, too, and it works great for me. > > Fred > > ___ > 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
Re: [Opensim-users] Problems with teleporting in grid mode, from simulator instance to another instance? (Ferd)
Johan Taal: You have an interesting comment that the FQDN should not be used on regions. Are you saying that the DNS system at the far end may have issues resolving it to an IP? Or that the LAN user cannot get to the region because their DNS server is not resolving, thus occasionally leading to Thomas Ringates flaky tp problem? Tom: Your region file looks fine.The Outbound Disallow looks correct, too. That's a good catch - an exception should be made to the use http:// 'rule'. One minor point: I believe Maxprims = 1 is meaningless without an economy module. It only reports that number to a osSL function for prims can check parcel limits. And the viewer stops at 45,000 no matter what you type in. I have the same Linksys, too, and it works great for me. Fred ___ Opensim-users mailing list Opensim-users@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Re: [Opensim-users] Problems with teleporting in grid mode from simulator, instance to another instance? (Ferd)
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 = 10 > 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
Re: [Opensim-users] Problems with teleporting in grid mode from simulator, instance to another instance? (Ferd)
Fred, I also checked my gridcommon.INI and this one statememt does not have the http:// in the different addresses. Could this be my problem? [Network] http_listener_port = 9182 OutboundDisallowForUserScriptsExcept = 192.168.1.61|tsim.us.to|bandit1.tsim.us.to|bandit1.tringate.us.to|tringate.us.to The use of "bandit1.tsim.us.to" is used so my "hosts" file can intercept the communications and point directly to the other local machine for script types of communications to my servers. I do this with scripted chat messages so that only people on my regions are able to use my chat server. 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 ___ 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
Re: [Opensim-users] Problems with teleporting in grid mode from simulator, instance to another instance? (Ferd)
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 = 10 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 doc
