What's new

vnStat [Release] vnStat-on-Merlin - UI, CLI and email - data use and data limit monitoring - R1 and R2

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

For those who asked about amtm email: I just checked the code for v.2.0.2 and it should be set to use amtm email.

Are you on vnstat-on-Merlin R2, specifically v2.0.2 and have you installed and tested amtm email and confirmed amtm email is working?
 
For those who asked about amtm email: I just checked the code for v.2.0.2 and it should be set to use amtm email.

Are you on vnstat-on-Merlin R2, specifically v2.0.2 and have you installed and tested amtm email and confirmed amtm email is working?
I changed to jackyaz-dev repo and it works.
 
I changed to jackyaz-dev repo and it works.
Not really helpful, but whatever. Would be more community-minded if you'd be a regular user participating in our efforts.
 
Meaning that when on main branch, the amtm email didn't work.
To make it work, I changed to jackyaz branch, with their last commits amtm email integration started working.
Not really helpful, but whatever. Would be more community-minded if you'd be a regular user participating in our efforts.
 
I believe it is working for me.
 
I'm going reach out to the vnStat (Linux app) developer (who has, on occasion, participated in Jack and my development of vnStat-on-Merlin) to see if this is something known.
@tsanga The author of vnStat (linux application) responded:

That looks strange as it isn't an exact 1:1 mirroring even if rather close. I haven't seen that sort of behaviour before. Any idea if that's the right interface to begin with?

If the device is used as a switch in that scenario then one explanation could be that the interface being monitored is the bridge interface in which case it would be normal that traffic received by the switch from one port and then forwarded to another would result in pretty much 1:1 traffic.

So we're back to "what i the setup and is it right". Can you confirm that it's eth0 now being monitored and not one of the bridges (e.g., br0), and that you're not using the router as a switch (e.g., not the primary routing device for your network).

  • Let's try uninstalling dn-vnstat and confirming that the previous configuration and databases are deleted (will be prompted during uninstall).
  • It would be good to have a reboot if that's practical. If not, move to the next step
  • Check the /jffs/addons folder - there should NOT be a /jffs/addons/dn-vnstat.d/ folder. If it's there, something did not uninstall properly. Delete or rename that folder.
    • Note: checking folder and file structure is easiest using a program like WinSCP, but can be done from the SSH CLI (e.g., cd /jffs/addons > ls)
  • Using SSH and run nload -m and monitor your upload/download speeds during some activity. You may need to scroll (using the arrow keys) to find the eth0 interface. Are you seeing symmetric data there too?
    • Note: if nload isn't installed, install it via SSH with opkg install nload. I don't recall if this is part of the standard install.
  • If nload -m shows the expected traffic on the interface of interest (e.g., somewhat asymmetric results), reinstall dn-vnstat. What interface is automatically identified?
  • If the auto detection does not choose eth0, please enter eth0 as the interface manually
Report back with your findings, please.
 
@tsanga The author of vnStat (linux application) responded:



So we're back to "what i the setup and is it right". Can you confirm that it's eth0 now being monitored and not one of the bridges (e.g., br0), and that you're not using the router as a switch (e.g., not the primary routing device for your network).

  • Let's try uninstalling dn-vnstat and confirming that the previous configuration and databases are deleted (will be prompted during uninstall).
  • It would be good to have a reboot if that's practical. If not, move to the next step
  • Check the /jffs/addons folder - there should NOT be a /jffs/addons/dn-vnstat.d/ folder. If it's there, something did not uninstall properly. Delete or rename that folder.
    • Note: checking folder and file structure is easiest using a program like WinSCP, but can be done from the SSH CLI (e.g., cd /jffs/addons > ls)
  • Using SSH and run nload -m and monitor your upload/download speeds during some activity. You may need to scroll (using the arrow keys) to find the eth0 interface. Are you seeing symmetric data there too?
    • Note: if nload isn't installed, install it via SSH with opkg install nload. I don't recall if this is part of the standard install.
  • If nload -m shows the expected traffic on the interface of interest (e.g., somewhat asymmetric results), reinstall dn-vnstat. What interface is automatically identified?
  • If the auto detection does not choose eth0, please enter eth0 as the interface manually
Report back with your findings, please.

Thanks for your help with this.

vnStat is not currently installed. It usually detects eth0 as the interface, and when I was testing vnStat, I confirmed the .conf file had eth0 configured.

nload wasn’t installed with the default packages. Here’s my output during a few minutes of Netflix streaming:
Code:
Device eth0 [redacted external IP] (4/15):
============================================
Incoming:                 Outgoing:
Cur: 24.95 kBit/s         Cur: 21.41 kBit/s
Avg: 4.39 MBit/s          Avg: 4.39 MBit/s
Min: 4.73 kBit/s          Min: 3.51 kBit/s
Max: 57.19 MBit/s         Max: 57.18 MBit/s
Ttl: 1.23 GByte           Ttl: 1005.54 MByte

Right away, it seems weird that the average numbers are identical! The current number would oscillate a bit asymmetrically with the download rate happening in bursts, but the average would be very close to each other.

If I use nload in graphical mode (without -m) on eth0, I can see traffic spikes that are basically identical in both outgoing and incoming.

My setup:
Code:
Fiber modem —> AiMesh Router WAN port
                             LAN port —> 8 port unmanaged switch —> AiMesh node
                             LAN port —> Asus RT-AC66U acting as a switch in AP mode

I checked the Asus Traffic Monitor once more, and the tx/rx patterns are what I would expect for the times of day. Movie in the evening (orange), backups at night (cyan).
1640182321097.png


How is the Asus monitor measuring correctly but not nload?
Is it possible my fiber modem is “reflecting” traffic back through the WAN port? I don’t understand how this would even work for both uploads and downloads.
Is it possible for port forwarding to put traffic in a loop? I didn’t think this would be the case for a few ports I have open for Plex, VPN (server is not on the router) etc.
 
Thanks for your help with this.

vnStat is not currently installed. It usually detects eth0 as the interface, and when I was testing vnStat, I confirmed the .conf file had eth0 configured.

nload wasn’t installed with the default packages. Here’s my output during a few minutes of Netflix streaming:
Code:
Device eth0 [redacted external IP] (4/15):
============================================
Incoming:                 Outgoing:
Cur: 24.95 kBit/s         Cur: 21.41 kBit/s
Avg: 4.39 MBit/s          Avg: 4.39 MBit/s
Min: 4.73 kBit/s          Min: 3.51 kBit/s
Max: 57.19 MBit/s         Max: 57.18 MBit/s
Ttl: 1.23 GByte           Ttl: 1005.54 MByte

Right away, it seems weird that the average numbers are identical! The current number would oscillate a bit asymmetrically with the download rate happening in bursts, but the average would be very close to each other.

If I use nload in graphical mode (without -m) on eth0, I can see traffic spikes that are basically identical in both outgoing and incoming.

My setup:
Code:
Fiber modem —> AiMesh Router WAN port
                             LAN port —> 8 port unmanaged switch —> AiMesh node
                             LAN port —> Asus RT-AC66U acting as a switch in AP mode

I checked the Asus Traffic Monitor once more, and the tx/rx patterns are what I would expect for the times of day. Movie in the evening (orange), backups at night (cyan).
View attachment 37948

How is the Asus monitor measuring correctly but not nload?
Is it possible my fiber modem is “reflecting” traffic back through the WAN port? I don’t understand how this would even work for both uploads and downloads.
Is it possible for port forwarding to put traffic in a loop? I didn’t think this would be the case for a few ports I have open for Plex, VPN (server is not on the router) etc.
can you share the output of
Code:
ifconfig -a
masking your public IP and MAC addresses as appropriate? alternatively please feel free to PM me
 
can you share the output of
Code:
ifconfig -a
masking your public IP and MAC addresses as appropriate? alternatively please feel free to PM me
Thanks Jack.
Code:
br0       Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B0 
          inet addr:10.48.48.1  Bcast:10.48.48.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:5968109 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3274662 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:784816629 (748.4 MiB)  TX bytes:799188215 (762.1 MiB)

br2       Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B5 
          inet addr:192.168.102.1  Bcast:192.168.102.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:253 errors:0 dropped:0 overruns:0 frame:0
          TX packets:517 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:11638 (11.3 KiB)  TX bytes:31583 (30.8 KiB)

dpsta     Link encap:Ethernet  HWaddr 00:00:00:00:00:00 
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B0 
          inet addr:[redacted]  Bcast:[redacted]  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:339535780 errors:0 dropped:0 overruns:0 frame:0
          TX packets:312095486 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2175239798 (2.0 GiB)  TX bytes:1920661109 (1.7 GiB)
          Interrupt:179 Base address:0x4000

eth0.502  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B0 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:217402 errors:0 dropped:0 overruns:0 frame:0
          TX packets:74337 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:10001504 (9.5 MiB)  TX bytes:4164896 (3.9 MiB)

eth1      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B0 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1128817 errors:0 dropped:0 overruns:0 frame:14000599
          TX packets:3789545 errors:293 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:182258851 (173.8 MiB)  TX bytes:1494888407 (1.3 GiB)
          Interrupt:163

eth1.502  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B0 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:101373 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:5680936 (5.4 MiB)

eth2      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B4 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:13235741 errors:0 dropped:0 overruns:0 frame:16212117
          TX packets:36787674 errors:486 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3109157927 (2.8 GiB)  TX bytes:2005885977 (1.8 GiB)
          Interrupt:169

eth2.502  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B4 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:101371 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:5680824 (5.4 MiB)

ifb0      Link encap:Ethernet  HWaddr yy:yy:yy:yy:yy:4F 
          BROADCAST NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ifb1      Link encap:Ethernet  HWaddr zz:zz:zz:zz:zz:7F 
          BROADCAST NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
          RX packets:1577331 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1577331 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:275195110 (262.4 MiB)  TX bytes:275195110 (262.4 MiB)

lo:0      Link encap:Local Loopback 
          inet addr:127.0.1.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1

vlan1     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B0 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:125247689 errors:0 dropped:0 overruns:0 frame:0
          TX packets:177651914 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:111236185638 (103.5 GiB)  TX bytes:231335595797 (215.4 GiB)

vlan2     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B0 
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wl1.1     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:B5 
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:16212117
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
ah, i wonder if this is an AiMesh guest network thing. are you using a guest network #1 with access intranet disabled?

Looking at the counters, vlan1 might be worth trying in vnstat and nload
assuming you've downloaded 200gb+ and uploaed 100gb+ since reboot!
 
ah, i wonder if this is an AiMesh guest network thing. are you using a guest network #1 with access intranet disabled?
Yes, I use AiMesh guest copied to all nodes, with intranet disabled. But I must note when I tried a complete reset, I didn’t set up AiMesh at all, and it was still doing this symmetric workload.

Looking at the counters, vlan1 might be worth trying in vnstat and nload
assuming you've downloaded 200gb+ and uploaed 100gb+ since reboot!
I thought about using vlan1 too. Is there any downside to doing this - the only thing I read in this thread is you can’t disable HW acceleration on it. But I would probably run vnStat with HW accel on anyway, I don’t need exact accurate numbers. I’d note that HW acceleration on/off didn’t impact the symmetric workload.

Edit: uptime is a bit over 6 days, so the vlan1 numbers seem reasonable. I’ll work on getting a nload readout for vlan1.
 
Last edited:
can you share the output of
Code:
ifconfig -a
masking your public IP and MAC addresses as appropriate? alternatively please feel free to PM me
How is the Asus monitor measuring correctly but not nload?
Is it possible my fiber modem is “reflecting” traffic back through the WAN port? I don’t understand how this would even work for both uploads and downloads.
Is it possible for port forwarding to put traffic in a loop? I didn’t think this would be the case for a few ports I have open for Plex, VPN (server is not on the router) etc.

@tsanga , can you describe the Plex setup? Is there something off-site that is syncing or using data?
 
@tsanga , can you describe the Plex setup? Is there something off-site that is syncing or using data?
It’s a single port forward to a fixed internal IP to make my Plex server accessible from outside. I’m not serving content to anyone except occasionally for our family.

I run other servers behind my router for private use (offsite backup for extended family, file sharing) which require other ports to be forwarded to the same fixed internal IP. But those are scheduled tasks and I wouldn’t expect simultaneous upload/download unless something is rogue or misconfigured. That’s why I’m interested to figure out whether vnstat is reporting something “real” on eth0.

Edit: I wouldn’t expect streaming Netflix to an iPad to trigger any file syncing services from my server. Or my own offsite backup task at 2am to have simultaneous incoming traffic.
 
Last edited:
Looking at the counters, vlan1 might be worth trying in vnstat and nload
assuming you've downloaded 200gb+ and uploaed 100gb+ since reboot!
Here’s my nload output for vlan1 after a few minutes of movie streaming:
Code:
Device vlan1 (1/1):
=========================================
Incoming:Outgoing:
Cur: 1.84 kBit/s       Cur: 3.55 kBit/s
Avg: 90.19 kBit/s      Avg: 2.60 MBit/s
Min: 872.00 Bit/s      Min: 3.20 kBit/s
Max: 2.28 MBit/s       Max: 24.58 MBit/s
Ttl: 103.80 GByte      Ttl: 216.70 GByte

This is pretty much as expected.

The interesting thing with eth0 is sometimes it starts measuring the expected throughputs, only for the incoming and outgoing to converge after some seconds/minutes.

Do you have any ideas why eth0 and vlan1 would be so different? If I understood this maybe I can see what else in my home network could be a culprit.
 
For those who asked about amtm email: I just checked the code for v.2.0.2 and it should be set to use amtm email.

Are you on vnstat-on-Merlin R2, specifically v2.0.2 and have you installed and tested amtm email and confirmed amtm email is working?
On a separate note:

I just reinstalled vnstat 2.0.2 via amtm, and found two things:
- I said “no” to the default eth0, specified vlan1, and it still wrote the .conf for eth0. Edit: after I manually changed .conf file, I got “Error: Interface "vlan1" not found in database.”

- I tried to toggle daily emails with the new amtm email setup, and it told me diversion was not installed even though amtm has successfully sent a test email.
 
Last edited:
Happy holidays, fellow Merlin-enthusiasts.

vnStat-on-Merlin (dn-vnstat) version 2.0.3 - R2 - is now available. The primary change is to check for amtm messaging existence. If available, vnStat-on-Merlin will use amtm messaging preferentially.

If amtm messaging is not configured, will continue to use Diversion.

Notes:
  • The Diversion requirement is now deprecated in vnStat-on-Merlin R2. In a future update (TBD), only amtm messaging will be supported. This change is only for R2.
  • vnStat-on-Merlin R1 (primarily MIPS-based routers and older firmware versions) still uses Diversion messaging credentials.
    • Also on R1, there is a "false update" message that may show for vnStat-on-Merlin if you update to amtm 3.2.1. You may be shown that v 2.0.3 is available, but when you attempt to update you are informed - correctly - that the 1.0.2 version is the latest. You should ignore this update prompt in 3.2.1. The R1 update to 1.0.3 appears to fix this notification (see next post).
  • There are some other minor updates to configuration (e.g., new config file locations), performance and back-end tweaks to charts.
Again my thanks to @Jack Yaz for his work on this application!
 
Last edited:
Bonus update: if you're running R1 (MIPS and older firmware) and you update amtm to 3.2.1 or later, amtm messaging is now used, thus removing the requirement for Diversion, even in R1.

Diversion-based messaging may continue to work, but to future-proof your setup, you should activate and test amtm messaging.

If amtm messaging does not appear on the amtm menu, engage it by typing em and then following the steps to insert your credentials and test.
 
Last edited:
Guys I have been searching, how can I add a second wan to the interface? And how can I make the data more in detail like the traffic analizer.
 
Guys I have been searching, how can I add a second wan to the interface? And how can I make the data more in detail like the traffic analizer.
Not supported in this implementation.

You could read this and try to implement it. Report back if successful.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top