Packet, where are you? – eBPF-based Linux kernel networking debugger
1–10 of 20 posts
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#2Is 'tracing network packets in the kernel' also what tcpdump/snoop/nettl dp?
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#3This is a great codebase to read for me currently, as I am working on an ebpf based packet aquisition mechanism for a network monitoring program.
Anyone got other good projects to look at?
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#4Asking 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.
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#5Love the name!
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#6Asking 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.
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
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#7Asking 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.
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…
thank you! TIL.
I guess you need a completely different mindset to approach this.
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#8Is 'tracing network packets in the kernel' also what tcpdump/snoop/nettl dp?
I can speak for tcpdump and the answer is no. It only looks at the network interface. Something I often want to do is catch which process sent a few UDP packets. Netstat and ss won't catch it because it's too short of a time frame, and tcpdump doesn't contain any information about the kernel.
I've been using opensnitch which uses eBPF rules to track this information lately, but I'm looking for something more flexible.
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#9Is 'tracing network packets in the kernel' also what tcpdump/snoop/nettl dp?
No. Tcpdump and others are packet sniffers. They clone network packets so the contents can be examined.
pwru on the other hand is used to trace what the kernel is doing with your packets.
Re: Packet, where are you? – eBPF-based Linux kernel networking debugger
#10Asking 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.
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…
> 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 ?