After trying most of the bandwidth monitoring solutions listed in the Wiki, I decided to roll my own using an approach most similar to wrtbwmon. I wanted the ability to monitor bandwidth per host both from within the LuCI interface (using luci-app-statistics) as well as to be able to export the same data to an external data store.
iptmon is a shell script intended to be triggered by DHCP that adds iptables rules to track RX/TX per host. Packet counts are then parsed by collectd using the iptables plugin (collectd-mod-iptables), which exports the data to an external InfluxDB instance, finally ending up on pretty dashboards served up by Grafana.
It's lightweight, cross-platform, doesn't require a constantly running daemon eating CPU and memory, and uses the already present packet accounting functionality of the Linux kernel.
This looks really cool and I'd be interested in using this.
I am however slightly confused (and it's not your fault @oofnik).
It seems my dnsmasq automatically loads another custom dhcp-script out-of-the-box. To clarify, I don't have a dhcp-script line in my /etc/dnsmasq.conf file but instead, the custom script is automatically added in when I view /var/etc/dnsmasq.conf.
This is the custom script that my dnsmasq automatically executes:
@thencein Thanks for your interest!
I actually didn't know about the hotplug subsystem while writing iptmon and only recently discovered it. It seems to be poorly documented unfortunately
Looking at the code it seems like it would be a good idea to place wrappers in /etc/hotplug.d/dhcp and /etc/hotplug.d/neigh for iptmon instead of the current method of editing the dnsmasq base config directly.
For now the script in /var/lib/dnsmasq/dhcp-script.sh can be safely replaced by iptmon as long as there is nothing else that depends on scripts in either /etc/hotplug.d/dhcp/ or /etc/hotplug.d/neigh/.
All this script does is it calls the hotplug subsystem with the appropriate environment variables to trigger hotplug actions for DHCP and NDP/ARP events, respectively. This script will do nothing if there are no scripts in the aforementioned directories.
I'll do some testing and report back.
EDIT: There is a parameter available that's not listed in the Wiki called dhcpscript that can be used to override the default DHCP script triggered by dnsmasq. (source) I updated the Wiki
So, instead of editing /etc/dnsmasq.conf it's probably 'cleaner' to add this to /etc/config/dhcp:
However we need --script-arp to be enabled in dnsmasq for iptmon, and there is currently no option for that, making it necessary to add this directly to /etc/dnsmasq.conf.
I've opened a PR for this: https://github.com/openwrt/openwrt/pull/2842
Just to update, I've taken your feedback and went ahead with replacing the 'default' script (saved in /usr/lib/dnsmasq/dhcp-script.sh) and replaced it with the iptmon script. After that, a simple chmod of the script followed by a restart of dnsmasq did the trick and I can now see the data flowing into influxdb nicely
For now, it's going to be a waiting game to see whether anything has broken by me replacing the default script with your one. It could be that the hotplugs referenced in the old script are unused?
In the meantime, I can start visualising how I want my Grafana dashboard to look like
If option dhcpscript '...' is set, this doesn't replace the script, it just sets the variable USER_DHCPSCRIPT, which gets sourced by /var/lib/dhsnasq/dhcp-script.sh, preserving any previous functionality there may have been.
I spent a couple of hours learning the build system, and finally I can announce that iptmon has been released as an installable package!
Version 0.0.1 (all architectures) now available on the releases page: https://github.com/oofnikj/iptmon/releases
Installation instructions have been updated for package installation.
iptmon will remove the iptables entries for the device once it becomes unavailable, so no new data will be collected, but historical data will be preserved both in the RRDs and in InfluxDB (if configured).
In Grafana, if there are no data points available in the selected time frame for a particular series, that series will not be displayed -- at least, that's how it's behaving for me in version 6.6.2.
Yes, thanks, this was brought to my attention already. I will add a note in the readme about that.
I am familiar with nlbwmon, and at first I did try to build iptmon as a sort of 'extension' by running nlbw periodically and parsing the output - but decided against that approach for several reasons.
I am not really familiar with flow offloading (I'm working on x86 where it's not really necessary), but out of curiosity how does nlbwmon work with flow offloading? If I understand correctly, with this feature enabled, netfilter does not see the traffic at all. Maybe I'll need to do a little more reading...
Hello thank you for this very good plugin I am enjoying it's exactly what I was looking for, only thing that I would add is options for displaying packet graph and option to rename graphs I am always confused which one is upload and download I am looking at the moment for the code in system so I can disable it manualy but it will be great if all can do it by unchecking something I am only interested in bandwidth in MB
I understand your confusion re: rx and tx, but I opted not to make it configurable because IMO the flow direction in all bandwidth monitoring tools should be indicated from the perspective of the router. This means that if you are watching a YouTube video on host my-laptop, for example, you will see this data flow in tx_my-laptop. I think that the option to reverse the direction would only increase confusion.
Re: packet graphs, these come by default in luci-app-statistics under /cgi-bin/luci/admin/statistics/graph/iptables/mangle-iptmon_tx / rx for transmit and receive. I didn't look in to disabling them, but I think it would require some code changes to this package.
All iptmon does is manage the appropriate iptables rules to be able to monitor and identify traffic; it can't decide what the actual monitoring tools show through the UI.
Finally got around to adding support for static hosts.
Now any hosts defined in /etc/hosts or /tmp/hosts/* will be automatically included in the iptmon chains.