Traceroute(Technical)Follow

For those experiencing connection problems on PC - have you done a traceroute? It will resolve the 'It's your ISP' or 'It's SE' question once and for all.





Edited, Mar 13th 2007 10:48pm by Pikko

I'm no networking buff, but I know, at the very least, what a tracert command is...

I won't divulge any other information than the following: I started timing out after I'd reached APNIC. However, I have no R0 problems as others do, so take that as you will.

Well since some people even have problems with the lobby servers, you could just check which IP POL sends and transmits data from. And in that way at least find if there is an issue with the route the data takes from and to those servers at least.

Based on information collected on my router it appears that for each area you go into there is a unique IP address. A UDP session to that IP address comes up when you enter that area. There is also a brief TCP connection an IP address. For me, that address was 202.67.55.217. I am on Ragnarok Server. I have no clue without further testing if these IPs are "static" (I don't mean Static IP vs. Dynamic IP in the technical sense. Of course servers are static. I mean maybe they are load balanced or asigned on the fly, i dunno, anyway...). Can anyone confirm these IPs on Ragnarok?

UDP area addresses (for me on Ragnorok)
Windurst Mog - via Windurst Woods if that matters (for me) 202.67.50.99
Windurst Walls (for me) 202.67.50.100
Port Windurst (for me) 202.67.50.101 - *trouble R0 area*
Windurst Woods (for me) 202.67.50.102

Well, in any case the traceroute didn't seem to tell me too much. The areas that work, and those which don't work both return similar traceroutes. After hop 20 to 202.67.63.45, ICMP packets appear to be blocked. I have gotten "Destination net unreachable." on areas that work and those that don't work alike.

Tracing route to 202.67.50.101 over a maximum of 30 hops

** Removed the first few hops **

7 8 ms 8 ms 15 ms te-3-2.car1.Atlanta1.Level3.net [4.78.209.197]
8 8 ms 13 ms 17 ms ae-32-52.ebr2.Atlanta2.Level3.net [4.68.103.62]
9 8 ms 17 ms 17 ms ae-1-100.ebr1.Atlanta2.Level3.net [4.69.132.33]
10 31 ms 35 ms 35 ms ae-3.ebr1.Dallas1.Level3.net [4.69.132.81]
11 38 ms 35 ms 36 ms ae-1-100.ebr2.Dallas1.Level3.net [4.69.132.46]
12 75 ms 70 ms 72 ms ae-3.ebr2.LosAngeles1.Level3.net [4.69.132.77]
13 64 ms 63 ms 64 ms ae-21-56.car1.LosAngeles1.Level3.net [4.68.102.172]
14 64 ms 63 ms 64 ms WILTEL-INTE.car1.LosAngeles1.Level3.net [63.208.231.86]
15 64 ms 64 ms 62 ms lacbb001.kddnet.ad.jp [59.128.2.1]
16 178 ms 191 ms 179 ms otecbb103.kddnet.ad.jp [203.181.100.157]
17 173 ms 174 ms 173 ms otejbb203.kddnet.ad.jp [59.128.4.161]
18 180 ms 193 ms 177 ms cm-ote221.kddnet.ad.jp [203.181.101.6]
19 190 ms 207 ms 189 ms 203.181.98.10
20 177 ms 176 ms 177 ms 202.67.63.45
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.

"Request timed out" is repeated until maximum hops are reached OR it ends with address 202.67.63.58 reporting "destination net unreachable"

XX * * 202.67.63.58 reports: Destination net unreachable.



Edited, Mar 13th 2007 1:45am by Radell

Edited, Mar 13th 2007 1:46am by Radell

Edited, Mar 13th 2007 2:19am by Radell

When it reaches 202.67.63.58, is it consistently for zones you can reach, consistently for zones you R0 in, or kinda all over the place?

The zone server don't respond to ping. Any of them. The lobby servers, servers you open TCP connections with will thou.

I looked thur the packet stream during a 'zone in', see what I could figure out.

When you zone into an area, you start sending UDP packets back and forth (UDP isn't a 'connection' per say, you just send a packet and then the other person sends back another packet, if they want -- and hopes for the best -- UDP its strictly relible -- thats why you don't DC immediately, the client retrys many times before giving up). After about 3 rounds of UDP chat, SE sends another kind of packet I wasn't familier with, I think it was a kind of authentication SE was using. And then continues UDPs.

Only difference between the R0 zones and non-R0 zones, I could find was the server is failing to send this special packet for some reason, or the packet is being filtered before it reaches your PC (I don't know why it would be filtered for one zone and not all). W/o the response to this packet (which was a UDP), SE servers won't listen to your continued UDP traffic. You're still trying to talk to the server, but the server is ignoring you. So Send continues but Receive drops to zero.

Doesn't Ping use a different ports that may be used by FFXI? Would it still be a fair test to use Ping instead of the FFXI ports? Since there are other people that can access the same server -- trying to ping an obviously accessible server (to some degree to a lot of people) would that a futile effort?

Edited, Mar 13th 2007 9:00am by scchan

I found visualroute.visualware.com/ to present some fairly useful information.

Testing 202.67.63.58, as suggested above, yields major packet loss on hops owned by KDDI Corp., a telecommunications group in Japan. I got 12 hops before 100% packet loss running from the US server.

Give it a shot yourself if you're interested to see how the connection is poor before (presumably) entering Square-Enix network. The page requires Java 2 to run, so if you don't do Java, don't bother.

Sorry to break this to you, but 1) that's easy to do and 2) someone else in this thread has already done so. I have my firewall configured so strictly that I have to explicity allow traffic from SE's servers. When they move stuff around and I get an R=0 on zoning, it takes me all of 30 seconds to find the address of their server and poke the appropriate hole.

Ping uses ICMP, an entirely different protocol from UDP. If you can successfully ping or trace part of a route, that will confirm that part of the route is working. Unfortunately, many providers filter or break ICMP traffic for one reason or another, so a simple timeout doesn't mean that something is broken. It's also very possible for ping to work but other traffic be blocked.

Destination net unreachable usually indicates a routing failure or configuration issue. However, if you're seeing that for both working and non-working areas, then it's entirely possible that SE (or someone else) is somehow causing that on purpose.

If looking at pings and traces doesn't help lead to an answer, using a packet sniffer might. Now before everyone goes and karma-bombs me for suggesting that, understand that I'm talking about a standard tool used to analyze network traffic, not a custom sniffer that decodes FFXI packets for the purposes of cheating, etc. Someone else in this thread already has tried this, I can see, but it might be helpful for others to look at the packets also. I would do it myself, but I'm not having r=0 problems. More than likely if you know enough to be helpful with a sniffer, you already know where to get one. But in the interest of being completely open about things, this is the tool I prefer: www.wireshark.org/.

One thing I'm curious to know is if our clients are looking up the zone servers with DNS, or simply receiving the IP address directly from SE. If DNS info is stale or bogus, connecting to the wrong IP would obviously be a problem. If anyone has multiple chars or accounts where one can access a particular zone and another cannot, then I'd like to know if the client is attempting to connect to the same IP in both cases. If not, that's a clue. If so, any differences in the packet captures between the two could be helpful.

Anyhow, I was hoping SE would have fixed this by now (their fault or otherwise), but if we have to figure this out ourselves then so be it. I was going to stay out of it since there's not much I can do without experiencing the proglem first hand, but having a quarter of my dynamis shell r=0 when we zoned into dynamis last night really kinda pissed me off.

Edited, Mar 13th 2007 11:08am by VxSote

I've tried running netstat while I'm playing, but I don't see any of these UDP connections that seem to change while you're in a zone.

  TCP    tatobox:19067          202.67.56.124:51246    ESTABLISHED     3152    [pol.exe]

That's about the only thing I can see FFXI related.

It's probably only giving you established TCP connections. UDP is a connectionless protocol. You might try using "netstat -a", though I'm not certain if that will work.



I was thinking about this possibility as well. It is the first thing I'm going to try when I get home from work, assuming the "server maintentance" does not fix it. After I change my IP and get different zones to R0, I will see if my client tried to access "port windurst" with a different IP addres.

On the other hand, I'm not sure if DNS is even as issue, as I can't seem to be able to do a reverse-DNS lookup on the IP addresses for various zones.

Nope, that won't snag the connection.

I'm going to look a little further into this.

Using a sniffer I noticed that when I zone into La Theine Plateu, I keep sending packets to 202.67.49.184 but I am not getting any back.

Here's the tracert

Tracing route to 202.67.49.184 over a maximum of 30 hops 
 
  1    <1 ms    <1 ms    <1 ms  192.168.2.1 
  2     1 ms    <1 ms    <1 ms  192.168.0.1 
  3     9 ms    10 ms     9 ms  adsl-75-45-239-254.dsl.sfldmi.sbcglobal.net [75. 
45.239.254] 
  4    10 ms     9 ms     9 ms  67.38.70.65 
  5     9 ms    10 ms     9 ms  bb1-g10-0.sfldmi.sbcglobal.net [151.164.43.59] 
  6    10 ms    11 ms    11 ms  bb2-p8-0.sfldmi.sbcglobal.net [151.164.43.193] 
  7    15 ms    16 ms    15 ms  core2-p7-0.crchil.sbcglobal.net [151.164.43.195] 
 
  8    15 ms    16 ms    16 ms  core1-p8-0.crchil.sbcglobal.net [151.164.188.42] 
 
  9    26 ms    26 ms    26 ms  151.164.94.86 
 10    32 ms    31 ms    31 ms  core1-p4-0.crhnva.sbcglobal.net [151.164.41.204] 
 
 11    31 ms    31 ms    32 ms  bb1-p4-1.hrndva.sbcglobal.net [151.164.242.70] 
 12    32 ms    31 ms    31 ms  bb2-p6-0.hrndva.sbcglobal.net [151.164.243.22] 
 13    32 ms    35 ms    32 ms  ex2-p5-1.eqabva.sbcglobal.net [151.164.40.53] 
 14    32 ms    32 ms    31 ms  ix-dc1.kddnet.ad.jp [206.223.115.43] 
 15    39 ms    38 ms    38 ms  tr-ny3.kddnet.ad.jp [203.181.106.169] 
 16    92 ms    92 ms    92 ms  lacbb002.kddnet.ad.jp [59.128.3.17] 
 17   214 ms   214 ms   214 ms  otecbb104.kddnet.ad.jp [203.181.100.165] 
 18   205 ms   205 ms   205 ms  otejbb203.kddnet.ad.jp [203.181.96.142] 
 19   206 ms   205 ms   200 ms  cm-ote221.kddnet.ad.jp [203.181.101.6] 
 20   205 ms   205 ms   206 ms  203.181.98.10 
 21   204 ms   205 ms   205 ms  202.67.63.45 
 22     *        *        *     Request timed out. 
 23     *        *        *     Request timed out. 
 24  202.67.63.58  reports: Destination net unreachable. 
 
Trace complete.