Proposal: introduce --filter-trace-tunnel-type and --filter-trace-tunnel-pcap

[Asphaltt]

As for VxLAN env, it'll be really convenient to trace skb with filtering inner-VxLAN packet info with pcap-filter, as pcap-filter does not support filtering inner-VxLAN packet info directly.

To achieve it, let me introduce --filter-trace-tunnel-type and --filter-trace-tunnel-pcap options to accept a pcap-filter expr to filter inner-VxLAN packet info.

$ sudo pwru --filter-trace-tunnel-type vxlan --filter-trace-tunnel-pcap 'host 1.1.1.1 and icmp' host 1.1.1.1 and icmp

Then, pwru is able to trace skb before decapsulating VxLAN and after encapsulating VxLAN.

And --filter-track-skb does not work well before decapsulating VxLAN.

Furthermore, --filter-trace-tunnel-type should support geneve, ipip and so on.

TODOs:

• Introduce --filter-trace-tunnel-type vxlan
• Introduce --filter-trace-tunnel-type geneve
• Introduce --filter-trace-tunnel-type ipip

[jschwinger233]

I like this, thank you!

Just to be clear, --filter-trace-tunnel-pcap 'host 1.1.1.1 and icmp' host 1.1.1.1 and icmp in your proposal, will match nothing, right? My understanding is

--filter-trace-tunnel-pcap 'host 1.1.1.1 and icmp' host 1.1.1.1 and icmp
                            ---------------------  ---------------------
                                      ①                      ②

① filters inner packet, from skb->data + sizeof(outer)
② filters outer packet, from skb->data

Since a vxlan can't have an outer icmp, no traffic will be captured.

[Asphaltt]

Oh, what are we missing here?

It's the bool logic between ① and ②. It should be "① or ②" by default. And use --filter-trace-tunnel-both, or any option, to indicate "① and ②" instead.

[jschwinger233]

What is the use case of "or"? I think "and" is more useful to catch "out ip 172.1.1.1 and vxlan and inner ip 10.1.1.1"

[Asphaltt]

"out ip 172.1.1.1 and vxlan and inner ip 10.1.1.1"

This seems better for me.

Why not use "and vxlan", "or vxlan" instead of --filter-trace-tunnel-XXX options? The pcap-filter expr before them filters vxlan outer packet. The one after them filters vxlan inner packet. "and" and "or" in them indicate the bool logic.

Same for geneve and ipip.

[jschwinger233]

Was thinking about this. I have an ambiguous feeling of cool and dangerous about what we are doing here: extend pcap filter.

[tommyp1ckles]

Been wanting something like this for a while, decided to start hacking on it this week. I have a draft PR here only implementing vxlan support (geneve, etc would be todo...).

(think I need to drop the pcap-l3 flag as it's redundant with the l2 one).

Example usage:

sudo ./pwru --filter-func=udp_queue_rcv_skb  'port 8472' --output-tunnel --filter-tunnel-pcap-l2 'port 8080'  --output-tcp-flags
2025/01/27 16:43:11 Attaching kprobes (via kprobe)...
1 / 1 [-----------------------------------------------------------------------------------------------------------------------------------------------------------] 100.00% ? p/s
2025/01/27 16:43:11 Attached (ignored 0)
2025/01/27 16:43:11 Listening for events..
2025/01/27 16:43:11 Failed to retrieve all ifaces from all network namespaces: open /proc/2290523/ns/net: no such file or directory. Some iface names might be not shown.
SKB                CPU PROCESS          NETNS      MARK/x        IFACE       PROTO  MTU   LEN   TUPLE FUNC TUNNEL
0xffff0000d24daee8 3   nc:2291243       4026532458 0            eth0:353     0x0800 65536 90    172.18.0.5:44673->172.18.0.2:8472(udp) udp_queue_rcv_skb 52:2e:36:8d:11:23 -> ba:44:d8:6c:66:5a 10.244.1.205:44761->10.244.3.122:8080(tcp:SYN)
0xffff0000c76d4200 3   nc:2291243       4026532646 0            eth0:359     0x0800 65536 90    172.18.0.2:59719->172.18.0.5:8472(udp) udp_queue_rcv_skb 92:53:8f:3a:e7:ef -> 7e:16:77:14:df:0d 10.244.3.122:8080->10.244.1.205:44761(tcp:SYN|ACK)
0xffff0000c76d5800 3   nc:2291243       4026532458 0            eth0:353     0x0800 65536 82    172.18.0.5:44673->172.18.0.2:8472(udp) udp_queue_rcv_skb 52:2e:36:8d:11:23 -> ba:44:d8:6c:66:5a 10.244.1.205:44761->10.244.3.122:8080(tcp:ACK)
0xffff0000d24daee8 3   nc:2291243       4026532458 0            eth0:353     0x0800 65536 82    172.18.0.5:44673->172.18.0.2:8472(udp) udp_queue_rcv_skb 52:2e:36:8d:11:23 -> ba:44:d8:6c:66:5a 10.244.1.205:44761->10.244.3.122:8080(tcp:FIN|ACK)
0xffff0000d24d9ae8 3   node:2108761     4026532646 0            eth0:359     0x0800 65536 82    172.18.0.2:59719->172.18.0.5:8472(udp) udp_queue_rcv_skb 92:53:8f:3a:e7:ef -> 7e:16:77:14:df:0d 10.244.3.122:8080->10.244.1.205:44761(tcp:FIN|ACK)

So my approach is to have a tuple pcap filter flag, that will be pointed at the start of the encapsulated l2 filter.