[ralgozino]

Asking as someone with almost no experience with eBPF.

How do you read the otuput of the tool? In the README's example GIF, If I didn't know there's an IPTables rule dropping the packages I would not know that the package is being dropped.

[bazzargh]

if you have a recent enough kernel, this change https://github.com/cilium/pwru/pull/148 means that it will print the reason the packet was dropped in the output, as logged by kfree_skb_reason - see https://lwn.net/Articles/885729/

There's a whole heap of reasons a packet can be dropped: https://github.com/torvalds/linux/blob/76f598ba7d8e2bfb4855b...

In any case, this makes it less painful than going back to read the kernel source. I don't think that the gif in the README is up to date with this change - it's 2 years old and this feature only appeared 2 months ago.

[ralgozino]

that is pretty cool and a major QoL improvement indeed!

[zokier]

You'll want to have kernel sources handy. In this case you can see the packet ending up in nf_hook_slow function: https://elixir.bootlin.com/linux/latest/source/net/netfilter...

from there you can see only one branch leading to kfree_skb, so you can make a guess that some netfilter "hook" returned NF_DROP. From that you might already be able to make educated guesses that it might be iptables rule, or continue delving deeper to figure out what those hooks are etc

[liotier]

> make educated guesses that it might be iptables rule, or continue delving deeper to figure out what those hooks are etc

Would it be a good idea to let pwru dig into the iptables detour to provide the whole view of the packet's journey - or is iptables at a different layer whose observability is best left to another tool ?

[ralgozino]

thank you! TIL.

I guess you need a completely different mindset to approach this.