Re: [PATCH net-next 3/3] selftests: traceroute: Add ICMP extensions tests

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Ido Schimmel wrote:
> On Wed, Oct 22, 2025 at 06:12:13PM -0400, Willem de Bruijn wrote:
> > Ido Schimmel wrote:
> > > Test that ICMP extensions are reported correctly when enabled and not
> > > reported when disabled. Test both IPv4 and IPv6 and using different
> > > packet sizes, to make sure trimming / padding works correctly.
> > > 
> > > Disable ICMP rate limiting (defaults to 1 per-second per-target) so that
> > > the kernel will always generate ICMP errors when needed.
> > 
> > This reminds me that when I added SOL_IP/IP_RECVERR_4884, the selftest
> > was not integrated into kselftests. Commit eba75c587e81 points to
> > 
> > https://github.com/wdebruij/kerneltools/blob/master/tests/recv_icmp_v2.c
> > 
> > It might be useful to verify that the kernel recv path that parses
> > RFC 4884 compliant ICMP messages correctly handles these RFC 4884
> > messages.
> 
> FYI, I just ran this test with this series and it seems fine:
> 
> # sysctl -wq net.ipv4.icmp_errors_extension_mask=0x0
> # sysctl -wq net.ipv6.icmp.errors_extension_mask=0x0
> # ./recv_icmp_v2 
> 
> TEST(10, 0, 0)
> len=0 ee_info=0x0, ee_data=0x0 rfc4884=(0, 0x0, 0)
> 
> TEST(10, 41, 31)
> len=0 ee_info=0x0, ee_data=0x0 rfc4884=(0, 0x0, 0)
> 
> TEST(2, 0, 0)
> len=0 ee_info=0x0, ee_data=0x0 rfc4884=(0, 0x0, 0)
> 
> TEST(2, 0, 26)
> len=0 ee_info=0x0, ee_data=0x0 rfc4884=(0, 0x0, 0)
> OK
> # echo $?
> 0
> # sysctl -wq net.ipv4.icmp_errors_extension_mask=0x1
> # sysctl -wq net.ipv6.icmp.errors_extension_mask=0x1
> # ./recv_icmp_v2 
> 
> TEST(10, 0, 0)
> len=0 ee_info=0x10000000, ee_data=0x0 rfc4884=(0, 0x0, 0)
> 
> TEST(10, 41, 31)
> len=0 ee_info=0x10000000, ee_data=0x50 rfc4884=(80, 0x0, 0)
> 
> TEST(2, 0, 0)
> len=0 ee_info=0x0, ee_data=0x0 rfc4884=(0, 0x0, 0)
> 
> TEST(2, 0, 26)
> len=0 ee_info=0x0, ee_data=0x64 rfc4884=(100, 0x0, 0)
> OK
> # echo $?
> 0
> 
> When the extensions are enabled and the RFC4884 socket options are used,
> the offset to the extension structure relative to the beginning of the
> UDP payload seems correct. In both cases the "original datagram" field
> is 128 and if we remove the size of the headers from it we get the
> offset to the extension structure:
> 
> IPv4: 128 - ipv4_hdr - udp_hdr = 128 - 20 - 8 = 100
> IPv6: 128 - ipv6_hdr - udp_hdr = 128 - 40 - 8 = 80
> 
> In both cases SO_EE_RFC4884_FLAG_INVALID is not set.

Oh excellent. Thanks for running that.