Error code 2002 and 90000

**Alexika** · 07-29-2015 08:28 AM

Raist, at first I was really thinking you may be right, but I don't think our ISP is to blame at all. I have done numerous long term pings now to my server and the problem does not arise until it leaves my ISPs network. In fact, the majority of my packet loss is actually once it hits SEs network. I am starting to believe that SE is not paying for enough bandwidth.

**Raist** · 07-29-2015 08:48 AM

Originally Posted by Alexika

Raist, at first I was really thinking you may be right, but I don't think our ISP is to blame at all. I have done numerous long term pings now to my server and the problem does not arise until it leaves my ISPs network. In fact, the majority of my packet loss is actually once it hits SEs network. I am starting to believe that SE is not paying for enough bandwidth.

Didn't you previously state you were seeing issues at an alter.net hop? More specifically, I think it was alter.net and LEvel3 if I remember correctly. Alter.net is Verizon. More specifically, Verizon Business. They are the ones opting to put you on Level3 and not someone else. It is all on your ISP's routing policies making that happen...and they have the power to change it if they aren't going to work with Level3 to track down/address the issues with that peering partner.

It is well within your ISP's power to find you a better route.

Edit: let's see if I can find some examples of what I'm talking about...going back a over a year (03/2014), we have this, where I was wrangling with a localized issue with a TWC gateway (problem was an outdated CMTS):

http://forum.square-enix.com/ffxiv/t...=1#post1918510

Tracing route to 199.91.189.25 over a maximum of 30 hops

1 2 ms <1 ms 1 ms LPTSRV [10.10.100.1]
2 296 ms 65 ms 25 ms cpe-098-025-064-001.sc.res.rr.com [98.25.64.1]
3 11 ms 11 ms 17 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 33 ms 30 ms 24 ms xe-7-0-0.rlghncpop-rtr1.southeast.rr.com [24.93.64.40]
5 33 ms 34 ms 32 ms 107.14.19.44
6 28 ms 40 ms 30 ms ae-2-0.pr0.dca10.tbone.rr.com [66.109.6.169]
7 33 ms 43 ms 35 ms te0-16-0-23.ccr41.iad02.atlas.cogentco.com [154.54.10.209]
8 36 ms 32 ms 34 ms be2177.ccr22.dca01.atlas.cogentco.com [154.54.41.206]
9 45 ms 42 ms 44 ms be2148.ccr21.jfk02.atlas.cogentco.com [154.54.31.118]
10 42 ms 43 ms 61 ms be2106.ccr21.alb02.atlas.cogentco.com [154.54.3.50]
11 66 ms 67 ms 71 ms be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17]
12 62 ms 61 ms 60 ms 38.122.42.34
13 46 ms 45 ms 46 ms 192.34.76.10
14 42 ms 43 ms 43 ms 199.91.189.242
15 43 ms 44 ms 46 ms 199.91.189.25

Trace complete.

I continued to work with them for quite a while...eventually started working more directly with engineering on it (Tier3), as noted in this post:
http://forum.square-enix.com/ffxiv/t...RV#post2044489

Tracing route to 199.91.189.31 over a maximum of 30 hops

1 2 ms <1 ms 1 ms LPTSRV [10.10.100.1]
2 * * * Request timed out. (98.25.64.1, engineering investigating for residential in Florence, SC--seen 1000ms+ lag spikes at times)
3 12 ms 14 ms 12 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5] (Summerville, SC... was previously Raleigh)
4 25 ms 22 ms 32 ms 24.93.64.128 (Charlotte, NC--new Gbit fiber rolled out for Central Charlotte in the last year)
5 31 ms 31 ms 29 ms 107.14.19.42 (Cary, NC-- new Gbit market opening up, AT&T awaiting local boards to approve Residential services)
6 28 ms 32 ms 30 ms ae-2-0.pr0.dca10.tbone.rr.com [66.109.6.169]
7 37 ms 33 ms 35 ms te0-16-0-23.ccr41.iad02.atlas.cogentco.com [154.54.10.209]
8 34 ms 34 ms 36 ms be2112.mpd22.dca01.atlas.cogentco.com [154.54.5.234]
9 39 ms 40 ms 42 ms be2149.ccr22.jfk02.atlas.cogentco.com [154.54.31.126]
10 44 ms 44 ms 42 ms be2106.ccr21.alb02.atlas.cogentco.com [154.54.3.50]
11 65 ms 66 ms 65 ms be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17]
12 59 ms 57 ms 62 ms 38.122.42.34
13 50 ms 44 ms 47 ms 192.34.76.10
14 47 ms 48 ms 46 ms 199.91.189.242
15 44 ms 44 ms 47 ms 199.91.189.31

Trace complete.

Eventually, they managed to reign things in a bit at that gateway as shown in the trace in this post:
http://forum.square-enix.com/ffxiv/t...=1#post2066209

Tracing route to www.google.com [74.125.131.105]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms LPTSRV [10.10.100.1]
2 34 ms 20 ms 26 ms cpe-098-025-064-001.sc.res.rr.com [98.25.64.1]
3 13 ms 12 ms 10 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 27 ms 28 ms 26 ms 24.93.64.124
5 33 ms 35 ms 30 ms 107.14.19.20
6 31 ms 31 ms 30 ms ae-0-0.pr0.dca20.tbone.rr.com [66.109.6.183]
7 29 ms 30 ms 61 ms 74.125.49.181
8 30 ms 46 ms 32 ms 209.85.252.46
9 32 ms 30 ms 30 ms 72.14.236.148
10 41 ms 44 ms 49 ms 72.14.234.168
11 43 ms 45 ms 43 ms 209.85.251.228
12 * * * Request timed out.
13 44 ms 43 ms 43 ms vc-in-f105.1e100.net [74.125.131.105]

Trace complete.

but... it eventually came back a couple months later, as shown in this trace here:
http://forum.square-enix.com/ffxiv/t...=1#post2194801

Tracing route to 199.91.189.25 over a maximum of 30 hops

1 1 ms <1 ms <1 ms LPTSRV [10.10.100.1]
2 49 ms 23 ms 253 ms cpe-098-025-064-001.sc.res.rr.com [98.25.64.1]
3 28 ms 11 ms 15 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 25 ms 26 ms 28 ms xe-7-0-0.rlghncpop-rtr1.southeast.rr.com [24.93.64.40]
5 43 ms 30 ms 32 ms 107.14.19.44
6 31 ms 32 ms 34 ms ae1.pr1.dca10.tbone.rr.com [107.14.17.202]
7 31 ms 31 ms 32 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
8 71 ms 54 ms 65 ms if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
9 60 ms 55 ms 57 ms 64.86.85.1
10 54 ms 54 ms 57 ms if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
11 53 ms 53 ms 54 ms if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
12 55 ms 64 ms 55 ms if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
13 60 ms 52 ms 54 ms 66.198.96.50
14 55 ms 52 ms 57 ms 192.34.76.2
15 54 ms 57 ms 56 ms 199.91.189.234
16 51 ms 54 ms 56 ms 199.91.189.25

Trace complete.

***note something that changed here---my peering was switched from Cogentco to TATA (as6453). that was done by TWC, because the Cogentco lines had gone to pot on us. SE didn't do that--Time Warner did.

And then , just a short while later.. it changed again. But this time there were significant changes:
http://forum.square-enix.com/ffxiv/t...=1#post2224866

0 G75VXLAP [10.10.100.10]
1 LPTSRV [10.10.100.1]
2 cpe-066-026-112-001.sc.res.rr.com [66.26.112.1]
3 cpe-024-031-198-009.sc.res.rr.com [24.31.198.9]
4 24.93.64.134
5 bu-ether34.atlngamq46w-bcr00.tbone.rr.com [107.14.19.48]
6 107.14.19.99
7 te0-0-0-10.ccr21.atl02.atlas.cogentco.com [154.54.12.109]
8 be2050.ccr41.atl01.atlas.cogentco.com [154.54.0.165]
9 be2170.mpd21.dca01.atlas.cogentco.com [154.54.31.106]
10 be2150.mpd21.jfk02.atlas.cogentco.com [154.54.31.130]
11 be2108.ccr21.alb02.atlas.cogentco.com [154.54.3.134]
12 be2088.ccr21.ymq02.atlas.cogentco.com [154.54.43.17]
13 38.122.42.34
14 10.2.2.1
15 192.34.76.2
16 199.91.189.234
17 199.91.189.25

In case you missed it...aside from the switch back to Cogentco for peering, I also had a new gateway. TWC-SC finally gave up on the failing CMTS. I forget exactly...but I think they had moved me to Hilton Head's gateway at that time (I live in Florence).

But... we were far from being out of the woods. While things were generally good, it still had it's WTF moments, like this one here in August:
http://forum.square-enix.com/ffxiv/t...=1#post2359091

Tracing route to 199.91.189.30 over a maximum of 30 hops

0 MJ14336 [10.10.100.2]
1 LPTSRV [10.10.100.1]
2 cpe-066-026-112-001.sc.res.rr.com [66.26.112.1]
3 cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
5 be33.drhmncev01r.southeast.rr.com [24.93.64.180]
6 107.14.19.20
7 * ae-4-0.a0.lax91.tbone.rr.com [66.109.1.113]
8 ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
9 if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
10 64.86.85.1
11 if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
12 if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
13 if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
14 66.198.96.50
15 192.34.76.2
16 199.91.189.234
17 199.91.189.30

Yes... that is right... I was getting shot over to Southern California from South Carolina trying to get to Montreal. It wasn't perfect... but was better than dealing with some downed nodes here on the Eastern Seaboard at the time. Again, Time Warner was making this decision...in an effort to stay ahead of the congested corridors they were finding.

Yes... it's been a long road, and we still weren't there yet---but it was getting progressively better. Eventually, we hit pay-dirt, as demonstrated with the trace in this post in October:
http://forum.square-enix.com/ffxiv/t...=1#post2499951

Tracing route to 199.91.189.30 over a maximum of 30 hops

1 2 ms 1 ms <1 ms LPTSRV [10.10.100.1]
2 37 ms 26 ms 28 ms cpe-066-026-112-001.sc.res.rr.com [66.26.112.1]
3 17 ms 24 ms 29 ms cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
4 13 ms 16 ms 14 ms clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
5 28 ms 25 ms 27 ms be33.drhmncev01r.southeast.rr.com [24.93.64.180]
6 32 ms 34 ms 35 ms 107.14.19.20
7 33 ms 43 ms 33 ms so-1-1-1.c1.buf00.tbone.rr.com [66.109.1.113]
8 32 ms 31 ms 32 ms ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
9 62 ms 64 ms 61 ms if-11-2.tcore2.NJY-Newark.as6453.net [216.6.87.138]
10 62 ms 76 ms 62 ms if-4-4.tcore2.NYY-New-York.as6453.net [66.198.111.18]
11 59 ms 60 ms 62 ms if-12-6.tcore1.CT8-Chicago.as6453.net [216.6.99.46]
12 58 ms 61 ms 60 ms if-22-2.tcore2.CT8-Chicago.as6453.net [64.86.79.1]
13 60 ms 69 ms 61 ms if-3-2.tcore1.W6C-Montreal.as6453.net [66.198.96.45]
14 59 ms 73 ms 61 ms 66.198.96.50
15 62 ms 62 ms 64 ms 192.34.76.2
16 58 ms 59 ms 60 ms 199.91.189.234
17 62 ms 62 ms 59 ms 199.91.189.30

Trace complete.

It still has it's questionable responses...and eventually some of them evened out. They continued to actively monitor the routes for a while. Periodically my modem would reboot and the route would change between Level3, Cogent, and TATA. Sometimes it would change up 2 or 3 times in the same week, sometimes it would be 3 weeks before a change. But it was ALWAYS Time Warner working on my behalf...and always them resolving my problems with the game. The ONLY time we involved SE with the process is when we captured a problem at one of Ormuco's VLAN's, and that was just to include them with the communications to Ormuco about the problem just in case we needed the extra push to get Ormuco to take action in resolving the 250ms+ spikes we had detected at that point in the route after we had cleaned up everything else in between. That issue was handled within a few days and never reared it's head again. Since then, it has ben 100% on Time Warner fixing any issues I have. Most times automatically, but once in a while I would catch the signs first and forward them a snapshot--sometimes it was handled the same night, or if it was the weekend it might take until Monday night when I came home from work before I saw improvement.

Barring the few times it was in fact announced to be server side issues by SE, it has ALWAYS been a change in how I was routed that resolved my connectivity/stability issues with the game. And that was ALWAYS handled by going through my ISP's Tier3 support team first--and NOT SE.

**Alexika** · 07-29-2015 08:53 AM

Originally Posted by Alexika

Raist, at first I was really thinking you may be right, but I don't think our ISP is to blame at all. I have done numerous long term pings now to my server and the problem does not arise until it leaves my ISPs network. In fact, the majority of my packet loss is actually once it hits SEs network. I am starting to believe that SE is not paying for enough bandwidth.

I thought I was seeing issues there, but it turns out it is just an anti-DDoS feature. Want the MTR I am running right now?

Code:

|------------------------------------------------------------------------------------------|

|                                      WinMTR statistics                                   |

|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

|          Wireless_Broadband_Router.home -    1 | 1060 | 1058 |    0 |    4 |  473 |    2 |

|lo0-100.PRVDRI-VFTTP-306.verizon-gni.net -    0 | 1068 | 1068 |    4 |   10 |  428 |    6 |

|  T0-2-0-9.PRVDRI-LCR-22.verizon-gni.net -    0 | 1068 | 1068 |    4 |   10 |  422 |    8 |

|  xe-1-0-8-0.BOS-BB-RTR2.verizon-gni.net -    0 | 1068 | 1068 |    6 |   24 |  428 |    7 |

|xe-4-1-0-0.NY325-BB-RTR2.verizon-gni.net -    0 | 1068 | 1068 |   17 |   27 |  461 |   21 |

|                0.ae7.BR1.NYC1.ALTER.NET -    0 | 1068 | 1068 |   15 |   21 |  410 |   17 |

|                   No response from host -  100 |  213 |    0 |    0 |    0 |    0 |    0 |

|      ae-11-11.car2.Montreal2.Level3.net -    1 | 1053 | 1049 |   56 |   89 |  652 |  108 |

|      ae-11-11.car2.Montreal2.Level3.net -    1 | 1052 | 1048 |   56 |   89 |  620 |  270 |

|   ORMUCO-COMM.car2.Montreal2.Level3.net -    1 | 1041 | 1034 |   56 |   63 |  534 |   60 |

|                            192.34.76.10 -   13 |  719 |  632 |   68 |   78 |  534 |   72 |

|                          199.91.189.242 -   15 |  682 |  585 |    0 |   78 |  492 |   74 |

|                           199.91.189.33 -   17 |  645 |  539 |    0 |   81 |  503 |   75 |

|________________________________________________|______|______|______|______|______|______|

   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

**Raist** · 07-29-2015 09:33 AM

Originally Posted by Alexika

I thought I was seeing issues there, but it turns out it is just an anti-DDoS feature. Want the MTR I am running right now?

Code:

|------------------------------------------------------------------------------------------|

|                                      WinMTR statistics                                   |

|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

|          Wireless_Broadband_Router.home -    1 | 1060 | 1058 |    0 |    4 |  473 |    2 |

|lo0-100.PRVDRI-VFTTP-306.verizon-gni.net -    0 | 1068 | 1068 |    4 |   10 |  428 |    6 |

|  T0-2-0-9.PRVDRI-LCR-22.verizon-gni.net -    0 | 1068 | 1068 |    4 |   10 |  422 |    8 |

|  xe-1-0-8-0.BOS-BB-RTR2.verizon-gni.net -    0 | 1068 | 1068 |    6 |   24 |  428 |    7 |

|xe-4-1-0-0.NY325-BB-RTR2.verizon-gni.net -    0 | 1068 | 1068 |   17 |   27 |  461 |   21 |

|                0.ae7.BR1.NYC1.ALTER.NET -    0 | 1068 | 1068 |   15 |   21 |  410 |   17 |

|                   No response from host -  100 |  213 |    0 |    0 |    0 |    0 |    0 |

|      ae-11-11.car2.Montreal2.Level3.net -    1 | 1053 | 1049 |   56 |   89 |  652 |  108 |

|      ae-11-11.car2.Montreal2.Level3.net -    1 | 1052 | 1048 |   56 |   89 |  620 |  270 |

|   ORMUCO-COMM.car2.Montreal2.Level3.net -    1 | 1041 | 1034 |   56 |   63 |  534 |   60 |

|                            192.34.76.10 -   13 |  719 |  632 |   68 |   78 |  534 |   72 |

|                          199.91.189.242 -   15 |  682 |  585 |    0 |   78 |  492 |   74 |

|                           199.91.189.33 -   17 |  645 |  539 |    0 |   81 |  503 |   75 |

|________________________________________________|______|______|______|______|______|______|

   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

O M G.

It is staring us right in the face. Practically screaming at you.

Even if you want to write off the massive lag spike and lost packets on your local network (which you shouldn't--it is after all the first link in the chain and can affect everything after)...it looks like jitter may be on the high side with Verizon. Then it goes bonkers at Level3.

Based on the data you have presented, you appear to have networking issues that would have an impact on the most perfectly tuned server.

Even if the 600+ spikes were a once-only fluke spike at each of those hops, Level3 is running 56 to 108 with an average of 89 on one hop, and then 56 to 27-0 with an average of 89 at another. That is NOT acceptable. And imagine that... it is LEvel3's car2 hops in Montreal---notorious for being flakey as all get out. They get reported continuously all over the place for a variety of service issues.

Verizon is keeping you on that troubled route. They can take you off of it, just like Time Warner does for me on a regular basis... as demonstrated in the edit I made in my previous post.

**Alexika** · 07-29-2015 09:39 AM

Originally Posted by Raist

O M G.

It is staring us right in the face. Practically screaming at you.

Even if you want to write off the massive lag spike and lost packets on your local network (which you shouldn't--it is after all the first link in the chain and can affect everything after)...it looks like jitter may be on the high side with Verizon. Then it goes bonkers at Level3.

Based on the data you have presented, you appear to have networking issues that would have an impact on the most perfectly tuned server.

I fix cars not networks. You might as well speak in Egyptian, because that would mean more to me than anything you just said. Who has networking issues? What kind of issues? How did you determine that? What the heck is jitter? How do I get that fixed? What do I say to the monkey on the phone at Verizon to get them to stop blowing me off?

**Raist** · 07-29-2015 09:55 AM

As noted in Blizzard's tracert guide that I keep referring people to, the response times should be tight. There should not be a massive variance between the times at the same hop. That is a big warning sign that something is going bad around that point of the route--could be signalling issue, or over-utilization...congestion is on the rise and their is potential for lost/delayed/retransmitted packets because of it. If you see intermittent * events at one hop, that means you lost packets. Again...often a sign of an overloaded network segment or other technical difficulties are negatively impacting the session. That is part of the problem with using some tools like WinMTR... you aren't able to get a better picture of just where the numbers actually stand. Tracert and ping are the more popular tools--simple, quick snapshots that allow you to better track the numbers to see just what/where the anomalies are rearing their ugly heads.

Basically, you should NOT see a swing of even 50% across the response times at one hop. Granted, depending on what the norm is you can still manage with a high variance, but if it jumps by 100% you are pretty much looking at trouble...and in your example you go beyond even that point.

Think of it like reading your O2 sensor data. If you see the downstream sensor bouncing all over the map from extremely low to extremely high in an erratic fashion...it sets off a red flag for you to take a closer look at your exhaust system and such.

Just for some recent examples, using tracert as described in that blogpost:

This is a trace from the other night when Time Warner, TATA, Level3, Verizon and others were reporting problems in NY/NJ, Atlanta, Ashburn, Nashville, Memphis, and Austin. Things were getting choppy in the game for me, but it was still playable because I am in SC and was only mildly affected by Ashburn, but it was frustrating when you are used to smooth gameplay--for others it was completely debilitating because they were getting a double/triple whammy along the way:

Code:

Tracing route to neolobby02.ffxiv.com [199.91.189.74]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  LPTSRV [10.10.100.1]
  2    40 ms    13 ms    18 ms  cpe-75-176-160-1.sc.res.rr.com [75.176.160.1]
  3    23 ms    31 ms    33 ms  cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
  4    14 ms    15 ms    14 ms  clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
  5    26 ms    26 ms    26 ms  be33.drhmncev01r.southeast.rr.com [24.93.64.180]
  6    33 ms    34 ms    90 ms  bu-ether35.asbnva1611w-bcr00.tbone.rr.com [107.14.19.42]
  7    31 ms    29 ms    62 ms  0.ae2.pr1.dca10.tbone.rr.com [107.14.17.204]
  8    53 ms    48 ms    51 ms  ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
  9   133 ms   155 ms    74 ms  if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
 10    62 ms    62 ms    70 ms  64.86.85.1
 11   175 ms   147 ms   173 ms  if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
 12    66 ms    73 ms    70 ms  if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
 13    65 ms    75 ms    80 ms  if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
 14    75 ms    76 ms    78 ms  66.198.96.50
 15    79 ms    82 ms    80 ms  192.34.76.2
 16    79 ms    78 ms    78 ms  199.91.189.234
 17    75 ms    79 ms    78 ms  199.91.189.74

Trace complete.

Now look at it tonight, where things are running considerably more smoothly (detected a slight stutter once in a while, but no rubberbanding or big skips):

Code:

Tracing route to neolobby02.ffxiv.com [199.91.189.74]
over a maximum of 30 hops:

  1     1 ms     1 ms    <1 ms  LPTSRV [10.10.100.1]
  2    29 ms    23 ms    24 ms  cpe-75-176-160-1.sc.res.rr.com [75.176.160.1]
  3    25 ms    31 ms    31 ms  cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
  4    12 ms    14 ms    15 ms  clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
  5    26 ms    26 ms    26 ms  be33.drhmncev01r.southeast.rr.com [24.93.64.180]
  6    31 ms    31 ms    35 ms  bu-ether35.asbnva1611w-bcr00.tbone.rr.com [107.14.19.42]
  7    31 ms    30 ms    44 ms  0.ae2.pr1.dca10.tbone.rr.com [107.14.17.204]
  8    60 ms    55 ms    72 ms  ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
  9    70 ms    74 ms    71 ms  if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
 10    67 ms    69 ms    67 ms  64.86.85.1
 11    71 ms    78 ms    79 ms  if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
 12    68 ms    75 ms    82 ms  if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
 13    74 ms    75 ms    72 ms  if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
 14    77 ms    73 ms    66 ms  66.198.96.50
 15    72 ms    69 ms    68 ms  192.34.76.2
 16    65 ms    70 ms    70 ms  199.91.189.234
 17    58 ms    60 ms    69 ms  199.91.189.74

Trace complete.

**Alexika** · 07-29-2015 10:04 AM

They are sending me a new router for tomorrow, but I don't see how that will fix this.

**TheDuxun1977** · 09-04-2015 04:14 PM

Originally Posted by Alexika

They are sending me a new router for tomorrow, but I don't see how that will fix this.

try doing a system restore to a point when you could log in hope that helps

Thread: Error code 2002 and 90000

Thread Tools

Search Thread

Display

Hybrid View