[Swan-dev] F32(5.6.8-100.fc30.x86_64) Kernel not reporting ICMP shunt events correctly?

[Andrew Cagney]

How the kernel reports a ping seems to have changed.  However, is
there also a problem with what pluto does next?

On Tue, 26 May 2020 at 17:08, Andrew Cagney <andrew.cagney at gmail.com> wrote:
>
> Linux swanbase 5.6.8-100.fc30.x86_64 #1 SMP Wed Apr 29 17:49:15 UTC
> 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> --- MASTER/testing/pluto/newoe-18-poc-private/road.console.txt
> +++ OUTPUT/testing/pluto/newoe-18-poc-private/road.console.txt
> @@ -55,7 +55,7 @@
>  src 192.1.3.209 dst 192.1.2.23
>   proto esp spi 0xSPISPI reqid REQID mode transport
>   replay-window 0
> - sel src 192.1.3.209/32 dst 192.1.2.23/32 proto icmp type 8 code 0 dev eth0
> + sel src 192.1.3.209/32 dst 192.1.2.23/32 proto icmp type 0 code 0 dev eth0
>  XFRM policy:
>  src 192.1.2.253/32 dst 192.1.3.209/32
>   dir fwd priority 3129279 ptype main
> @@ -138,7 +138,7 @@
>  src 192.1.3.209 dst 192.1.2.23
>   proto esp spi 0xSPISPI reqid REQID mode transport
>   replay-window 0
> - sel src 192.1.3.209/32 dst 192.1.2.23/32 proto icmp type 8 code 0 dev eth0
> + sel src 192.1.3.209/32 dst 192.1.2.23/32 proto icmp type 0 code 0 dev eth0
>  XFRM policy:
>  src 192.1.2.253/32 dst 192.1.3.209/32
>   dir fwd priority 3129279 ptype main
>
> notice how the type changed.  The logs show:
>
> | xfrm netlink msg len 376
> | xfrm acquire rtattribute type 5
> | xfrm template attribute with reqid:0, spi:0, proto:50
> | xfrm acquire rtattribute type 16
> | subnet from address 192.1.3.209 (in netlink_acquire() at kernel_xfrm.c:1842)
> | subnet from address 192.1.2.23 (in netlink_acquire() at kernel_xfrm.c:1843)
> | subnet from address 192.1.3.209 (in has_bare_hold() at kernel.c:1263)
> | subnet from address 192.1.2.23 (in has_bare_hold() at kernel.c:1264)
> | add bare shunt 0x7f0759854f58 192.1.3.209/32:0 --1-->
> 192.1.2.23/32:0 => %hold 0    %acquire-netlink

Picking up from IRC.

Going by some of the comments I'm reading in the code, OE should set
up a tunnel for all-protocols and all-ports.  Hence, no matter what
the kernel indicates, the port/protocol should be stripped and:
> + sel src 192.1.3.209/32 dst 192.1.2.23/32 proto icmp type 0 code 0 dev eth0
installed?

(segway, is protoport=tcp/10 valid on an OE template connection?)

>
> where as the old logs show (notice the :8 everywhere):
>
> | xfrm netlink msg len 376
> | xfrm acquire rtattribute type 5
> | xfrm template attribute with reqid:0, spi:0, proto:50
> | xfrm acquire rtattribute type 16
> | subnet from endpoint 192.1.3.209:8 (in netlink_acquire() at
> kernel_xfrm.c:1842)
> | subnet from address 192.1.2.23 (in netlink_acquire() at kernel_xfrm.c:1843)
> | subnet from endpoint 192.1.3.209:8 (in has_bare_hold() at kernel.c:1263)
> | subnet from address 192.1.2.23 (in has_bare_hold() at kernel.c:1264)
> | add bare shunt 0x7f9817505f58 192.1.3.209/32:8 --1-->
> 192.1.2.23/32:0 => %hold 0    %acquire-netlink
> initiate on demand from 192.1.3.209:8 to 192.1.2.23:0 proto=1 because: acquire