UDP Throttling

[MikeTurner]

What is the Blizzard IP address for me to run this test?

[MikeTurner]

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| No response from host - 100 | 55 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 55 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 55 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 54 | 0 | 0 | 0 | 0 | 0 |
| 103.4.115.248 - 0 | 54 | 54 | 7 | 8 | 11 | 8 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )

[Dazzled]

I haven't seen you here for a while Mike. The avatar is way out of date.

The WoW Oceania IP in your mtr is local, even though it doesn't answer a reverse host lookup. mtr uses ICMP, the same as Windows tracert, and the server does respond to an ICMP traceroute.

When I run a normal Linux traceroute on UDP, I get

Code: Select all

$ traceroute 103.4.115.248
traceroute to 103.4.115.248 (103.4.115.248), 30 hops max, 40 byte packets
 1  192.168.1.1 (192.168.1.1)  2.242 ms  2.582 ms  2.927 ms
 2  * * *
 3  10.1.23.136 (10.1.23.136)  172.316 ms  172.552 ms  172.906 ms
 4  55497.syd.equinix.com (202.167.228.99)  44.512 ms  46.469 ms  46.831 ms
 5  55497.syd.equinix.com (202.167.228.99)  48.785 ms !X * *

The next destination hop will not reply - !X = "communication administratively prohibited", that is, it has been deliberately set to ignore my packet.

Since it will respond to ICMP, I ran mtr, and lost no packets, with a different result.

Code: Select all

Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                     Packets               Pings
 Host                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. Gate.home                       0.0%    91    0.6   0.6   0.6   1.3   0.1
 2. ???
 3. 10.1.23.136                     0.0%    90   31.2  41.1  30.0 271.2  35.9
 4. 55497.syd.equinix.com           0.0%    90   31.7  31.1  30.2  32.4   0.5
 5. 103.4.115.248                   0.0%    90   30.4  31.3  29.9  33.2   0.7

[MikeTurner]

Ok, Dazzled, I have no idea what 90% of your post means. But here is a Traceroute in windows

Tracing route to 103.4.114.248 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 7 ms 7 ms 7 ms 203.1.233.220.static.exetel.com.au [220.233.1.203]
3 7 ms 7 ms 7 ms 10.1.21.45
4 8 ms 7 ms 7 ms as55497.nsw.ix.asn.au [218.100.52.65]
5 7 ms 7 ms 7 ms 10.106.67.66
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
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.

C:\Users\Mike>

[Dazzled]

Mike, I posted a different result, from an ADSL service, in the hope that someone would spot the reason for the difference.

Windows uses the ICMP protocol for tracert. Linux, by default uses the UDP protocol, but can also send ICMP and TCP protocol trace packets. The WoW server has a firewall set to refuse a UDP traceroute. It is similarly set for a TCP traceroute.

However my service can get a response to an ICMP trace, and also to mtr which uses the same protocol. That's where we differ. Your tracert didn't get a reply.

The server IP doesn't reverse look up from the host command, but I was able to establish that it is here.

Interestingly when the simple Linux ICMP tracepath targets the WoW server IP, it responds "Host unreachable". Traceroute with the ICMP argument works:

Code: Select all

$ sudo traceroute -I 103.4.115.248
traceroute to 103.4.115.248 (103.4.115.248), 30 hops max, 40 byte packets
 1  192.168.1.1 (192.168.1.1)  1.255 ms  1.593 ms *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * 103.4.115.248 (103.4.115.248)  30.812 ms  32.923 ms

[cong]

So has this issue been fixed? I'm having the exact same problem with League of Legends where it constantly disconnects then reconnects. Haven't been able to play for the past 3 weeks. Thinking of changing back to TPG.....

[MikeTurner]

Is there any response to this. I supplied the requested tests above.

[angelos]

Is there any response to this. I supplied the requested tests above.

We will get the results looked into and get back to you.

[MikeTurner]

Hi,

I'm still waiting for a response.

[ShaminG]

Hi,

I'm still waiting for a response.

Please stand by. We are working on this as a matter of highest priority.

[MikeTurner]

Hi,

Is there any movement on this? "Highest priority" isnt seeing much action.

My gaming is frustrating. Yesterday it was non-existent. I lost internet for 4-5 hours yesterday.

I was kicked from D3 maybe 20 times without warning. And a couple of times this morning.

I expected the NBN to be at least on par with adsl, but in my experience, it's far worse.

[angelos]

Hi,

Is there any movement on this? "Highest priority" isnt seeing much action.

My gaming is frustrating. Yesterday it was non-existent. I lost internet for 4-5 hours yesterday.

I was kicked from D3 maybe 20 times without warning. And a couple of times this morning.

I expected the NBN to be at least on par with adsl, but in my experience, it's far worse.

This is being looked into. However an email has been sent to you with some information that is required. Please respond to it with the requested info and we will pass this on to the team who is looking into this.

[wardrop]

I'm assuming this is still happening? I'm getting UDP packet loss which is preventing me from connecting to a game server, in this case, iracing. If I tether the internet from my phone via Telstra NextG, it works, so it's definitely not a server-side issue on iracing's end. I don't seem to experience the issue every night, but when I do, it's normally after 9pm AEST. Very annoying to say the least.

The others in this thread have stopped complaining so I'm assuming you've done a per-customer fix? Can I get the same fix applied if that is the case?

To add a general comment. Internet performance always seems poor after 9pm, especially internationally. I had issue connecting to an iracing server last night, and that was in the netherlands, so it's probably a double whammy of poor international performance and UDP packet loss.

[angelos]

I'm assuming this is still happening? I'm getting UDP packet loss which is preventing me from connecting to a game server, in this case, iracing. If I tether the internet from my phone via Telstra NextG, it works, so it's definitely not a server-side issue on iracing's end. I don't seem to experience the issue every night, but when I do, it's normally after 9pm AEST. Very annoying to say the least.

The others in this thread have stopped complaining so I'm assuming you've done a per-customer fix? Can I get the same fix applied if that is the case?

To add a general comment. Internet performance always seems poor after 9pm, especially internationally. I had issue connecting to an iracing server last night, and that was in the netherlands, so it's probably a double whammy of poor international performance and UDP packet loss.

It could most likely be an issue with the particular international server. Please PM your service number so we could try and look into this further.

[Roy]

I'm getting constant packet loss in games and voice programs as well, makes it very frustrating to play games.
Is this due to UDP throttling from exetel?
When i try to ping google in cmd i get alot of "request timed out".