On Thu, Nov 26, 2020 at 09:21:39AM +0000, Marler, Jonathan wrote: > We've found an issue while running the following USGv6 tests where the kernel > drops outgoing packets: > > 5.3.11 Tunnel Mode: Fragmentation > 5.4.11 Tunnel Mode: Fragmentation > > During the test, an esp PING request is sent to our device under test, and we > send back a response that is rejected by our router with a "packet to big" > error. This error is fine, it's part of the test. This error packet then > sets the MTU to 1280 (which also happens to be the minimum MTU size allowed > by ipv6 and the kernel). > > The issue comes up when this mtu is adjusted by the esp6_get_mtu function. > It adjusts it to a value below the 1280 threshold, which causes any packets > associated with this MTU to be dropped in the ipv6_setup_cork function. > > We are running on kernel version 4.9.180, but this issue looks as if it would > still exist in the latest version except that esp6_get_mtu has been replaced > by xfrm_state_mtu. By adding instrumentation, we found during the test the > mtu value of 1280 given by the "packet to big" response gets passed to the > esp6_get_mtu function, and the following values are what we logged in that > function: > > mtu = 1280 > x->props.header_len = 56 > crypto_aead_authsize(aead) = 12 > net_adj = 0 > blocksize = 8 > > This causes the function to return an mtu size of 1206, causing packets > thereafter to be dropped because this falls below the IPV6_MIN_MTU threshold. > > Our idea is to modify esp6_get_mtu to limit the minimum mtu to IPV6_MIN_MTU. > We're not certain this is the correct fix, and thought to check with the > maintainers of that file, and a few others who have modified that function. > Any help or guidance here is appreciated, thank you. >
We should not return a mtu below IPV6_MIN_MTU for IPv6 and not below IPV6_MIN_MTU for IPv4. So the proposed fix looks correct to me.
