Bogus IP Header Length Packet Sniff - Page 2

towbes · #1 06-13-2015, 02:18 PM

What would case this to happen? All of these are in my EQ install folder. It looks to me like I'm missing a packet or two in the zoning process and it's throwing off the entire load, anyone else have dbg logs from similar circumstances?

**Haynar** · #2 06-16-2015, 03:26 PM

Too many missing files probably slowing down connecting too much.

H

demonstar55 · #3 06-16-2015, 03:29 PM

Quote:

2015-06-13 11:16:32 Could not connect to 108.61.129.184:7022 [clientisconnectReasonConnectFail,serverisconne ctReasonNone]. Negotiation count: 595.

That's the message the client gives when it timesout negotiating the session. For some reason your client never saw the reply from P99 and quit. The rest of the log is 100% irrelevant.

towbes · #4 06-16-2015, 05:49 PM

Quote:

Originally Posted by demonstar55 [You must be logged in to view images. Log in or Register.]

That's the message the client gives when it timesout negotiating the session. For some reason your client never saw the reply from P99 and quit. The rest of the log is 100% irrelevant.

I'll focus more on packet logs and see if anything turns up.

Wisteso · #5 06-16-2015, 06:57 PM

towbes, I've been having a very similar issue as you since yesterday. Took me about 20 attempts to get logged in on my character. NGREP showed that my packet loss was significant. Sometimes about 30% of the expected UDP packets never arrived.

I've been having the issue with both P99 and the loginserver, which suggests its not P99's issue, but instead possibly due to XO.net or NTT.net.

Failure packet dump (gist.github.com)
Success packet dump (gist.github.com)

Heroes of the Storm has been having widespread problems for users that route through XO.net so this might be another game that is affected by XO's shitty network nodes.
http://us.battle.net/heroes/en/forum/topic/18000364944
http://us.battle.net/heroes/en/forum...6329?page=2#23 (blue post on the issue)

Can you paste your results from WinMTR using host 66.55.145.2 to this thread?

Mine for example are...

Code:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                                  lolwat -    0 |  934 |  934 |    0 |    0 |    1 |    0 |
|           cpe-65-31-128-1.wi.res.rr.com -    3 |  934 |  912 |    9 |   76 | 4599 |   22 |
|       tge7-1.brfdwifb02h.midwest.rr.com -    0 |  934 |  934 |    8 |   11 |   74 |    8 |
|   tge1-6-0-9.gnfdwibb01r.midwest.rr.com -    0 |  934 |  934 |   12 |   16 |   37 |   14 |
|bu-ether16.chcgildt87w-bcr00.tbone.rr.com -   0 |  934 |  934 |   14 |   18 |   38 |   19 |
|            0.ae1.pr1.chi10.tbone.rr.com -    0 |  934 |  934 |   13 |   18 |   82 |   18 |
|                            216.1.94.145 -    0 |  934 |  934 |   13 |   18 |   76 |   17 |
|              207.88.15.90.ptr.us.xo.net -    1 |  934 |  931 |   13 |   17 |   52 |   15 |
|              206.111.2.65.ptr.us.xo.net -    0 |  934 |  934 |   14 |   17 |   49 |   31 |
|     ae-7.r20.chcgil09.us.bb.gin.ntt.net -    0 |  934 |  934 |   14 |   19 |  100 |   15 |
|     ae-5.r23.nycmny01.us.bb.gin.ntt.net -   17 |  934 |  780 |   36 |   42 |  131 |   52 |
|     ae-1.r06.nycmny01.us.bb.gin.ntt.net -    0 |  934 |  934 |   36 |   40 |   71 |   37 |
|  ae-1.choopa.nycmny01.us.bb.gin.ntt.net -    6 |  934 |  887 |   37 |   45 |  138 |   45 |
|                           108.61.244.50 -    5 |  934 |  891 |   37 |   42 |  206 |   38 |
|                   No response from host -  100 |  934 |    0 | 5000 |    0 |    0 |    0 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.91 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Wisteso · #6 06-16-2015, 09:37 PM

Would like to add that I suspected XO.NET to be the root issue. NordVPN has a server (US2) which allows me to entirely bypass ptr.us.xo.net with a slightly longer route. (still routes through ntt.net).

Issue resolved immediately after that. My ping is 15ms higher, sure, but I'm not disconnecting during almost every attempt to connect to 66.55.145.2; virtually zero issues at all so far.

towbes · #7 06-17-2015, 08:10 AM

Wisteso, thank you for that information, here's a dump of WinMTR, same exact servers, although I obviously have some issues before it crosses the Pacific Ocean as well. But having 27% loss at a server right before the gameserver is probably not helpful at all.

Code:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                              me -    0 |   69 |   69 |    1 |    1 |    5 |    1 |
|                           modem -    0 |   70 |   70 |    5 |    8 |   17 |    6 |
|                              10.80.16.1 -    6 |   58 |   55 |    8 |   13 |   20 |   14 |
|                          203.81.171.243 -   14 |   46 |   40 |    0 |   13 |   20 |   14 |
|                          203.81.171.255 -    6 |   58 |   55 |    8 |   16 |   81 |   13 |
|                             10.9.10.187 -   10 |   50 |   45 |    7 |   13 |   26 |   12 |
|                             10.9.10.201 -   14 |   46 |   40 |    7 |   15 |   24 |   15 |
|                          203.81.170.241 -    8 |   56 |   52 |    7 |   13 |   23 |    8 |
|                            203.215.62.5 -   13 |   47 |   41 |    8 |   16 |   55 |   10 |
|                           203.215.62.25 -    8 |   54 |   50 |    8 |   14 |   24 |   14 |
|                          203.215.60.218 -   10 |   50 |   45 |   15 |   24 |  210 |   23 |
|                            116.51.31.29 -   10 |   51 |   46 |   64 |   68 |   77 |   71 |
|    ae-10.r20.sngpsi05.sg.bb.gin.ntt.net -    8 |   54 |   50 |   65 |   73 |  128 |   70 |
|     ae-8.r22.snjsca04.us.bb.gin.ntt.net -   18 |   41 |   34 |  243 |  249 |  313 |  246 |
|     ae-7.r23.asbnva02.us.bb.gin.ntt.net -    8 |   55 |   51 |  298 |  302 |  309 |  302 |
|     ae-0.r22.asbnva02.us.bb.gin.ntt.net -    8 |   54 |   50 |  303 |  309 |  319 |  310 |
|     ae-8.r23.nycmny01.us.bb.gin.ntt.net -   10 |   50 |   45 |    0 |  317 |  333 |  315 |
|     ae-1.r06.nycmny01.us.bb.gin.ntt.net -   27 |   34 |   25 |  309 |  313 |  322 |  313 |
|  ae-1.choopa.nycmny01.us.bb.gin.ntt.net -    8 |   54 |   50 |  316 |  335 |  367 |  334 |
|                           108.61.244.50 -    6 |   58 |   55 |  308 |  315 |  331 |  315 |
|                   No response from host -  100 |   14 |    0 |    0 |    0 |    0 |    0 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

towbes · #8 06-17-2015, 08:32 AM

And another when I utilize Singapore VPN, now it's 87% loss at that ae-8 node in NYC. However I am connected and successfully zoned twice. Still having some crashes on zone, and timing out past char select, packets showing my client sending data to server, but getting nothing back.

Code:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                                 singapore -    7 |  158 |  148 |   58 |   73 |  344 |   67 |
|                         103.254.153.125 -    7 |  154 |  144 |   58 |   73 |  195 |   64 |
|       xe-0-0-3.cr01.sin-11.leaseweb.net -    8 |  151 |  139 |   59 |   71 |  344 |   65 |
|      te0-0-0-6.br02.sin-10.leaseweb.net -    6 |  162 |  153 |   58 |   72 |  195 |   67 |
|     xe-0-3-3.singapore2.sin.seabone.net -    4 |  174 |  168 |   58 |   81 |  286 |   65 |
|    ntt-verio.singapore2.sin.seabone.net -    8 |  150 |  138 |   58 |   73 |  204 |   64 |
|     ae-1.r20.sngpsi05.sg.bb.gin.ntt.net -   16 |  122 |  103 |   58 |   73 |  301 |   66 |
|     ae-8.r22.snjsca04.us.bb.gin.ntt.net -   11 |  138 |  123 |  238 |  248 |  423 |  242 |
|     ae-7.r23.asbnva02.us.bb.gin.ntt.net -    8 |  151 |  139 |  293 |  308 |  670 |  299 |
|     ae-0.r22.asbnva02.us.bb.gin.ntt.net -   11 |  138 |  123 |  300 |  311 |  491 |  307 |
|     ae-8.r23.nycmny01.us.bb.gin.ntt.net -   87 |   44 |    6 |  311 |  331 |  417 |  417 |
|     ae-1.r06.nycmny01.us.bb.gin.ntt.net -   10 |  142 |  128 |  299 |  316 |  524 |  300 |
|  ae-1.choopa.nycmny01.us.bb.gin.ntt.net -    9 |  146 |  133 |  319 |  343 |  553 |  324 |
|                   No response from host -  100 |   39 |    0 |    0 |    0 |    0 |    0 |

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

Ruien · #9 06-19-2015, 11:07 AM

Guys,

There are idiosyncrasies about the way that MTR (and, by extension, WinMTR) reports packet loss. 87% packet loss to ae-8.r23.nycmny01.us.bb.gin.ntt.net (129.250.2.148) means nothing if you consistently get 9% to a node past that. It just means that the router is de-prioritizing ICMP ECHO but forwarding normally.

Here's my MTR report to 66.55.145.2:

Code:

root@RyanDesktop:~# mtr --no-dns -r -w -c100 --interval=0.2 -s 56 66.55.145.2
Start: Fri Jun 19 22:50:47 2015
HOST: RyanDesktop    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1     0.0%   100    0.2   0.2   0.2   0.3   0.0
  2.|-- 100.68.128.1    0.0%   100   21.0  10.2   1.2  96.8  15.7
  3.|-- 61.188.202.181 35.0%   100    5.3   4.4   3.1  44.3   5.1
  4.|-- 171.208.203.13  0.0%   100   11.1  12.6   9.8  45.2   3.5
  5.|-- 202.97.36.225   0.0%   100   44.8  47.1  44.7  49.6   1.0
  6.|-- 202.97.33.238  86.0%   100   44.6  45.0  44.4  45.7   0.0
  7.|-- 202.97.60.146  80.0%   100   46.5  52.3  46.0  80.4  11.4
  8.|-- 202.97.58.230   2.0%   100  409.3 392.2 372.9 416.9  11.5
  9.|-- 202.97.50.22    8.0%   100  216.4 217.8 214.9 220.1   1.1
 10.|-- 129.250.9.9     8.0%   100  200.6 198.7 196.8 200.6   0.4
 11.|-- 129.250.5.69    1.0%   100  218.5 220.1 215.7 249.8   5.5
 12.|-- 129.250.3.188   5.0%   100  276.8 277.5 275.4 291.4   2.3
 13.|-- 129.250.2.148  75.0%   100  314.5 291.7 288.6 314.5   6.9
 14.|-- 129.250.4.149   1.0%    99  277.0 276.7 274.1 279.5   0.8
 15.|-- 128.241.2.250   2.0%    99  285.0 292.7 283.7 349.5  11.2
 16.|-- ???            100.0    99    0.0   0.0   0.0   0.0   0.0

We know that 66.55.145.2 doesn't respond to ICMP and speculate that it's hop 16. We can't know that for sure, since it could be 128.241.2.250 refusing to forward upstream ICMP to us. But presumably once we've arrived at 129.250.* network there won't be much additional loss to 66.55.145.2, so the average packet loss to the most reliable node in this network is our most accurate assessment of the packet loss.

I'll just use the farthest visible hop as it's about the same:

Code:

root@RyanDesktop:~# ping -i 0.2 -c 1000 -q 128.241.2.250
PING 128.241.2.250 (128.241.2.250) 56(84) bytes of data.

--- 128.241.2.250 ping statistics ---
1000 packets transmitted, 996 received, 0% packet loss, time 200776ms
rtt min/avg/max/mdev = 271.787/301.339/509.617/37.038 ms, pipe 3

So the real packet loss here is 0.4%.

The problems I am seeing are not caused by packet loss to the server. According to Wireshark, both Emerald Jungle and Trakanon's Teeth use 66.55.145.2, and I have problems only in TT. If I had a terrible connection to that IP, then I'd see the same issues in both zones.

Wisteso, you may have slightly more packet loss than I do, but not significantly so.

towbes, you are seeing packet loss issues, but the problem shows up very early in your network route. Run some manual pings like I did in my example; are you seeing any consistently low loss to any hops along the way? Either you're looking at an anomaly (maybe your VPN hates ICMP) or else you're getting loss at the third hop. Try pinging with TCP to an open port with tcping if you have access to linux.

Proven Guilty · #10 06-25-2015, 08:09 PM

Just to chime in, the troubleshooting information Wisteso and Ruien between ICMP prioritization, MTR returned results, and using TCP ports to 'ping' are all accurate.

In the problematic MTR, I see there are issues before traffic even reached a public IP address (using a 10.x.x.x subnet). It's very likely that the issue was always within the local area network.