Edited by Xajorkith, 24 May 2013 - 06:21 AM.
Malformed Packet Causing A Game Drop
#61
Posted 24 May 2013 - 05:59 AM
#62
Posted 24 May 2013 - 10:07 AM
CGameRules::OnDisconnect: Client has disconnected: cause=eDC_ProtocolError, desc=Remote disconnected: Malformed packet (1486)
#63
Posted 24 May 2013 - 10:09 AM
#64
Posted 24 May 2013 - 11:07 AM
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.
#65
Posted 24 May 2013 - 11:10 AM
Notick, on 24 May 2013 - 11:07 AM, said:
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.
#66
Posted 24 May 2013 - 11:15 AM
Tomato Firmware
DD-WRT Firmware
#67
Posted 24 May 2013 - 11:28 AM
TyR, on 24 May 2013 - 11:15 AM, said:
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.
#68
Posted 24 May 2013 - 11:53 AM
[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.
#69
Posted 24 May 2013 - 02:16 PM
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
#70
Posted 24 May 2013 - 02:18 PM
Jagsmar, on 24 May 2013 - 02:16 PM, said:
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
#71
Posted 24 May 2013 - 03:10 PM
TyR, on 24 May 2013 - 11:53 AM, said:
[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.
#72
Posted 24 May 2013 - 04:37 PM
#73
Posted 24 May 2013 - 06:38 PM
Xajorkith, on 24 May 2013 - 05:59 AM, said:
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.
#74
Posted 24 May 2013 - 07:53 PM
Edited by King Arthur IV, 24 May 2013 - 09:31 PM.
#75
Posted 24 May 2013 - 09:20 PM
Edited by StandingCow, 24 May 2013 - 09:20 PM.
#76
Posted 24 May 2013 - 09:34 PM
#77
Posted 24 May 2013 - 10:50 PM
King Arthur IV, on 24 May 2013 - 09:34 PM, said:
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.
#78
Posted 24 May 2013 - 11:07 PM
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.
#79
Posted 24 May 2013 - 11:28 PM
King Arthur IV, on 24 May 2013 - 11:07 PM, said:
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.
#80
Posted 25 May 2013 - 07:50 AM
TyR, on 24 May 2013 - 11:53 AM, said:
[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:
5 user(s) are reading this topic
0 members, 5 guests, 0 anonymous users