不管 traceroute 具体的工作原理是什么，只需要抓住一点：如果当前的包 IP 头里的 TTL 是 1，那么就可以回一个 ICMP TtlExceeded 包，这样就可以支持 traceroute 和 mtr 了。 TL;DR XDP 程序里的处理逻辑

有位 pwru 的用户在 GitHub 上提了一个 issue，说 --filter-trace-tc 不能正常工作。 option –filter-trace-tc not support 1 2 3 4 5 6 7 8 9 ...... ; event.addr = bpf_get_func_ip(ctx); 26: (bf) r1 = r6 27: R0=invP1 R1_w=ctx(id=0,off=0,imm=0) R6=ctx(id=0,off=0,imm=0) R7=ptr_sk_buff(id=0,off=0,imm=0) R10=fp0 fp-8=????mmmm fp-16=00000000 fp-24=00000000 fp-32=0mm0mmmm fp-40=mmmmmmmm fp-48=mmmmmmmm fp-56=mmmmmmmm fp-64=mmmmmmmm fp-72=00000000 fp-80=00000000 fp-88=00000000 fp-96=00000000 fp-104=mmmmmmmm

tc-dump 是一个基于 eBPF 的 tc 抓包工具，支持抓取 tc 的 ingress 和 egress 方向的包。 最近，tc-dump 支持了 pcap-filter，即支持了 pcap 的过滤语法。 与此同时，t

近来，没怎么学习 eBPF，就给 pwru 做下贡献。 Replace objs with collection Support tracing tc-bpf Support tracking skb clones Accelerate attaching/detaching kprobes WIP Replace objs with collection 该 PR 重构了一下 pwru 中管理 bpf 对象的代码，将 bpf 对象的管理从 struct 改成 c

前段时间，老板让我 手撕 分析 一个陌生的 XDP 程序。 责任重过山头，莫敢推辞，只能硬着头皮上了。 陌生的 XDP 程序 没有源代码，且发现该 XDP 程序还没带上 debug 信息；

最近在忙着些什么呢？没有发表 eBPF 技术文章了。 本公众号并没有被封号、也没有被禁言；其实，最近在忙着向内核 bpf 子系统贡献 patch，在不断完善 tailcall 这个

梅开二度，再次向内核 bpf 子系统贡献 patch。 bpf, x64: Fix tailcall infinite loop 此次修复的是 x64 平台的一个 bug，该 bug 会导致 tailcall 陷入无限循环，最终导致宕机。 tailcall 无限循环 如

通过 bpf: Support bpf program calling kernel function 学习 kfuncs 的实现。 不过，此 kfuncs 不是 bpftrace kfunc/kretfunc: Kernel Functions Tracing。bpftrace 的 kfunc 是的底层是 fentry/fexit。 BPF Kernel Functions (kfuncs) 该内核

tailcall in freplace 有 BUG？真的？假的！ 最近，偶然发现在 freplace 里使用 tailcall 有 BUG。尽管，我的同事早就发现了有问题，但不确定是不是内核的问题。所以，我就花了点时

在 eBPF Talk: trace tailcall 程序？NO！ 里，我们知道 tailcall 程序是不能直接使用 fentry/fexit 进行 trace 的。 如果通过内核模块，使用比较 hack 的方式，能否 trace tailcall 程序呢？ TL;DR 能对静态 tailcall 进行 tra