mexmer wrote:this problem reminds me about issue with certain intel network adapters "eating" audio packets.

http://blog.krisk.org/2013/02/packets-of-death.html ?

AyrA wrote: To generally mitigate this problem in the future, add a 16bit counter to the UDP packets your applications send, this way, you automatically change the checksum for each packet that is transmitted again.

That sounds like a sane solution to this problem.

You are also forgetting that this is before the NAT, so the PCs do not deal with this. It's looking like a bad router or bad hardware at the ISP. I'll put my money on a bad router. I'm curious what model it is. Oh, right. Well, a solution is to roll your own checksum and set UDP's checksum to zero....

Nice Voltara! However, what's special with 0xFFFF? The only "special case" with UDP checksum is that if you get a checksum of 0x0000, then you need to actually set it to 0xFFFF, as per RFC768. If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's compleme...

I included a screenshot and I also included the packets that are being filtered, so maybe you can ask your ISP a few questions of why they are filtering those specific packets. I re-calculated the checksum both for the first large packet and the small packet. They both (should) have checksum 0x99F2...