Potential bug in GRO code for Windows?

[thomaseizinger]

We are seeing an issue on a Windows machine where quinn-udp gives us packets larger than the configured MTU (2540 and 3810). Here is how we split the packets: https://github.com/firezone/firezone/blob/5437c3e2df001c8c491749c7bff0c063ccdf39e1/rust/socket-factory/src/lib.rs#L210-L255

This code has been working on Linux for several months and we have also not had reports that it doesn't work on Windows. Recently however a customer filed a bug report and looking through the logs, I discovered that we receive packets (i.e. DatagramIn in the above snippet) that are much larger than expected.

Going through quinn-udp's source code, I developed two theories and would be interested in hearing your thoughts on it:

1. stride is being read incorrectly (endianess-issue?) and instead of being smaller than len, it is bigger than len, meaning we never end up splitting the packets despite it being coalesced. https://github.com/quinn-rs/quinn/blob/d23e4e494f7446e21184bf58acd17a861ae73bba/quinn-udp/src/windows.rs#L241
2. The buffer for control messages is too small, thus Windows fails to fit the UDP_COALESCED_INFO message into it and can't tell us that the buffer is coalesced even though it is.

Unfortunately, I've not been able to reproduce this on my own hardware :(