Log an error somewhere (make sure to throttle if it's possible that 1000's of packets could get sent).Transmit the packet, inserting a useless checksum calculated over only the portion of the packet that is in the first fragment.Transmit the packet, without modifying the checksum.Silently discard the packet (ideally also incrementing a discard counter).
#Ipv4 checksum offload driver#
In any case, if there is a situation where the OS produces a fragmented IPv4 datagram with checksum enabled, you're free to make your NIC driver do any of these: What's the exact command line you've used? Are you doing anything else to make it work? As far as I can see, Windows enforces a minimum MTU of 576 bytes, per RFC. I'm not able to set an MTU of 128 via netsh.exe. Observed this behavior on Windows Server 2012 and Windows Server 2016 (didn't try on other Windows versions).BTW, don't know if it's related but Browser protocol had a zero-day vulnerability. Tried to reproduce with DHCP traffic - got IP fragments but in this case the UDP checksum was calculated correctly by the OS (didn't check the miniport logs to see the checksum offload flag but can check it as well if needed).I don't see any principal obstacle to such behavior with normal MTU values if IP fragmentation is performed Maybe it can be forced by other means as well, but I'm not familiar with them. The MTU setting to 128 is done to force the IP fragmentation.I suppose NDIS traces should provide this data as well but I'm not sure what flags to enable and for which WPP provider The underlying miniport receives UDP checksum offload flag set for each IP fragment (I see it from our proprietary logs).
the OS didn't calculate it or calculated it incorrectly
0 kommentar(er)
