This shows you the differences between two versions of the page.
|
ep:labs:061:contents:tasks:ex3 [2026/04/06 22:01] maria.popescu2812 [03. [30p] Packets, where are you?] |
ep:labs:061:contents:tasks:ex3 [2026/04/07 02:13] (current) radu.mantu |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| [[https://github.com/cilium/pwru|pwru]] is a tool created by Cilium to help trace network packets in the kernel's network stack and debug network connectivity issues. It does this by attaching simple eBPF programs to certain function entry points. These programs can report back to a userspace process different kinds of information, including the function that was reached, the arguments that were passed, and a CPU clock timestamp. The method used for instrumenting kernel code is based on [[https://www.kernel.org/doc/html/latest/trace/kprobes.html|kprobes]]. Ask your assistant for more information. | [[https://github.com/cilium/pwru|pwru]] is a tool created by Cilium to help trace network packets in the kernel's network stack and debug network connectivity issues. It does this by attaching simple eBPF programs to certain function entry points. These programs can report back to a userspace process different kinds of information, including the function that was reached, the arguments that were passed, and a CPU clock timestamp. The method used for instrumenting kernel code is based on [[https://www.kernel.org/doc/html/latest/trace/kprobes.html|kprobes]]. Ask your assistant for more information. | ||
| - | === [10p] Task A — A packet's journey === | + | === [10p] Task A - A packet's journey === |
| **Installation — build from source** | **Installation — build from source** | ||
| Line 72: | Line 72: | ||
| - **What changed with the DROP rule?** Compare the two traces side by side. At which function does the path diverge? | - **What changed with the DROP rule?** Compare the two traces side by side. At which function does the path diverge? | ||
| - | ==== 04. 4. [20p] bpftrace — Network Scripts ==== | ||
| - | |||
| - | In Lab 05 you used bpftrace exclusively via one-liners (''-e'' flag). That works fine for quick investigations, but as your probes get more complex — multiple hooks, conditionals, helper functions — you'll want to write proper **script files** (''.bt'' extension). | ||
| - | |||
| - | The difference is minimal syntactically, but important in practice: a script file can have comments, be version-controlled, be shared with teammates, and be run with ''sudo bpftrace script.bt'' without the shell escaping headaches that come with one-liners. | ||
| - | |||
| - | In this task you'll write two scripts targeting functions you observed in your ''pwru'' trace from Task 03. | ||
| - | |||
| - | <note important> | ||
| - | **Before starting:** make sure you have a clean ''iptables'' state. Remove any DROP rules you added in Task 03: | ||
| - | <code bash> | ||
| - | $ sudo iptables -D OUTPUT -p udp -d 8.8.8.8 --dport 53 -j DROP | ||
| - | # verify: | ||
| - | $ sudo iptables -L OUTPUT -n | ||
| - | </code> | ||
| - | </note> | ||
| - | |||
| - | === [0p] Task A — Demo: coding style for bpftrace scripts === | ||
| - | |||
| - | Before writing your own scripts, study this example. It is not a task — there is nothing to submit. It exists to show what a well-structured ''.bt'' script looks like, so you have a reference when writing the next two. | ||
| - | |||
| - | <code bash nf_demo.bt> | ||
| - | #!/usr/bin/bpftrace | ||
| - | |||
| - | /* | ||
| - | * nf_demo.bt — demonstration script | ||
| - | * | ||
| - | * Counts how many times nf_hook_slow is invoked per second, | ||
| - | * broken down by the process that triggered the hook. | ||
| - | * Prints results every 3 seconds and resets counters. | ||
| - | * | ||
| - | * Usage: sudo bpftrace nf_demo.bt | ||
| - | */ | ||
| - | |||
| - | BEGIN | ||
| - | { | ||
| - | printf("Tracing nf_hook_slow... Ctrl+C to stop.\n\n"); | ||
| - | } | ||
| - | |||
| - | /* | ||
| - | * fentry fires at the entry of the kernel function. | ||
| - | * Faster and lower-overhead than kprobe. | ||
| - | * 'comm' is a bpftrace built-in: the name of the current process. | ||
| - | */ | ||
| - | fentry:nf_hook_slow | ||
| - | { | ||
| - | @invocations_by_process[comm]++; | ||
| - | } | ||
| - | |||
| - | /* Print and reset every 3 seconds */ | ||
| - | interval:s:3 | ||
| - | { | ||
| - | printf("-- %s --\n", strftime("%H:%M:%S", nsecs)); | ||
| - | print(@invocations_by_process); | ||
| - | printf("\n"); | ||
| - | clear(@invocations_by_process); | ||
| - | } | ||
| - | |||
| - | END | ||
| - | { | ||
| - | printf("Done.\n"); | ||
| - | } | ||
| - | |||
| - | |||
| - | Run it for a few seconds while generating some traffic (''curl'', ''dig'', etc.) and observe the output. Then read through the script again. This is the style expected in Task B.</code> | ||