Monitor bandwidth usage with bandwhich (and build a snap package of it) | Hacker News Reader

Monitor bandwidth usage with bandwhich (and build a snap package of it)

popey.com

46 pointsjandeboevrie25 comments

Very, very awesome! I love the per process table. How does that work?

CBM was a fine tool [0]. I think it's been basically abandoned though. It does only do per interface, but it seems like an earlier simpler iteration of this type of tool. It works by reading the stat tables in /proc/net/dev

I'd just throw our something I wrote a long time ago called fsbm [1] (fucking small bandwith monitor) which was a rewrite of CBM without curses. useful for logging to a file or to something without NCURSES support. Along the way I added support for network namespaces and just general other stuff. I use it frequently. You can pump it into i3-bar for example or such and such

[0] https://github.com/resurrecting-open-source-projects/cbm [1] https://git.ceux.org/fsbm.git/tree/fsbm.c

I'm not sure how it works beyond that it reads /proc, but whatever it does it uses a whole lot more compute than nethogs does (which also displays per process and also uses /proc as the information source). This is fine for most of my machines, but for lower-specced machines I'll probably have to stick with nethogs[1]

[1]: https://github.com/raboof/nethogs

If it the popey from podcasts he used to work at Canonical. Actually looking at this confused, popey also came up with the snap removal tool that is handy https://github.com/popey/unsnap

Maybe he has a love hate relationship with snaps lol

Edit: added gh info

Yeah I would strongly bet it is the same Popey from the JB podcasts. Last I heard him he was pretty pro-Snap and was Snapping different projects for people, so this is completely in-line with my expectations. Seems pretty unlikely to be a coincidence :-)

Why does this need a snap, when it could probably be compiled to a single binary?

Availability in the Ubuntu Store, presumably.

Put it in Debian, it will get to base Ubuntu eventually...

I gather that the "eventually" part is what Snaps are attempting to solve/bypass.

The banwhich part is much more interesting than the snap part.

snap is the first thing to get the apt-get purge treatment whenever I install a new ubuntu box.

Agreed. TFA author either currently or previously worked for Ubuntu, so it makes sense to me that they are a big proponent of Snap. Personally, I would rather build from source than install a Snap.

Bandwhich looks like a neat tool[1]

[1]: https://github.com/imsnif/bandwhich

This feels like the setup for a limerick:

There was a monitoring app called bandwhich that fits a network administrator's niche

something something something something something something

sudo make me a sandwich.

Neat idea! I'll give it a whirl

A monitoring app for bandwidth

Captured many false positives that which,

Once analyzed with a filter

Revealed nothing off-kilter.

So I told it to make me a sandwich

The only thing I like about this is the idea of the bandwhich tool.

The rest of it is adding more mechanism than is required for such a utility. I see so much these days where people can't see the simplest path to the solution of the problem and build complicated Rube Goldberg machines around them. They do nothing other than serve the ego of the person.

Give me a static bin and the sha256.

Edit: oh wait, the upstream already do that! Why all this?!?!?!?!

I personally enjoyed it because it seems like a good guide to publishing a snap, which... is a thing people do (and I've never seen a write-up detailing the process from start to finish).

I admit the submission title probably emphasizes the wrong portion of the content, but if you're not interested in building a snap, this is just not the right post for you.

Similar to bandwhich, I recently created a snap of my own bandwidth monitor, picosnitch [1]. However I was only able to get it working with classic confinement due to there being no snap interfaces for fanotify or BPF kfuncs. Unfortunately this meant it couldn't be published on the store.

I already packaged it for nearly every distro, but unfortunately most don't have dash [2] in their repos so the user needs to install it separately, and I was hoping that snap would be an easier solution for that.

[1] https://github.com/elesiuta/picosnitch/blob/master/snap/snap...

[2] https://repology.org/project/python:dash/versions

It's in the AUR. yay -S bandwich (I run a computer actually).

I deliberately ran it as my unpriv user account and it spat out an easy to understand summary of why it won't work and some great suggestions on how to fix it.

It looks lovely, does a job very well and goes straight into the toolbox.

I run luci-app-vnstat on my OpenWrt router, default config except that DatabaseDir is on a USB flash drive.

This doesn't provide device or app-level granularity, but I can see my network's total bandwidth usage for previous hours, days, and months, which is useful for avoiding Comcast's 1.2TB data cap.

> I don’t recall why I had docker installed, and was happy to remove it. Never liked docker

Some people not only like it, but require it for their work - seems like an odd prerequisite.

who really likes snaps?

C'mon, you know they're awful. You know it's not every package using up a loopback device... You know it's not little tricks like hiding apt-get install packages in snap. You know its' not me having a choice in the matter. Really, why is snap so crappy.

Stopped reading at the "remove docker" line. Like, really?

> Stopped reading at the "remove docker" line. Like, really?

Why so incredulous about removing docker?

Did you read the part right before about how the networking interferes with LXD? "remove docker" is a pretty damn good solution to those types of problems as Docker notoriously hacks iptables and screws up all sorts of other apps that rely on it to do networking work. I've had to do that on my desktop in order to get bridges working in kvm (I started using podman instead which plays nicely with kvm).

What alternative solution do you offer instead for fixing the LXD networking?

There's no need to be so defensive. HN has a lot of web developers and, for better or worse, docker is an integral part of their workflow. So any guide brushing off "yeah just remove docker" with no further explanation will naturally be met with incredulity...

Thanks that's valuable feedback. I didn't mean to sound defensive!

Are these issues true for Podman as well? Podman's drop-in ability vs. Docker seems impressive so far for me, but I have yet to really stretch it.

Nope! Podman does things different and works very well with other network tools like kvm and lxd.

Reply on news.ycombinator.com