Bandwidth monitoring on Orbi

[mith_y2k]

When you installed did you pick OpenWRT as the OS or something else? The base files are installed in /top/www for me (no yamon). If I symlink that directory inside /www (I.e. /www/yamon) it sort of works but I also get the JavaScript error

 

[R. Gerrits]

Yes, used OpenWRT, with advanced configuration and then changed some stuff.

 

[RMinNJ]

I agree Netgear (and all manufacturers) really could have given this data since the router has it..baffles me as the one of the primary purposes of a router is send and receive data on the WAN interface.

I got lazy with packages on the R7800 and use this program called softperfect networkx on my linux laptop. Sadly they only make it for windows and macs now.

probes the It probes the routers WAN port with UpnP i believe and gives live
usage. I found it fairly accurate; kid downloading an xbox game...uses my entire pipe. Previews on
the netflix screen I've seen burst to 60Mbit.

Let us know if you get any packages working the router. A simple iftop on the wan port would be fine with me.

 

[mith_y2k]

I was looking for something that tells me the bandwidth for every device. I'm not looking for detailed analytics, but I would like to see live usage (like yours) and aggregated data, maybe daily, weekly, monthly. I am looking to better understand which devices use most bandwidth and if there are any unexpected spikes (a firmware upgrade, a new device, a virus, etc).

YAMon seems close, but it needs some work and I fear that the Netgear/Voxel community is too small unless someone decides to get their hands dirty and contribute back to the main project. I have time to tinker here and there like I did so far, I'm not sure I can dedicate the time to learn the details of the project and fix it. I'm also not an expert of bash scripting and of netgear's software.

 

[RMinNJ]

Oh wow..live usage per device would be nice... I often wondered if Ubiquity had that in there software/ecosystem since they are so software centric. I have so few devices in my home comared to others to have a need for this..always simple.. kids are using the most data and bandwidth.

 

[mith_y2k]

While I haven't made progress on this for a long time I keep thinking about it every now and then. Inspired by Aegis, I was thinking of coming back to this and use iptables for tracking. While this is all command line, I think it would not be that hard to extract the information and turn it into a graph. I'm no iptables expert, but this tutorial seems easy enough, unfortunately the chains are created, but nothing is being tracked for me, see https://www.cyberciti.biz/faq/linux-configuring-ip-traffic-accounting/

Any ideas?

 

[R. Gerrits]

Most logical cause is that you inserted the rules at the wrong place.
Can you share the output of iptables -nvL ?

What you also should know (at least this is the case on R7800) -> traffic that is handled by the hardware accelleration, is not counted in the iptables statistics.
So if you want accurate reports, then you might need to disable hw accelleration. (depending on how fast your network is, you may or may not notice this.

Also counters might be reset by the firmware at unexpected moments. So you'd need to pull and store the date quite frequently.

(btw, not sure if kamoj's addon also can be installed on Orbi -> because that already has a simple Bandwidth monitor based on IP-tables built-in.)

 

[mith_y2k]

I don't know if anyone has tried Kamoj on Orbi. @HELLO_wORLD might agree or disagree, I would say that to get Aegis to work it was probably 80% working out of the box and 20% needed debugging. I think the fixes were simple once we figured out what were the differences.

Speaking on the iptables I created, the whole print out is pretty large, but I think this should be meaningful:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 4215  265K aegis_src  all  --  brwan  *       0.0.0.0/0            0.0.0.0/0            match-set aegis_bl src /* incoming in aegis blocklist */
  15M  851M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  host0  *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  LeafNets *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     41   --  *      *       0.0.0.0/0            0.0.0.0/0           
  706 25416 ACCEPT     2    --  brwan  *       0.0.0.0/0            0.0.0.0/0           
 736K 1438M brwan_in   all  --  brwan  *       0.0.0.0/0            0.0.0.0/0           
2507K  180M br0_in     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 common     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 reject     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 bandwidth  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   53  4296 aegis_src  all  --  brwan  *       0.0.0.0/0            0.0.0.0/0            match-set aegis_bl src /* incoming in aegis blocklist */
  267 36187 aegis_dst  all  --  *      brwan   0.0.0.0/0            0.0.0.0/0            match-set aegis_bl dst /* outgoing in aegis blocklist */
 427K   41M BD_FILTER  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 139K   15M brwan_fwd  all  --  brwan  *       0.0.0.0/0            0.0.0.0/0           
 288K   26M br0_fwd    all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 common     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 reject     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0            all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 bandwidth  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain bandwidth (2 references)
 pkts bytes target     prot opt in     out     source               destination

I am not pasting the OUTPUT chain since it's unaffected. As you can see the "bandwidth" chain is created, but it's not tracking any traffic

these are the commands I executed. My thinking was to first see if the counters are actually working:

root@RBR50:~# iptables -N bandwidth
root@RBR50:~# iptables -A FORWARD -j bandwidth
root@RBR50:~# iptables -A INPUT -j bandwidth

PS: I would not have a problem with frequent saving and storing and TBH I'm not monitoring for billing, but just to check which devices use most of the network and for any big spikes in traffic for security. Even if a few bits are lost here and there I won't be pulling my hair

 

[R. Gerrits]

You should jump to the new chain first. They are now at the end, so they are never reached.

iptables -N bandwidth
iptables -I FORWARD -j bandwidth
iptables -I INPUT -j bandwidth

and then for the IP-addresses that you want to monitor, add rules to the bandwidth chain.
for instance:
iptables -I bandwidth -d 192.168.1.100 -j RETURN
iptables -I bandwidth -s 192.168.1.100 -j RETURN

This would allow you to see how much traffic 192.168.1.100 is receiving and sending

 

[mith_y2k]

Thank you @R. Gerrits you're always helpful and clear. I have 2 more questions.

With the -I option I insert the rule at the top, would this interfere with other rules? Would I end up skipping other rules that are more important later?

From the tutorial I had followed it looked like I could be explicit to track the traffic of given IPs, but at least the way I read it by not specifying any IP I was tracking all of them. In your second point you seem to imply that only the IPs I specifically add to the chains will be tracked, is that right?

I had already been thinking about this and I was wondering if I will have to create a script that periodically reads the full list of attached devices to add or remove rules. The other alternative is that I manually assign the IP and track those, but that would prevent me from tracking possible new devices that I would add in the future.

 

[HELLO_wORLD]

I agree @mith_y2k

Aegis was even over 95% already ready for Orbi.
What was left to do was dealing with a few differences in the environment (different file names, little difference in behavior), but not a huge work.
What took time was to pinpoint those things, using extensive debugging.

Same for the web part. Most of it was dealing with a difference of web server (uhttpd vs lighttpd). Thankfully here too, it was not a huge task, and most of the work was again pinpointing.

The good thing is it forced to review portions of code that are rarely used, and helped to improve aegis overhaul.


About iptables, the insertion -I can take a position:
iptables -I chain 3 some rule
It will insert some rule in third position in the chain.

 

[R. Gerrits]

With the -I option I insert the rule at the top, would this interfere with other rules? Would I end up skipping other rules that are more important later?

nope, because in the chain bandwidth, we use the "-j RETURN" on successfull matches -> this will jump back to the rule immediately after the initial "-j bandwidth" rule.
And if nothing matches in chain bandwidth, it also jumps back.

HELLO_wORLD is right, we could also specify a number to insert this in a specific place. So we could for instance have inserted them after the aegis rules (if they exist).
But as this chain bandwidth has no rules that would accept traffic, there is no risk of applying these rules first.

 

[mith_y2k]

@R. Gerrits I love the “we” here

@kamoj is your add on open source? Would it make sense to take some parts and adapt for Orbi? Is there broader interest among Orbi users?

 

[kamoj]

Sure, I mean it's free to use - thank you for asking.
It should be pretty forward to do it.
At least to get started.

You only need one shell script (addon_bwusage.sh) and some cron jobs (included in script).
The script is the same for my beta add-on R7800/R9000 so just unpack the .ipk with 7-zip and get started!

The code has a lot of comments so it should be easy to make the few changes needed!

/tmp/addons/manuf.txt is created with 10 lines to take from addons.sh,
and to start with maybe you can ignore/comment out the tries to identify the device better
through functions in addon_bypassvpnip.sh.

The script even outputs a html-page, not the most beautiful, but informative.

The only control from my GUI is "on/off" and "reset", which I don't know how to do for Orbi.

Please keep us posted !!!

Thank you for all your help to the community and here in SNB!

EDIT:
You should also use the addon_bwusage.htm file, or use another way to trick the webserver.
@HELLO_wORLD would know how to do!

@R. Gerrits I love the “we” here

@kamoj is your add on open source? Would it make sense to take some parts and adapt for Orbi? Is there broader interest among Orbi users?

 

[mith_y2k]

Ehm, where do I download it?

 

[c00labah]

Has anyone managed to get Yamon installed on an RBR50 v2 running the latest Voxel (the model without the USB port)? If so, are you able to share instructions on how you achieved this?

(The install script doesn't work, and manual install leads to permissions problems - 430 Forbidden.)

 

[mith_y2k]

No one is using it as far as I know. I also contacted the maintainer back in the day but they didn’t answer

 

[agneev]

I'll share something that I've found to work reliably.

Couple of caveats: this is per network interface, not per device. This setup also requires a separate device, I'm using Docker on a Raspberry Pi. You can get this working on the Orbi itself but I'm not quite sure about configuring a HTTP server.

Basically I get graphs like this:

I'll leave instructions here, in case anyone is interested:

To set this up, install vnstat2 on Orbi, a Rclone mount is also required on the router:

root@Orbi:/tmp/mnt/sda1/entware/etc/init.d# cat S61rclone-vnstat-router
#!/bin/sh

ENABLED=yes
PROCS=rclone
ARGS="serve webdav --addr 10.0.0.1:9001 /tmp/mnt/sda1/entware/var/lib/vnstat"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

On your server, you need to mount it, also using Rclone. So create a webdav remote and mount it. I use a cron job:

@reboot sleep 30 && rclone mount rv: /mnt/res --allow-other --daemon

Then finally, docker-compose up -d:

version: '3.9'

  vnstat-router:
    image: vergoh/vnstat
    container_name: vnstat-router
    restart: unless-stopped
    environment:
      SERVER_NAME: orbi
      LARGE_FONTS: 1
      HTTP_LOG: /dev/null
      RUN_VNSTATD: 0
    ports:
      - 8000:8685
    volumes:
      - /mnt/res:/var/lib/vnstat
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro

Then go to <SERVER_IP>:8000.

 

[mith_y2k]

When you say network interface do you mean Orbi interface? Most of my devices are WiFi so traffic will be heavily aggregated. Do you at least get a breakdown between devices connected to the router and ones connected to either satellite?

 

[agneev]

When you say network interface do you mean Orbi interface

Yeah, so eth0 is the WAN interface, there's also interfaces for the 2.4GHz, 5GHz. There's a breakdown here someplace.

Do you at least get a breakdown between devices connected to the router and ones connected to either satellite?

I'm not too sure about multiple satellites, I think there's two interfaces for 5GHz and 2.4GHz connection to satellites that have aggregated data.

But yeah, the network interface ath2 is the backhaul 5GHz interface and I have that enabled. Since it's from the POV of the router, upload corresponds to download to your devices.