But what was the checksum? Like the actual, specific value?
The Factorio devs found[1] that some devices do fail to compute checksums, in that they compute the checksum just fine, but they're doing something stupid with some values and so checksums of 0x0000 or 0xFFFF (the two values from the FFF) cause packet loss.
In any protocol that, when the packet repeats, repeats it with even the slightest permutation (different request ID, timestamp, sequence number, etc.), that will be enough to jiggle the checksum to a new value (probably), and then the protocol will keep going with only a minor blip that probably goes unnoticed.
But if the packet is deterministic, only then you hit the problem.
> calculating the UDP checksum is not exactly rocket science.
I've seen things that trivial get messed up. "Just read the standard" is a high bar, sometimes. (Though the above is probably "I dual purposed a u16 without realizing it didn't have any available niches for that…")
Without disassembling and tracing the Intel Windows drivers (something I don’t feel like doing)
As someone who generally doesn't use AI in software development nor RE, this is one thing that I'd recommend trying one on to see what it can do: the problem is clearly defined and a solution is easily validated, and it's a problem you're not intersted in digging deeper yourself. The other comment here about 0000 and FFFF checksums seems like a good place to start.
A little more digging found this discussion from TODAY regarding what looks like a very similar bug in one of Intel's Linux NIC drivers: https://lkml.org/lkml/2026/5/4/1886
show comments
stroebs
I came across this very same issue with fika, a community-made mod for Escape from Tarkov. One player would consistently fail to join games and it took ages to figure out the different components that were failing. The code intentionally sent the join message 4 times in quick succession, which triggered the DoS protection on the internet firewall. Ok, disabled that. The next issue was the packets were being interfered with by the ALG on the internet firewall, so disabled that too. Then the last final hurdle was the Rx offloading on the Intel NIC which was the exact same issue with the checksum being set to all 0’s or all F’s.
What made it confusing at the time is the join packet would sometimes be accepted and passed through to the game, so it prompted further digging into why.
bombcar
It'd be interesting to see what the wrong checksum it calculates is ...
show comments
nubinetwork
Interesting... I've heard enabling tx/rx offloading is actually beneficial, turns out that's not always the case...
But what was the checksum? Like the actual, specific value?
The Factorio devs found[1] that some devices do fail to compute checksums, in that they compute the checksum just fine, but they're doing something stupid with some values and so checksums of 0x0000 or 0xFFFF (the two values from the FFF) cause packet loss.
In any protocol that, when the packet repeats, repeats it with even the slightest permutation (different request ID, timestamp, sequence number, etc.), that will be enough to jiggle the checksum to a new value (probably), and then the protocol will keep going with only a minor blip that probably goes unnoticed.
But if the packet is deterministic, only then you hit the problem.
> calculating the UDP checksum is not exactly rocket science.
I've seen things that trivial get messed up. "Just read the standard" is a high bar, sometimes. (Though the above is probably "I dual purposed a u16 without realizing it didn't have any available niches for that…")
[1]: https://www.factorio.com/blog/post/fff-176
Without disassembling and tracing the Intel Windows drivers (something I don’t feel like doing)
As someone who generally doesn't use AI in software development nor RE, this is one thing that I'd recommend trying one on to see what it can do: the problem is clearly defined and a solution is easily validated, and it's a problem you're not intersted in digging deeper yourself. The other comment here about 0000 and FFFF checksums seems like a good place to start.
A little more digging found this discussion from TODAY regarding what looks like a very similar bug in one of Intel's Linux NIC drivers: https://lkml.org/lkml/2026/5/4/1886
I came across this very same issue with fika, a community-made mod for Escape from Tarkov. One player would consistently fail to join games and it took ages to figure out the different components that were failing. The code intentionally sent the join message 4 times in quick succession, which triggered the DoS protection on the internet firewall. Ok, disabled that. The next issue was the packets were being interfered with by the ALG on the internet firewall, so disabled that too. Then the last final hurdle was the Rx offloading on the Intel NIC which was the exact same issue with the checksum being set to all 0’s or all F’s.
What made it confusing at the time is the join packet would sometimes be accepted and passed through to the game, so it prompted further digging into why.
It'd be interesting to see what the wrong checksum it calculates is ...
Interesting... I've heard enabling tx/rx offloading is actually beneficial, turns out that's not always the case...