61 replies to this topic

[Dude42]

Vercinaigh, on 19 May 2013 - 10:10 AM, said:

you're getting packet loss.....I've helped 5 people with this so far...all have had packet loss, even if a tiny amount. It seems this game has a strict policy on corrupted or lossed packets and instead of re-syncing you, it drops you. Hope this helps people a bit.

I'm sitting here running 16 pingtest.net tests to each and every Canadian server available. So far I'm just halfway through the second one(starting on the left). Total sent so far about 5000 packets, 0 lost. I'll continue to run these, and finishout all the Canadian servers just to be sure. If you'd be so kind as you let me in on what method you used to test for packet loss I'll be happy to test it. I've gone ahead and run ping -n 10000 to my ISP to see if I lose one. It's only at about 200(according to Ctrl+Break, lol) so thats gonna take a while, but none lost so far. I'll edit this post with the results of everything when it's done. But if you've helped 5 people, how did you resolve it? Or is just telling someone what you mean by help?

Update: FInished the pingtest.net tests. Sending 250 packets at a time(i really wish you could configure that, what a PITA), 16x per server, so 4000 packets per server to Clagary, Edmonton, Dryden, Sudbury, and Toronto. That's 20'000 packets sent. Not a single packet was lost. The ping command is still running, its at about 1100. Not a single packet lost yet. I may just cancel it at this point. Since I didn't lose one of 20k sent around the world, I doubt I'm going to lose one of 10k sent to my ISP directly. I was hopeful it was something on my end.

Edited by Dude42, 19 May 2013 - 11:07 AM.

[Lugh]

StandingCow, on 17 May 2013 - 05:37 AM, said:

I guess some stats might help find a common cause for this:
OS: Win 7 64 bit
AV: BitDefender
Connection: 55 Mb down 11 Mb up (live alone so it's not lack of bandwidth)
Motherboard:Z77 Extreme4 w/PCIE Gigabit LAN
Router:TP-LINK TL-WR1042ND (Hard wired, don't use wifi).
Cable modem:MOTOROLA SB6121

I've been supplying support tickets for this issue since it first began on 1-5-20123, that's 4 months of data provided. It's still not fixed. It isn't YOU. The problem resides with PGI's network code.

[MrVop]

Doing more and more research on this I have to agree with Lugh... My system is solid, my ping tests are more solid then expected.
A network engeneer needs to sit down and iron this out. Not much we can do on our end for the people having this issue. I have tried a lot of stuff... A LOT, but only because I happen to have hardware lying around.
Meh.... This is just Meh...

[Infernus1986]

MrVop, on 19 May 2013 - 04:55 PM, said:

Doing more and more research on this I have to agree with Lugh... My system is solid, my ping tests are more solid then expected.
A network engeneer needs to sit down and iron this out. Not much we can do on our end for the people having this issue. I have tried a lot of stuff... A LOT, but only because I happen to have hardware lying around.
Meh.... This is just Meh...

You should add a simple yes no poll to the op so we can see how many people have this bug so PGI can ignore it some more.

[Dude42]

The silence is deafening.

[Infernus1986]

Dude42, on 20 May 2013 - 08:25 AM, said:

The silence is deafening.

It hasn't been months yet
its ok im sure some one will pop in tell us to send more support tickets then lock the thread

[Dude42]

Infernus1986, on 20 May 2013 - 09:59 AM, said:

It hasn't been months yet
its ok im sure some one will pop in tell us to send more support tickets then lock the thread

How long does it have to be when you've paid for premium time? I have 14.5 days left. You think I'm gonna buy any more?

The Answer:
CGameRules::OnDisconnect: Client has disconnected: cause=eDC_ProtocolError, desc=Remote disconnected: Malformed packet
CGameClientChannel::Release

[Deathlike]

I know part of this is PGI's netcode... but I think there are other conditions that seem to cause this to happen.. like a busy network.. and some people have used some sort of VPN...

I'm not saying it is necessarily the user's fault, but you would have to do a lot of serious network troubleshooting to figure out what causes it to happen more often...

[Notick]

Infernus1986, on 20 May 2013 - 09:59 AM, said:

It hasn't been months yet
its ok im sure some one will pop in tell us to send more support tickets then lock the thread

Speak for yourself... I've been dealing with this bug for over four months. Each time my internet connection has been 'blamed' and it was brushed underneath a rug. I've called in a buddy from Comcast (my ISP) who is actually a local director of field repair - and he personally examined my lines from my home to the nodes, as well as had my lines monitored for 48 hours. I'm also a CCNP, NT+ network Tech... My Comcast buddy told me my lines are performing optimally, and have absolutely no issue other than the typical 'Peak Hour' loads.

I've done everything imaginable with my network (Including replacing all the infrastructure within my home).

Even after several re-formats and a HDD replacement, hundred of tweaks and edits to Networking Settings within windows, on my router, within my modem, and in my Firewalls, it's still happening. I've also tried it without any AV/AS installed with all windows security deactivated so there was absoultely no firewall what-so-ever possible. I've even tried directly off the modem while in this state... Still to no avail.

So... Not really sure what else to do at this point but wait until it's actually addressed/located/admitted to.

Edited by Notick, 20 May 2013 - 02:33 PM.

[StandingCow]

Notick, on 20 May 2013 - 02:20 PM, said:

Speak for yourself... I've been dealing with this bug for over four months. Each time my internet connection has been 'blamed' and it was brushed underneath a rug. I've called in a buddy from Comcast (my ISP) who is actually a local director of field repair - and he personally examined my lines from my home to the nodes, as well as had my lines monitored for 48 hours. I'm also a CCNP, NT+ network Tech... My Comcast buddy told me my lines are performing optimally, and have absolutely no issue other than the typical 'Peak Hour' loads.

I've done everything imaginable with my network (Including replacing all the infrastructure within my home).

Even after several re-formats and a HDD replacement, hundred of tweaks and edits to Networking Settings within windows, on my router, within my modem, and in my Firewalls, it's still happening. I've also tried it without any AV/AS installed with all windows security deactivated so there was absoultely no firewall what-so-ever possible. I've even tried directly off the modem while in this state... Still to no avail.

So... Not really sure what else to do at this point but wait until it's actually addressed/located/admitted to.

Yea, I work for my ISP actually, and have examined my connection a few times, and could find no fault (modem levels are acceptable). I'm actually a network engineer myself, lol.

What makes this so difficult to troubleshoot is it is sporadic... but as I mentioned earlier in the thread... when I connect through my VPN, I have yet to have the issue happen, which makes me think it's something along the path... I will try setting up a constant ping to the last hop next time I play and hope the issue shows up.

IP from MWO system file: 70.42.29.74
Tracing route to 70.42.29.74 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.0.1
2 27 ms 21 ms 13 ms c-68-44-240-1.hsd1.nj.comcast.net [68.44.240.1]
3 11 ms 10 ms 12 ms te-9-2-ur01.hammonton.nj.panjde.comcast.net [68.85.76.29]
4 10 ms 10 ms 10 ms te-1-1-ur01.mayslanding.nj.panjde.comcast.net [68.86.210.42]
5 11 ms 10 ms 11 ms xe-6-0-0-0-ar03.absecon.nj.panjde.comcast.net [68.86.210.46]
6 15 ms 12 ms 15 ms ae-1-0-ar03.plainfield.nj.panjde.comcast.net [68.85.63.209]
7 17 ms 17 ms 18 ms pos-3-10-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.92.217]
8 16 ms 17 ms 16 ms be-12-pe04.ashburn.va.ibone.comcast.net [68.86.84.210]
9 40 ms 39 ms 39 ms INTERNAP.Gi1-0-11.asr1.YYZ1.gblx.net [64.214.196.26]
10 40 ms 39 ms 43 ms xe-3-3-0.tor10.ip4.tinet.net [141.136.110.9]

Ping statistics for 141.136.110.9: <- Last hop before ping is blocked
Packets: Sent = 243, Received = 239, Lost = 4 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 104ms, Average = 47ms

Gonna grab pingplotter and see which hop is where the loss is happening, and see if others with the packetloss are going through the same hop.

Edited by StandingCow, 20 May 2013 - 06:23 PM.

[karoushi]

Could be Comcast blocking ports or a certain type of traffic.

[Infernus1986]

karoushi, on 20 May 2013 - 06:32 PM, said:

Could be Comcast blocking ports or a certain type of traffic.

if it where some issue with an ISP
why would it only happen in this game udp port is random
why would only start recently
why would it affect multiple ISP's

also

Quote

Reppu (MechWarrior® Online™)

Apr 17 11:35 (PDT)

Hello -x-,

The game doesn't really require any port forwarding as it does not make any unsolicited connection requests, however here is the port list anyway:

TCP 45461
TCP 45464
UDP 21000 to 30000

It is impossible to know which UDP port the game will use, it uses a different one every time a new match is launched.

Edited by Infernus1986, 20 May 2013 - 06:39 PM.

[Dude42]

karoushi, on 20 May 2013 - 06:32 PM, said:

Could be Comcast blocking ports or a certain type of traffic.

I don't have Comcast. I have Road Runner.

[StandingCow]

karoushi, on 20 May 2013 - 06:32 PM, said:

Could be Comcast blocking ports or a certain type of traffic.

That would be a constant issue, and we have people on different ISPs having the same issue. Plus it doesn't happen in any other game.

My assumption is that the minimal packet loss might be happening on one of these two hops:
9 40 ms 39 ms 39 ms INTERNAP.Gi1-0-11.asr1.YYZ1.gblx.net [64.214.196.26]
10 40 ms 39 ms 43 ms xe-3-3-0.tor10.ip4.tinet.net [141.136.110.9]

I am wondering, and I know nothing about game design or programming, if MWO has it's servers set too strict on how many packets can be lost before it disconnects you, or if it just doesn't want to allow you to resync.

Edited by StandingCow, 20 May 2013 - 06:40 PM.

[karoushi]

Infernus1986, on 20 May 2013 - 06:36 PM, said:

if it where some issue with an ISP
why would it only happen in this game udp port is random
why would only start recently
why would it affect multiple ISP's

also

Some ISPs mass block ports and you must use a port scanner to find open ones.

Maybe the ISP has done something recently or some other manner of technology phenomena

Multiple ISP's block the same traffic and try to do the same things, these tend to be the mega-corporate ones like Comcast, Road runner, etc.

Other games could be using different protocols or confirmed working ports.


The only thing I can suggest other then the usual networking (Setup your hardware adapters to optimal settings, check for spyware/adware, you know, the works) is try TCP Optimizer (not much of a suggestion but at least it will set your network to optimal) and DNSCrypt (this will secure your connection to the DNS server).

Try those and check the results. It has to be something otherwise if it was the game it would be affecting everyone. So you must ask yourselves and deduce, what could be doing this? My Location? My Internet connection? My Computer?

Deduce the problem to find a solution.

Edited by karoushi, 20 May 2013 - 06:44 PM.

[Dude42]

karoushi, on 20 May 2013 - 06:42 PM, said:

Dribble.

Read the thread. If ports were blocked no connection could be established in the first place. It wouldn't drop you in the middle of a game. Go figure.

Edited by Dude42, 20 May 2013 - 06:45 PM.

[Infernus1986]

karoushi, on 20 May 2013 - 06:42 PM, said:

Deduce the problem to find a solution.

The problem is somewhere in PGI's well known mess of netcode.
The solution is for PGI to acknowledge the issue and really investigate it.
Your going to have a hard time convincing me its anything but a problem on their end,
If every other modern online game has zero issues with my connection then MWO needs to get with the program.

Quote

The only thing I can suggest other then the usual networking (Setup your hardware adapters to optimal settings, check for spyware/adware, you know, the works) is try TCP Optimizer (not much of a suggestion but at least it will set your network to optimal) and DNSCrypt (this will secure your connection to the DNS server).

I'm not installing/using/changing a bunch of crap to not fix one bugged game.
if my connection is optimal enough to let me host a 12man minecraft sever, host a skype call and play star conflict at the same time i'm pretty sure it can handle one game.

Edited by Infernus1986, 20 May 2013 - 07:01 PM.

[StandingCow]

I have caught 3.4% packet loss on: xe-0-2-0.nyc34.ip4.tinet.net a bunch of times now. Thing is, my trace doesn't always take that same path, which makes sense as it may be due to traffic balancing. But I wonder if that xe-0-2-0 interface may be experiencing some errors... hell, if it is a cisco it could be constantly err-disabling the port causing it to switch over to the other path, then auto-recovering the port and putting traffic back on the dirty path.

For any of you having this issue, try getting pingplotter, set it to trace to: 141.136.110.9 and see if you go through this router/port: xe-0-2-0.nyc34.ip4.tinet.net.

Edited by StandingCow, 20 May 2013 - 07:03 PM.

[StandingCow]

Spoke with some of my colleagues at work about this... the path should be steady, and that isn't what I was seeing on my home connection. I know BGP can select different paths sometimes, but I thought even using that protocol that it would pick a path based on weight then stick to it unless something goes wrong/changes in the network.

Sometimes it would go through:
9 40 ms 39 ms 39 ms INTERNAP.Gi1-0-11.asr1.YYZ1.gblx.net [64.214.196.26]
Othertimes:
xe-0-2-0.nyc34.ip4.tinet.net (where the packet loss is)
and now:
12 9 ms 9 ms 9 ms xe-7-0-2.was10.ip4.tinet.net [77.67.71.193]
13 9 ms 9 ms 9 ms xe-1-1-1.was14.ip4.tinet.net [89.149.185.13]

The problem I noticed earlier is that the path changed constantly between INTERNAP.Gi1-0-11.asr1.YYZ1.gblx.net [64.214.196.26] and xe-0-2-0.nyc34.ip4.tinet.net (where the packet loss is), that isn't supposed to happen.... if it were just changing interfaces, that's fine, that's load balancing... but it isn't supposed to constantly change routes, that would be a sign of a dirty link. And even one dirty link on two load balancing links could cause the path to change.

Now, from work, it is steady on this path:
**REMOVING UNNECESSARY HOPS**
11 10 ms 9 ms 9 ms be-13-pe04.ashburn.va.ibone.comcast.net [68.86.84.214]
12 9 ms 9 ms 9 ms xe-7-0-2.was10.ip4.tinet.net [77.67.71.193]
13 9 ms 9 ms 9 ms xe-1-1-1.was14.ip4.tinet.net [89.149.185.13]
14 31 ms 31 ms 31 ms xe-3-3-0.tor10.ip4.tinet.net [141.136.110.9]

That path has no packet loss, and if you notice, from my trace from home vs work, they both exit the comcast network from the same place (pe04.ashburn.va.ibone.comcast.net [68.86.84.214]), so I think the issue is within the tinet.net space, which would explain why multiple ISPs are experiencing this issue.

This is going to take some time to figure out where and if this is even the issue... will this issue only happen when we go through the xe-0-2-0.nyc34.ip4.tinet.net router? My assumption at this point is..that one of two load sharing links have errors on it.

What would help is if those of you experiencing the issue went to command prompt, and typed tracert 141.136.110.9 and posted in this thread the path... and if you wanted to go a step further download pingplotter (http://www.pingplotter.com/) and watch to see the path you take once you hit that tinet.net space, if changes from time to time (not interfaces, but routers/paths) and if you are seeing any sort of packet loss.

Edited by StandingCow, 21 May 2013 - 05:39 AM.

[MrVop]

People keep telling me that the MWO netcode drops a user after just one bad packet (out of order etc etc)... Can't really find the source of this myself, but It seems to me that expecting zero packet loss is unrealistic at best. Has there been official word from PGI on if this is an issue they are looking into fixing?