164 replies to this topic

[FREDtheDEAD]

Caveat: There's a few differences between TCP and UDP packets which make testing quality of service in an UDP environment very hard. Ping and tracert are TCP protocol tools and wont be able to spot a router dropping UDP packets. Unfortunately there is no UDP equivalent of those command line tools - UDP is quick and dirty and only used where speed is more important that packet loss (games). See http://gafferongames...ers/udp-vs-tcp/ for a nice guide (the chat on that article is really interesting).

Edited by Xajorkith, 24 May 2013 - 06:21 AM.

[Trotil]

Today, post-patch:
CGameRules::OnDisconnect: Client has disconnected: cause=eDC_ProtocolError, desc=Remote disconnected: Malformed packet (1486)

[Dude42]

Just reporting in. Since using the VPN client mentioned by Notick I have not dropped since. And have a lower ping

[Notick]

My last communique with the Support team bared another possible work around.

That possibility is what follows:
"Another player found a fix for an issue that is related to connectivity - or a workaround rather. His router has a UDP Flood Prevention feature - he disabled this and suddenly the issues he was facing disappeared.

If I can have some more players test this and get similar results, I'll be able to build a solid case to send to the devs about it."

Personally, my router has no functionality like this. Just the typical NAT settings, which even when turned off doesn't fix the problem.

Edited by Notick, 24 May 2013 - 11:08 AM.

[Dude42]

Notick, on 24 May 2013 - 11:07 AM, said:

My last communique with the Support team bared another possible work around.

That possibility is what follows:
"Another player found a fix for an issue that is related to connectivity - or a workaround rather. His router has a UDP Flood Prevention feature - he disabled this and suddenly the issues he was facing disappeared.

If I can have some more players test this and get similar results, I'll be able to build a solid case to send to the devs about it."

Personally, my router has no functionality like this. Just the typical NAT settings, which even when turned off doesn't fix the problem.

Same, no such feature. If I had my ISP place my modem/router combo in bridge mode, then go purchase a nice router that does have such a feature, then disable it, I wonder if that would fix it. Hmm, I'll just put that as a last resort.

[TyR]

There is a thread started for testing the UDP flood settings. Unfortunately I do not have this as an option with my router either, so I am posting whatever I can find that may also be related to some UDP manipulation. Depending on your router, you may be able to install some third party firmware that will either fix this issue (if it is indeed the cause) or provide you more options for tweaking not normally available by the manufacturer. A couple options listed below for third party. Of course my router is listed, but only the newer hardware versions are supported, so I cannot test this either.

Tomato Firmware
DD-WRT Firmware

[Notick]

TyR, on 24 May 2013 - 11:15 AM, said:

There is a thread started for testing the UDP flood settings. Unfortunately I do not have this as an option with my router either, so I am posting whatever I can find that may also be related to some UDP manipulation. Depending on your router, you may be able to install some third party firmware that will either fix this issue (if it is indeed the cause) or provide you more options for tweaking not normally available by the manufacturer. A couple options listed below for third party. Of course my router is listed, but only the newer hardware versions are supported, so I cannot test this either.

Tomato Firmware
DD-WRT Firmware

It is Reppu that I have been working with - so it'd make sense that he'd start a post for more information.

[TyR]

I just took a look in my router logs and I am seeing a lot of lines of the following

[INFO] Fri May 24 11:33:39 2013 Blocked incoming UDP packet from 70.42.29.75:21521 to MyIPNumber:62847

I also get some of

[INFO] Fri May 24 11:29:43 2013 Blocked incoming TCP packet from 70.42.29.74:45461 to MyIPNumber:53597 as FIN:ACK received but there is no active connection

Just wish it told me why these were being blocked. I am going to try to set up an inbound filter to allow these IPs to see if that will stop the blocking of what I am assuming are legitimate packets. I would think the .74 IP is just another from their servers. It does not seem to get the blocked messages without the the no active connection.

Edited by TyR, 24 May 2013 - 11:55 AM.

[Jagsmar]

Is there a prize for being the first person disconnected while using VPN?


CGameRules::OnDisconnect: Client has disconnected: cause=eDC_ProtocolError, desc=Remote disconnected: Received an ack for a packet newer than what we've sent (received 49495, at 49494); disconnecting
CGameClientChannel::Release
UnLoadLevel End: 0.4 sec

[Dude42]

Jagsmar, on 24 May 2013 - 02:16 PM, said:

Is there a prize for being the first person disconnected while using VPN?


CGameRules::OnDisconnect: Client has disconnected: cause=eDC_ProtocolError, desc=Remote disconnected: Received an ack for a packet newer than what we've sent (received 49495, at 49494); disconnecting
CGameClientChannel::Release
UnLoadLevel End: 0.4 sec

[Deathlike]

TyR, on 24 May 2013 - 11:53 AM, said:

I just took a look in my router logs and I am seeing a lot of lines of the following

[INFO] Fri May 24 11:33:39 2013 Blocked incoming UDP packet from 70.42.29.75:21521 to MyIPNumber:62847

I also get some of

[INFO] Fri May 24 11:29:43 2013 Blocked incoming TCP packet from 70.42.29.74:45461 to MyIPNumber:53597 as FIN:ACK received but there is no active connection

Just wish it told me why these were being blocked. I am going to try to set up an inbound filter to allow these IPs to see if that will stop the blocking of what I am assuming are legitimate packets. I would think the .74 IP is just another from their servers. It does not seem to get the blocked messages without the the no active connection.

I bet these correspond with the omicron logs. Search for ICMP in your logs, and that may show up in logs/matches that "dumped you to the mechlab."

ICMP is specifically PING related, but I think it is specifically a server node that you are being routed to that is overwhelmed and/or incapable of handling this load. I get that same IP in my omnicron logs and have already sent in a support ticket about it.

[TyR]

Not seeing anything ICMP related from this IP in my logs actually. Thought I had some, but they were from another computer on my network. With later testing I was kicked from the match, but nothing showed up in my router logs about it. Not sure if something else is going on or if some events are just not being logged or maybe happening remotely.

[StandingCow]

Xajorkith, on 24 May 2013 - 05:59 AM, said:

Caveat: There's a few differences between TCP and UDP packets which make testing quality of service in an UDP environment very hard. Ping and tracert are TCP protocol tools and wont be able to spot a router dropping UDP packets. Unfortunately there is no UDP equivalent of those command line tools - UDP is quick and dirty and only used where speed is more important that packet loss (games). See http://gafferongames...ers/udp-vs-tcp/ for a nice guide (the chat on that article is really interesting).

And that is why I think maybe this is happening due to MWO being intolerant toward lost packets. With UDP it doesn't have any type of control protocol, so a packet that is lost will not be resent... but I have to wonder if too many lost UDP packets are causing the malformed packet, or in this case, almost any loss.

Like you said, we have no option really with UDP like we do with TCP/IP,.. so the best we can do is tell PGI that, hey, when we take packet loss... we get this malformed packet.

I am working with a member of my unit that has never had this issue until the patch, but we also discovered that he is taking packet loss on his first hop to his ISP, so again... packet loss and this malformed packet do seem tied to one another... and something PGI has done recently (they mentioned something about changing the game to use less bandwidth?) is causing this issue to happen more.


Tonight, I am taking 0 packet loss, and I have not had the malformed packet issue happen once. For those of you using VPNs, that will only work if your connection through your VPN isn't taking packet loss, if it is, you will get the malformed packet.

Edited by StandingCow, 24 May 2013 - 07:02 PM.

[King Arthur IV]

op, can you recommend a vpn thingy that is really free. correct me if im wrong but that one you suggested will stop after every 2 hours?

Edited by King Arthur IV, 24 May 2013 - 09:31 PM.

[StandingCow]

This isn't free (like 6 bucks a month for the month by month version), but it is high quality (I use this often): https://www.privateinternetaccess.com/

Edited by StandingCow, 24 May 2013 - 09:20 PM.

[King Arthur IV]

i just tried op's vpn thing. played 3 games and didnt crash but decided not to test anymore because the program nearly tripled my ping. im in Australia so my ping was about 600-700, kind of pointless even if it worked for me with ping that high. are there any other programs out there that will make the game more stable without the high ping?!?!?

[StandingCow]

King Arthur IV, on 24 May 2013 - 09:34 PM, said:

i just tried op's vpn thing. played 3 games and didnt crash but decided not to test anymore because the program nearly tripled my ping. im in Australia so my ping was about 600-700, kind of pointless even if it worked for me with ping that high. are there any other programs out there that will make the game more stable without the high ping?!?!?

Well, you would need to VPN into a server that was on it's way to your final destination... For example you don't want to connect to western Australia if you were in eastern Australia then to Canada, nor would you want to VPN all the way across to the eastern US then to Canada. The quality/speed of the VPN server also matters, that is why paid VPNs are better, higher quality and speed.

But, I also want to make clear that using a VPN isn't a solution that will always work, all it is doing is allowing you to bypass a route that is taking packet loss (which it seems causes the malformed packets)... if your path to the VPN server and to the PGI servers has errors, you are going to get that malformed packet issue. Also, "dirty" links do not ALWAYS take packet loss, so you might see your path clean in one moment, then packet loss the next, it all depends on what is causing it... if it's due to heavy traffic it would happen more often during peak hours, if it is low light levels on the link then it could happen at any time.

Edited by StandingCow, 24 May 2013 - 10:51 PM.

[King Arthur IV]

StandingCow, on 24 May 2013 - 10:50 PM, said:

Well, ..............

basically this is useless for me. it "may" only work if it takes a clean path. if im going to put my money any where it would of been into the game but as of right now it may have to go into a new rig. even then im unsure if the game will be stable or not.

anyway thx for explaining it to me.

[StandingCow]

King Arthur IV, on 24 May 2013 - 11:07 PM, said:

basically this is useless for me. it "may" only work if it takes a clean path. if im going to put my money any where it would of been into the game but as of right now it may have to go into a new rig. even then im unsure if the game will be stable or not.

anyway thx for explaining it to me.

Oh I agree with you, the real fix in this case is (at least how I understand it right now) for PGI to make a change in the game to be more forgiving of packet loss. Like I said earlier, in the patch notes they made a change having to do with the bandwidth the game used... all the sudden a LOT more people are having this malformed packet. So, yea, I am convinced this is something only PGI can fix.

[FREDtheDEAD]

TyR, on 24 May 2013 - 11:53 AM, said:

I just took a look in my router logs and I am seeing a lot of lines of the following

[INFO] Fri May 24 11:33:39 2013 Blocked incoming UDP packet from 70.42.29.75:21521 to MyIPNumber:62847

I also get some of

[INFO] Fri May 24 11:29:43 2013 Blocked incoming TCP packet from 70.42.29.74:45461 to MyIPNumber:53597 as FIN:ACK received but there is no active connection

On those IP addresses:

Spoiler

[Querying whois.arin.net]
[whois.arin.net]
#

NetRange: 70.42.0.0 - 70.42.255.255
CIDR: 70.42.0.0/16
OriginAS:
NetName: PNAP-09-2005
NetHandle: NET-70-42-0-0-1
Parent: NET-70-0-0-0-0
NetType: Direct Allocation
RegDate: 2005-09-29
Updated: 2006-11-13
Ref: http://whois.arin.ne...NET-70-42-0-0-1

OrgName: Internap Network Services Corporation
OrgId: PNAP
Address: 250 Williams Street
Address: Suite E100
City: Atlanta
StateProv: GA
PostalCode: 30303
Country: US
RegDate: 1996-07-18
Updated: 2012-01-24
Ref: http://whois.arin.net/rest/org/PNAP

It's the InterNAP ISP.