On Sat, Jul 1, 2023 at 9:51 AM Herbert Xu [off-list ref] wrote:

quoted

xfrm_prepare_input: XFRM_MODE_SKB_CB(skb)->protocol: 17
xfrm_inner_mode_encap_remove: x->props.mode: 1 XFRM_MODE_SKB_SB(skb)->protocol:17

This seems to make no sense.  UDP encapsulation is supposed to sit
on the outside of ESP.  So by the time we hit xfrm_input it should
be lone gone.  On the inside of the packet, as it's tunnel mode we
should have either IPIP or IPV6, definitely not UDP.

It's triggering in testIPv4UDPEncapRecvTunnel() in xfrm_test.py.
Specifically, it's the self.ReceivePacketOn(netid, input_pkt) a dozen
lines higher.

The packet we end up writing into the tap fd is
02 00 00 00 C8 01 02 00 00 00 C8 00 08 00
45 00 00 44 00 01 00 00 40 11 98 96 08 08 08 08 0A 00 C8 02
11 94 BF 12 00 30 1C D0
00 00 12 34 00 00 00 01
45 00 00 20 00 01 00 00 40 11 98 BA 08 08 08 08 0A 00 C8 02
01 BB 7D 7B 00 0C 9B 7A
01 02 02 11

You can decode this with https://hpd.gasmi.net/ or https://packetor.com/

You can decode the inner packet (this is null esp crypto) by passing in
00 00 00 00 00 00 00 00 00 00 00 00 08 00
45 00 00 20 00 01 00 00 40 11 98 BA 08 08 08 08 0A 00 C8 02
01 BB 7D 7B 00 0C 9B 7A
01 02 02 11
instead.

Note that the protocol the kernel's printk I added prints is the
*outer* encap UDP protocol, not the inner UDP.
ie. you can change the scapy.UDP to scapy.TCP in the 'inner_pkt =' assignment,
and the warning still triggers.  The resulting packet is:
02 00 00 00 FA 01 02 00 00 00 FA 00 08 00
45 00 00 50 00 01 00 00 40 11 66 8A 08 08 08 08 0A 00 FA 02
11 94 A7 EB 00 3C 33 E0
00 00 12 34 00 00 00 01
45 00 00 2C 00 01 00 00 40 06 66 B9 08 08 08 08 0A 00 FA 02
01 BB 7D 7B 00 00 00 00 00 00 00 00 50 02 20 00 F9 82 00 00
01 02 02 11

ie. the inner packet is IPv4/TCP:
00 00 00 00 00 00 00 00 00 00 00 00 08 00
45 00 00 2C 00 01 00 00 40 06 66 B9 08 08 08 08 0A 00 FA 02
01 BB 7D 7B 00 00 00 00 00 00 00 00 50 02 20 00 F9 82 00 00
01 02 02 11

Are you able to reduce this to a set of "ip xfrm" commands that I
can use to reproduce this?