Page 1 of 1

Traceroute to new server

Posted: April 11th, 2018, 4:00 pm
by Mali Mrav
dont understand

Tracing route to 47.190.52.113 over a maximum of 30 hops

1 2 ms 2 ms 2 ms Gateway.Home [192.168.1.1]
2 24 ms 24 ms 65 ms 85.114.32.150
3 22 ms 22 ms 21 ms 85.114.32.149
4 31 ms 31 ms 30 ms 80.157.206.5
5 42 ms 43 ms 42 ms 80.156.160.98
6 * * * Request timed out.
7 197 ms 197 ms 197 ms 4.15.44.126
8 196 ms 195 ms 195 ms ae3---0.scr01.dlls.tx.frontiernet.net [74.40.4.1
3]
9 199 ms 199 ms 199 ms be10---0.lcr21.dlls.tx.frontiernet.net [74.40.3.
18]
10 194 ms 195 ms 195 ms 172.102.51.237
11 207 ms 199 ms 207 ms 47.190.52.113

Trace complete.

Re: Traceroute to new server

Posted: April 11th, 2018, 5:54 pm
by Trench
From a high-level view, this trace looks like what we would expect when coming from Croatia to the US. The traffic went from your modem, through two hops inside Croatia, then through two hops in Germany, then across the Atlantic Ocean, and into the Level 3 backbone carrier within the USA, and then though three hops inside Texas before reaching the EA117 server. The only "major jump in ping" is the one you would pretty much expect; crossing the Atlantic:
tracert dc.ea117.com wrote:Tracing route to 47.190.52.113 over a maximum of 30 hops

1 2 ms 2 ms 2 ms Gateway.Home [192.168.1.1] (your modem at your home)
2 24 ms 24 ms 65 ms 85.114.32.150 (Optima Telekom, Croatia)
3 22 ms 22 ms 21 ms 85.114.32.149 (Optima Telekom, Croatia)
4 31 ms 31 ms 30 ms 80.157.206.5 (Deutsche Telekom AG, Germany)
5 42 ms 43 ms 42 ms 80.156.160.98 (Deutsche Telekom AG, Germany)
6 * * * Request timed out. (unknown router that doesn't reply to ICMP Time To Live timeout)
7 197 ms 197 ms 197 ms 4.15.44.126 (Level 3 Communications, USA)
8 196 ms 195 ms 195 ms ae3---0.scr01.dlls.tx.frontiernet.net [74.40.4.13] (Frontier Communications, Texas, USA)
9 199 ms 199 ms 199 ms be10---0.lcr21.dlls.tx.frontiernet.net [74.40.3.18] (Frontier Communications, Texas, USA)
10 194 ms 195 ms 195 ms 172.102.51.237 (Frontier Communications, Texas, USA)
11 207 ms 199 ms 207 ms 47.190.52.113 (dc.ea117.com)

Trace complete.
So you had about a 22ms ping if you had been staying inside Croatia; about a 42ms ping if you had been playing a server in Germany; a 197ms ping in order to just cross the Atlantic, and then +/-5ms to get to Texas. Meaning it took 42ms to get out of Europe, 155ms to cross the Atlantic, and then about +/-5ms inside the US to get to the EA117 server.

When looking at this trace, one thing that should catch your eye is one of the three pings sent to 85.114.32.150 inside Croatia ended up with a 65 ms round trip time instead of just 24ms. That doesn't necessarily mean there is a problem there; but it's something you would keep watching as you continue to run traceroutes, to see whether the 85.114.32.150 hop is "usually 24ms, but keeps spiking every once in a while." Since if that's happening, it's likely going to cause your Battlefield 1942 communication to spike too.

You kind of "have to" look at traceroutes using multiple examples over time. Looking at just a single trace, it's informative, but you can't really conclude where the issue is occurring, if you're seeing a possible issue. For example, there was a +45ms spike shown in just one of the round-trips for the Croatia router. Was that just a one-time anomaly? Of if you keep taking traces, will that anomaly continue to show up at exactly that same router?

When trying to interpret the numbers, you also have to keep in mind that the packet also had to still go through all the previous hops. Meaning if we were seeing a +40ms spike on a Frontier Communications hop in Texas, that might be because the Frontier Communications hop in Texas was actually overloaded or slow.

But it could also be because "at that moment, the 85.114.32.150 hop inside Croatia was spiking." Because when sending a ping to the Texas router, the traffic still has to pass through the Croatia router, and Germany, and cross the Atlantic, etc. And so the Croatia router being slow at that moment would cause the Texas ping measurement to spike, too.

So it's only by viewing multiple traceroutes, taken over time, to see where -- if anywhere -- spikes are more consistently appearing.

-Trench

Re: Traceroute to new server

Posted: April 13th, 2018, 9:42 am
by Trench
Mali Mrav wrote:Tracing route to 47.190.52.113 over a maximum of 30 hops

1 2 ms 2 ms 1 ms Gateway.Home [192.168.1.1]
2 94 ms 22 ms 38 ms 85.114.32.150
3 22 ms 24 ms 21 ms 85.114.32.146
4 40 ms 33 ms 31 ms 62.159.61.221
5 34 ms 33 ms 32 ms 80.156.160.98
6 * * * Request timed out.
7 200 ms 205 ms 203 ms 4.15.44.126
8 194 ms 193 ms 197 ms ae3---0.scr01.dlls.tx.frontiernet.net [74.40.4.13]
9 208 ms 199 ms 199 ms be10---0.lcr21.dlls.tx.frontiernet.net [74.40.3.18]
10 195 ms 195 ms 194 ms 172.102.55.109
11 206 ms 206 ms 206 ms 47.190.52.113
This second traceroute you sent again shows one of the three pings sent to the second hop ("85.114.32.150") having a higher than normal response time. The three pings sent took 94ms, then 22ms, and finally 38ms, which is pretty inconsistent for having seen this variation over a short period of time while traceroute was running.

(Your earlier traceroute had shown 24ms for the first two pings, and then 65ms for the third ping to this same router.)

If you keep seeing a lot of variation or high pings to that second hop, the implied meaning is that this is a problem for the ISP, and that this router is overloaded or having issues. Technically a problem at your modem in your home could also cause that result (i.e. the first hop looks slow because the modem delayed getting the packet out onto the Internet), but if that were the case, all of your hops would show this kind of wild variation in ping time.

So thus far, "22ms or 24ms or 38ms or 94ms" response time we're seeing for that second hop seems like it might be indicating there is an issue on the 85.114.32.150 router. I would keep taking a few more traceroutes at various times of the day to show more examples, and if the same issue continues to be occurring, then I would talk to my ISP about why one of their routers is giving such inconsistent response times.

The good news is it's at least within their network, and they have the ability to investigate and resolve this. (As opposed to if it was happening within one of the Germany networks, etc., which are outside of their control.) The question will be whether or not they're willing to investigate it...

-Trench

Re: Traceroute to new server

Posted: April 14th, 2018, 7:22 pm
by CJ (Crash)
Thanks for explaining that. That was a comprehensive answer to something I've wondered about for a while.

Re: Traceroute to new server

Posted: July 23rd, 2018, 5:39 pm
by Mali Mrav
I just was on ea and my ping was 150 then i exit and make a tracert
C:\Users\enter>tracert.exe 47.190.52.113

Tracing route to 47.190.52.113 over a maximum of 30 hops

1 4 ms 3 ms 2 ms Gateway.Home [192.168.1.1]
2 25 ms 25 ms 24 ms 85.114.32.145
3 23 ms 42 ms 43 ms 85.114.32.146
4 33 ms 32 ms 33 ms 62.159.61.221
5 65 ms 46 ms 45 ms 80.156.160.134
6 * * * Request timed out.
7 189 ms 189 ms 188 ms 4.15.44.126
8 190 ms 189 ms 190 ms ae3---0.scr02.dlls.tx.frontiernet.net [74.40.1.81]
9 197 ms 191 ms 192 ms be10---0.lcr22.dlls.tx.frontiernet.net [74.40.3.26]
10 194 ms 193 ms 204 ms 172.102.55.111
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.

Re: Traceroute to new server

Posted: July 23rd, 2018, 7:18 pm
by Trench
If you're referring to the
"11 * * * Request timed out"
...
30 * * * Request timed out"
being shown there, that is typically the symptom of "the machine that you're attempting to ping or traceroute does not respond to ICMP Echo or with ICMP Time Exceeded messages."

That can be intentional. And/or can be out of your control, if those messages are actually blocked by the ISP. I get that about 50% of the time when trying to make traceroutes back to player IP addresses, because either their ISP or their router/modem does not respond to ICMP Echo or issue ICMP Time To Live expiration messages.

But it's not supposed to be true for the EA117 server, and it hasn't been true in the past (as shown in your April 2018 traceroute results). The EA117 server is configured to allow for both ICMP Echo and ICMP Time Exceeded responses.

But I tested for myself just now and I see the same results as you do. Will have to look at it some more later when there aren't people on the server.

Lack of ICMP Echo or ICMP Time To Live Exceeded messages don't cause any kind of game problem though; just the behavior you saw when trying to use tools like PING and TRACEROUTE that depend on those specific ICMP messages.

-Trench

Re: Traceroute to new server

Posted: July 28th, 2018, 10:39 am
by Trench
I can see the ICMP packets inbound to the computer (not being blocked at the ISP), but the Windows TCPIP stack just doesn't respond.

Appears to just be something about the latest Windows updates that is making the built-in ICMP Echo rule for IPv4 no longer work correctly. The rule was still enabled on the EA117 server, just as it has always been. But regardless of already being allowed for both public and private networks; and even after disabling and re-enabling the rules; and even after deleting and re-adding the Microsoft-defined versions of these rules --- in all cases, its as though the firewall is still dropping the inbound request anyway.

Creating my own custom firewall rule for inbound ICMP on IPv4 worked right away; so it's just the built-in Microsoft rule that seems to be having some new behavior or malfunctioning. For what it's worth; ping and traceroute should work against the dc.ea117.com server itself again now.

The method used to create a custom rule was the following command line from an elevated command prompt:

Code: Select all

netsh advfirewall firewall add rule name="EA117 Custom ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allow
-Trench