Bogus IP Header Length Packet Sniff - Page 2

Wisteso · #11 06-16-2015, 03:00 PM

Quote:

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

TBH man, looking through that dump.. It looks like its trying to load the spell particles but is unable to find / load them, and that's what is closing the connection.

I doubt that's the issue. Its far more likely that he just pasted an irrelevant portion of the log. His next post did have relevant errors.

towbes, if there's an issue it's likely nothing you can fix on your system. Its likely to either be an EQEmu bug or an issue with your ISP / your ISP's ISP (Tier1 networks)

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

Too many missing files probably slowing down connecting too much.

H

demonstar55 · #13 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 · #14 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 · #15 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 · #16 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 · #17 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 · #18 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 · #19 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.

towbes · #20 06-19-2015, 10:46 PM

I had the same issue with TT, after about 30s in zone ping spiked up to 4k then eventually d/ced me. I was however able to log back in eventually and make my way to the seb orb and zone in. That makes sense on the MTR analysis. I know I'm seeing packet loss, I'm not questioning that. I just think the server is severing the connection too quickly, and the client is missing the message that the connection was severed so it just keeps trying. What's especially frustrating is circumstances where the character client never loads into a zone (just sits at the previous zone screen with the busy cursor), however when you manually close the client and attempt to log back in, it says you still have a character in zone. So what's happening there? Why isn't the client being sent messages telling it that it zoned? Probably the only way to pinpoint the issue is to setup a local server, and monitor the connection to that local server to find out what it's supposed to look like, and use something like burpsuite to kill certain packets and find that one that is causing the problems. (Not even sure it would be capable of performing quickly enough to allow a game session to occur though, just theorizing)