Unfortunately it's not compatible with flow offloading
You can rework @jow 's nlbwmon
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...
nlbw uses netfilter conntrack accounting, and
this patch takes care of accounting on offloaded connections.
Interesting, thanks for sharing this link.
May need to pick up some embedded router hardware to test flow offloading.
You can just enable flow offloading on your x86, no need to get a router
I see why flow offloading it's missing in my config now after going through the LuCI code.
I'm using a non-OpenWrt kernel because I'm running in Docker:
This has already caused some unexpected results, as one might imagine. Adding to the list
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
Hi @Liptovan, glad you found it useful.
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.
Oh i didn't know it's complicated like that I checked filesystem and I didn't found easy way to do it .. thx for information!
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.
New release v0.1.0 ready for download.
minor glitch @ master
dbg
+ eval '/usr/sbin/iptables -t mangle :iptmon_rx - [0:0]'
+ /usr/sbin/iptables -t mangle :iptmon_rx - '[0:0]'
Bad argument `:iptmon_rx'
Try `iptables -h' or 'iptables --help' for more information.
+ eval '/usr/sbin/iptables -t mangle -D FORWARD -j iptmon_rx'
+ /usr/sbin/iptables -t mangle -D FORWARD -j iptmon_rx
+ eval '/usr/sbin/iptables -t mangle -D iptmon_rx -s 127.0.0.1/32 -m comment --comment rx_localhost -j RETURN'
+ /usr/sbin/iptables -t mangle -D iptmon_rx -s 127.0.0.1/32 -m comment --comment rx_localhost -j RETURN
+ IFS='
'
+ /usr/sbin/iptables -t mangle -A iptmon_rx -s -j RETURN -m comment --comment rx_
Bad argument `RETURN'
Try `iptables -h' or 'iptables --help' for more information.
+ printf 'added iptmon entry for %s %s\n'
added iptmon entry for
+ IFS= read -r host
+ eval dnsmasq_add ff:ff:ff:ff:ff:ff ::1 localhost
+ dnsmasq_add ff:ff:ff:ff:ff:ff ::1 localhost
+ mac=ff:ff:ff:ff:ff:ff
Oh, I suspect it's because there are some newlines in your /etc/hosts
.
Can you share the output of:
cat /etc/hosts /tmp/hosts/* | grep '^$' | wc -l
If it's not 0, I forgot to account for newlines in those files, and that's probably what's causing the bug.
bingo! ( was 1 )
???
"init")
backup_orig
init_chain
finalize_chain
commit
load_static_hosts
cat /tmp/dhcp.leases | cut -d' ' -f2,3 | while read tMAC tIP; do
$0 arp-add "$tMAC" "$tIP"
done
Should be fixed now. Just pushed v0.1.1.
Needed to use a smarter grep
expression to handle both newlines and comments.
Could you give it a try?
yup... better...
Great, thanks for the feedback!
actually are we not hitting the counters now?
edit false alarm my bad
old
-A INPUT -j iptmon_input
-A OUTPUT -j iptmon_output
-A iptmon_input -j RETURN
-A iptmon_output -j RETURN
-A iptmon_rx -s 10.2.3.1/32 -m comment --comment rx_rpi-dca6325631 -j RETURN
-A iptmon_tx -d 10.2.3.1/32 -m comment --comment tx_rpi-dca6325631 -j RETURN
new (master)
-A INPUT -j iptmon_input
-A FORWARD -j iptmon_tx
-A FORWARD -j iptmon_rx
-A OUTPUT -j iptmon_output
-A iptmon_input -j RETURN
-A iptmon_output -j RETURN
-A iptmon_rx -s 127.0.0.1/32 -m comment --comment rx_localhost -j RETURN
-A iptmon_rx -s 10.2.3.1/32 -m comment --comment rx_rpi-dca6325631 -j RETURN
-A iptmon_tx -d 127.0.0.1/32 -m comment --comment tx_localhost -j RETURN
-A iptmon_tx -d 10.2.3.1/32 -m comment --comment tx_rpi-dca6325631 -j RETURN
Hm, it shouldn't have affected the rule generation.
I'd try to reload the firewall rules manually:
# iptmon init
# kill -HUP `pidof dnsmasq`
ok, cool... must have done something whacky... i'll sort it out!
iptmon sounds interesting but it seems I am too a neebie to understand everything.
I have OpenWRT 19.07.7
How can I check that:
iptmon
depends ondnsmasq
version >=2.80-16, which merged a PR to enablescript-arp
so make sure yourdnsmasq
package is up-to-date.If you are using
luci-app-statistics
prior to git commit4778aa6
you will need to upgrade as this commit merged a PR to fix the ip6tables firewall statistics view in LuCI.
dnsmasq -v gives me 2.80 but not much details more for example