Offering a monetary reward of at least L$ 5000 for the person who can help.

Kavai,

Most DSL 'modems' have a router built in, accessible through a web browser. I could not find specific information about your model, but similar ones from Comtrend have this feature. Have you tried to open this and tunnel through ports 12020-13050?

I was having a similar problem with a router that could not handle the UDP packet flood from LL's servers (even with the ports opened), and had to switch to one that could handle it. I was having issues logging in, and when I could login, doing a simple 'find' would kick me offline, every time.

To get to the web management utility (assuming your modem has one), just load your gateway's IP address into a web browser address bar. Usually it's located at 192.168.0.1 or 192.168.1.1, but yours may be different.

To find your gateway IP address, just go to Start > Run > CMD. At the command prompt, type 'ipconfig'. Your default gateway's IP address will be listed.

Note that if tunnelling though these ports doesn't help, it is possible that the router in your modem isn't going to work (reliably) with SL. If that's the case, then pester your service provider for a different model.

Hope this helps.

I wasn't able to acccess the 2 IPs I found thru IPConfig under their *default gateway* address. I don't think theres a router in this model. I will call my ISP on monday to check to make sure.

As this test didn't really work, could I conclude that its either my modem or that patch of SL code causing all the problem?

I think so, yes. Strife's posts lent a bit of insight to the problem with the circuit ID assignment, and I think that your modem is dropping packets (or receiving them out of order). Considering all the reformatting and testing you have done, the hardware/server code combination is the only culprit left.

After experiencing similar login problems, I concluded that my hardware didn't like what LL's server code was pushing to it. As I have no control over LL's code I had to change the only thing I could - my poor consumer-grade router that thought the UDP traffic from LL's server was a denial of service attack.

Since then, all has been quite peachy. It's interesting to note that Second Life is the first online application that I've used where I've experienced this problem. No other FPS or MMORPG that I've been involved with has exhibited this behavior.

I'm wondering if there's not a command line parameter that forces a connection to a particular circuit? In both logs you posted I saw that the same circuit was assigned (21422), but only right before the client's termination and most likely too late in connection process. This is just speculation, but if this ability existed it may bypass the code 0 issue with UserLoginLocationReply().

This sounds to me like the ISP is using a bad route to access SL, and that route is failing or has a high latency time.

This has nothing to do with the router ( or lack of ) in your DSL modem. This has to do with how your ISP is routing packets to / from SL.

Here is an example of a traceroute from my computer to SL. Note that there is a sever bottleneck at the borger gateway for BBNET before I get to SL ( 102ms). It may not seem like much , but it's huge compared to the previous hop(s). To this add that you are coming in from a long ways away. This result was from just hitting the SL web site - so next time you might try running a traceroute to SL and see what surprises are given. Save the results in a text file and compare them.

There are a few ways to do a traceroute - from dos : START >> RUN >> CMD ... from the dos prompt type tracert www.secondlife.com {substitute www.secondlife.com with the ip of the login server }

A bottleneck in routing could cause the out of sequence packets that the previous post indicated can cause issues.

-- Demetrius (Demi) Therian

--- Traceroute below --


07/09/05 10:42:10 Fast traceroute www.secondlife.com
Trace www.secondlife.com (66.150.244.149) ...
1 10.72.104.1 7ms 10ms 20ms TTL: 0 (No rDNS)
2 68.86.207.97 9ms 7ms 10ms TTL: 0 (No rDNS)
3 68.86.207.118 10ms 11ms 10ms TTL: 0 (No rDNS)
4 68.35.172.66 17ms 12ms 12ms TTL: 0 (No rDNS)
5 12.118.225.9 27ms 30ms 30ms TTL: 0 (No rDNS)
6 12.123.17.58 60ms 59ms 63ms TTL: 0 (tbr1-p012301.dlstx.ip.att.net bogus rDNS: host not found [authoritative])
7 12.122.10.50 56ms 54ms 56ms TTL: 0 (tbr1-cl2.la2ca.ip.att.net bogus rDNS: host not found [authoritative])
8 12.122.11.134 54ms 55ms 54ms TTL: 0 (gbr2-p10.la2ca.ip.att.net bogus rDNS: host not found [authoritative])
9 12.123.28.93 54ms 57ms 53ms TTL: 0 (gar1-p370.la2ca.ip.att.net bogus rDNS: host not found [authoritative])
10 No Response * * *
11 63.251.63.1 102ms 71ms 72ms TTL: 0 (border1.ge1-1-bbnet1.sfo002.pnap.net bogus rDNS: host not found [authoritative])12 66.150.244.149 65ms 65ms 67ms TTL: 51 (web0.lindenlab.com ok)

I did a traceroute and I was able to trace it all the way to the ISP of www.secondlife.com

However, the results came back where my connection to some Level 3 servers took 160-180 ms. Is this normal?

The only way to determine " Normal " is to take several samples and compare them. That being said, 160-180 seems a bit high to me. This could be a bottleneck. Another thing to look for is when you trace, watch the path it takes, and see if the path changes. While the path changing is perfectly normal, sometimes less than good paths are taken.


border1.ge1-1-bbnet1.sfo002.pnap.net seens to be fluxing between 60ms and 102ms. That is not good.


Keep in mind that www.secondlife.com is not the same as connecting to the simulation. Test any connections to the IP's assigned to the sim, as well as to lindenlabs.com.

Run stcond likfe, and login if you can.

Minimize SL and open up a dos window and issue the command NETSTAT

This should show you a connection to a remote site, in my case on port 8100. This will be your current connection to the simulation. Traceroute to that IP.

For example, my connection to Sl is via a colocation in NYC at 216.12.162.56:8100

NETSTAT

Proto Local Address Foreign Address State
TCP (My Machine):3030 216.12.162.56:8100 ESTABLISHED

I did a traceroute to that address, and I'm getting 76ms to it. There is a slight bottleneck of 85 at a core router nearby, but its not that big.

I have a theory, i noticed in your log file that your computer is set to a china time zone. And i've heard that china does some creative stuff when it comes to the internet (censorship). Now SL uses both UDP and TCP for it's connections. If the circuit code is the first packet of a udp connection your ISP might initializing and checking the connection through some computer (to determine if it should ax the connection), this could result in the delay of the packet. Since it's the week end i wouldn't expect to hear anything from LL. I'm confident in my diagnosis, I don't think there is much you can do short of changing ISPs (which may or may not fix the issue, i'm a synic so i say it won't). It's up to LL now.

Well, we did already go through this possibility earlier in the thread. Seth Kanahoe assured me that Macau is a Special Administrative Region, and that, among other things, the internet censorship policies don't apply. Still, maybe we should revisit this... Macau is kind of hanging off the coast of Southeast China, and pretty much has to have its main internet backbone coming straight from China's infrastructure. People not living in China have noticed in the past that if you get unlucky and your traffic gets routed through China, you'll be subject to their censorship policies.

It would make sense in light of what we're seeing here. I'm pretty sure that SL doesn't bother trying to reorganize the order of packets like TCP does, only asking for retransmissions if it misses a UDP packet. Piping a connection through China's internet infrastructure could well dirty it up beyond what the SL client's login code can deal with.

This would also explain the seeming intermittency of the problem. China's network infrastructure is changing all of the time, and people have often reported blocks starting intermittently until all border routers are updated. It seems like from what Kavai's been reporting, the failure to connect happens pretty much100% of the time.

Like I said before, when dealing with China's internet, all bets are off. LL can possibly work around the reordering problem, but who's to say SL will actually continue to work through China's filters? They do lots of really crazy stuff.

I'm sorry i didn't relize, I guess I didn't read the thread too carefully x_x

As I understand it, the client just shouldn't ever receive a zero circuit code under the current design. I mean, it should actually be possible at all for that to happen. It clearly is, though.

So that leaves some questions: why is it happening, why is it happening only to Kavai, (or why is Kavai the only one saying, "uh... guys?" and which Linden is savvy enough to wrangle a free vacation to Macau under the guise of "testing" out of this?

Upon further consideration, I think this is almost certainly a bug with SL that only ever presents under very rare conditions. Assuming your ISP isn't doing anything crazy, like interpreting SL as a massive DoS attack, your only real option is to wait for the Lindens to figure this out. Try filing another report, outlining the zero circuit strangeness, and see if that speeds the process up at all.

"I can't connect" is not a fun time to troubleshoot. "I have a reproduceable, documented problem, here are my logs, this is the circumstances under which it happens" is far, far better.

Thanks for the tips Catherine really appricate it.

I will file a third report as LL didn't get back to my on the 2nd one yet. So basically this region code is where my problem is and just send all my logs over.

However, just curious tho, why am I just affected, out of no specific reason, around 3-4 weeks ago, it worked fine before and this problem just happend. What might have caused it?

I think your ISP probably did something. Historically, SL has had the most problems when networks and drivers don't meet standards properly. This is the root of the ATI problems, of some instances of ghosting, and so on.

I suspect your problem is another example of something that should never happen, but does anyway. In the case of your problem, it occurs only when faced with whatever it is that your ISP has done. Hopefully, the Lindens will be able to resolve it, or your ISP can be convinced that whatever they've been up to is not a good idea.

It's not that it is receive a zero circuit, zero is just the default value asigned when the object is initialized. It shouldn't connect till it gets a circuit code.

Strife, do you think that it is caused by my ISP or is it some compatibility issue that just occured randomly?

I think your ISP is aggravating a flaw in the client. In my mind getting LL to fix the flaw is the right solution.

It's LL's responsibility to fix bugs.

Problem is, it has been like 4-5 days since I last heard from a Linden. If any Linden is online now can they check up with the issue?

I've had a perverse idea, and i think it should work.

It's a hack but a fun one.

First you will need this...
cpulower.zip

We are going to slow your computer down so that it takes your computer longer to log in, hopefully long enough as to allow for the circuity code to come back before it is used.

Set CPULower to 50%, that sould slow you down enough (if not try something higher)

When you have loged in just close CPULower.

sadly, even when i turned it down to 100% lowered, i still encounter that problem

well this is interesting, i was able to log in yesterday the whole day, but once i disconnected and went to bed, i came back and found i couldn't log in again... whats up with that?

Okay, lesee.
Run a full Tracert to the linden sims,
Post it here. I'm working or I'd be on to help..
Also, starting bugging your ISP.

C:\>tracert sim500.agni.lindenlab.com

Tracing route to sim500.agni.lindenlab.com [69.25.104.186]
over a maximum of 30 hops:

1 7 ms 9 ms 8 ms nrp12.macau.ctm.net [202.175.100.12]
2 7 ms 7 ms 8 ms v601a.macau.ctm.net [202.175.95.61]
3 8 ms 9 ms 9 ms gw2-191.macau.ctm.net [202.175.26.232]
4 73 ms 73 ms 73 ms 158.205.250.13
5 74 ms 74 ms 74 ms ge1-0.tokg3.idc.ad.jp [158.205.192.145]
6 188 ms 199 ms 188 ms so1-0-0.sfom1.idc.ad.jp [158.205.192.38]
7 206 ms 207 ms 207 ms ge-8-1-126.ipcolo2.SanFrancisco1.Level3.net [166
.90.128.5]
8 187 ms 187 ms 188 ms so-6-1-0.mp1.SanFrancisco1.Level3.net [4.68.96.1
41]
9 188 ms 187 ms 187 ms so-10-0.ipcolo1.SanFranciso1.Level3.net [4.68.11
2.234]
10 187 ms 187 ms 188 ms gw-level3-sfo.internap.com [63.211.143.18]
11 188 ms 188 ms 187 ms border1.ge1-1-bbnet1.sfo002.pnap.net [63.251.63.
1]
12 207 ms 207 ms 208 ms sim500.agni.lindenlab.com [69.25.104.186]

Trace complete.




Heres the tracert log