S
Soquel Dude
Guest
I'm writing an NDIS LWF driver for Windows 10. This LWF will need to insert a 34-byte tag after the 802.3 MAC header. To do this, the driver changes the NDIS_RESTART_GENERAL_ATTRIBUTES .MtuSize to 1466 during the FilterRestart call. The driver also filters OID queries and changes the return values for OID_GEN_MAXIMUM_FRAME_SIZE from 1500 to 1466, as well as OID_GEN_MAXIMUM_TOTAL_SIZE from 1514 to 1480.
All of this works and I have verified that the IPV4 stack uses 1466 as its MTU through netsh->int->ipv4->show->int.
I tried to confirm the max packet length used by IPv4 after reducing the MTU. I did this by pinging a target with a large frame size (e.g., ping www.yahoo.com -l 16000) in order to fragment the ping payload over various max-MTU frames. However, I see that the fragmented packets are 1474 total bytes (1460 bytes for the IPV4 payload). I would have expected a packet length of 1480 with an IPV4 payload of 1466.
Does anybody know why IPV4 would reduce the MTU by 6 bytes in this way?
Continue reading...
All of this works and I have verified that the IPV4 stack uses 1466 as its MTU through netsh->int->ipv4->show->int.
I tried to confirm the max packet length used by IPv4 after reducing the MTU. I did this by pinging a target with a large frame size (e.g., ping www.yahoo.com -l 16000) in order to fragment the ping payload over various max-MTU frames. However, I see that the fragmented packets are 1474 total bytes (1460 bytes for the IPV4 payload). I would have expected a packet length of 1480 with an IPV4 payload of 1466.
Does anybody know why IPV4 would reduce the MTU by 6 bytes in this way?
Continue reading...