Watch Where the Linux Kernel Drops a Packet

dropwatch is great, I&#x27;ve used it to debug why our router firmware drops packets. It has some issues (I really need to verify which are still present and file them) but it works.<p>You can also achieve mostly the same effect with perf via the skb:kfree_skb tracepoint. This has less performance impact, better post-processing options, and doesn&#x27;t require the dropwatch specific kernel config option (NET_DROP_MONITOR).

I recently read a blogpost about post-mortem in google engineering blog. They also mentioned this tool to detect dropped dns packages. Generally, when I see something new or something I never heard of before, when I see it two times at least within frequent time intervals, it almost becomes impossible to forget that for me. Brain is weird.

I setup the AUR package [0] for this while troubleshooting some dropped UDP data and was kind of shocked at how hard this tool was to used. It reported tons of drops everywhere that I couldn&#x27;t observe from userspace on any of my tests.<p>Is anyone aware of an overview showing how to approach and get started with this tool?<p>[0] <a href="https:&#x2F;&#x2F;aur.archlinux.org&#x2F;packages&#x2F;dropwatch&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aur.archlinux.org&#x2F;packages&#x2F;dropwatch&#x2F;</a>

Link to the GitHub repo:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;nhorman&#x2F;dropwatch" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nhorman&#x2F;dropwatch</a>

Would something similar be achievable using eBPF?

Great to know such a tool exists ;-)<p>Thanks @2bluesc for creating the AUR for Arch (Yes, Arch + Manjaro user ;-)<p>NOTE: what surprised me was that Fedora 32 has dropwatch in its official repo (so simply dnf install dropwatch worked without fuss). It all made sense when discovering the author works for Red Hat when looking at the GitHub repo, well done.

Is it for any layer? If traffic is dropped at the frame&#x2F;L2 level or at the tcp layer, would this show?

Nice. Now where’s the repository?

oh boy! i had no idea such a utility existed, very cool.

cool, trying to understand 3. Ambiguity. from the output: 4 drops at unix_stream_connect+4ff (0xffffffffb8e089ef) 4 drops at unix_stream_connect+4ff (0xffffffffb8e089ef) 2 drops at tcp_v4_rcv+48 (0xffffffffb8db1618) 2 drops at unix_stream_connect+4ff (0xffffffffb8e089ef) 2 drops at unix_stream_connect+4ff (0xffffffffb8e089ef)<p>especially the reason for the drop? what does +48 in &quot;tcp_v4_rcv+48&quot; mean, thanks and sorry if this was documented? and I TL;dr