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

[BailA]

With 2.5GB network card is it necessary to edit the config file?
Thank you

 

[elorimer]

I have a small puzzle with vnstat on my ax86 pro. Unpredictably, the statistics stop updating. I'm not seeing any error message in the logs, but the statistics don't update in the cron job, and don't update if the stats are updated from the web page. This is true if I reinstall keeping the old stats, but not if I delete the old stats.

 

[dev_null]

I have a small puzzle with vnstat on my ax86 pro. Unpredictably, the statistics stop updating. I'm not seeing any error message in the logs, but the statistics don't update in the cron job, and don't update if the stats are updated from the web page. This is true if I reinstall keeping the old stats, but not if I delete the old stats.

I saw this once in my testing during development of R2. IIRC reboot fixed it, but if not try the following:

• Identify the path to your "entware" folder (typically /tmp/mnt/<<usb drive>>/entware/)
• Issue the following command /tmp/mnt/<<usb drive>>/entware/etc/init.d/S33vnstat stop - you should see a message confirming vnStat is halted
• Then issue the following command /tmp/mnt/<<usb drive>>/entware/etc/init.d/S33vnstat start - you should see a message confirming vnStat is running
• Wait a few minutes for some data use, then run dn-vnstat and pick 1 to update - you should see today's date with some data usage

The time this happened was during early testing of R2 and I didn't encounter it subsequently. If it continues, you could try updating entware apps to see if that fixes it. I have an AX86 (not pro) so I wonder if it's a kernel thing (I have no way to test if it is).

Note: /tmp/mnt/<<usb drive>>/entware/etc/init.d/S33vnstat restart is also a valid command, but I seem to recall it hanging during stopping vnStat, thus my recommendation for separate stop and start commands.

 

[elorimer]

that restarted it, thanks. I wonder what stops it?

 

[dev_null]

that restarted it, thanks. I wonder what stops it?

Glad to hear it.

I don't know and it didn't happen more than once or twice. vnStat seemed to think it *was* running, but it had lost it's connectivity to the IP stack at the very least. Maybe some sort of race condition. If it happens again, I can reach out to the vnStat developer (who occasions SNB at least infrequently).

 

[elorimer]

Kicked off again twice in the last 72 hours.

 

[dev_null]

Kicked off again twice in the last 72 hours.

Other than a nuclear reset and rebuild I don't know have other specific solutions for you. This issue is not common (it is only coincidental that I even saw this during preliminary testing).

Is data being correctly reported on the built-in tools in AsusWrt (e.g., Traffic Monitor)? Are e all of your other apps/add-ons are working (e.g., this isn't an Entware/dependency thing)?

I will ping the vnStat *nix application maintainer to see if s/he's seen this and has any suggestions.

 

[dev_null]

@elorimer - I did hear back from the vnStat application owner (Teemu) and got pretty much the same answer "saw it once on a Raspberry Pi, haven't been able to reproduce it" and "no other reports", so it's obviously something specific to your setup.

He did ask if we are running a vnStat daemon (we're not) to see if there's something logged, and suggested strace, but since I have no way of reproducing the situation, it'd need to be done from your machine.

Out of curiosity, which version of vnStat are you running (vnstat --version) - I'm assuming it's 2.xx.

I guess there's a couple of options: 1) the aforementioned nuclear reset/reconfiguration or 2) creating a script that periodically runs the command /tmp/mnt/<<usb drive>>/entware/etc/init.d/S33vnstat stop && /tmp/mnt/<<usb drive>>/entware/etc/init.d/S33vnstat start to restart the underlying application. Not pretty but it might beat the reset.

 

[elorimer]

@elorimer - I did hear back from the vnStat application owner (Teemu) and got pretty much the same answer "saw it once on a Raspberry Pi, haven't been able to reproduce it" and "no other reports", so it's obviously something specific to your setup.

He did ask if we are running a vnStat daemon (we're not) to see if there's something logged, and suggested strace, but since I have no way of reproducing the situation, it'd need to be done from your machine.

Out of curiosity, which version of vnStat are you running (vnstat --version) - I'm assuming it's 2.xx.

I guess there's a couple of options: 1) the aforementioned nuclear reset/reconfiguration or 2) creating a script that periodically runs the command /tmp/mnt/<<usb drive>>/entware/etc/init.d/S33vnstat stop && /tmp/mnt/<<usb drive>>/entware/etc/init.d/S33vnstat start to restart the underlying application. Not pretty but it might beat the reset.

Thanks for the follow up. I've gone the reset route. I wanted to purge some things anyway.

EDIT: I've been slowly adding things back, one at a time. I added back vnstat2 on the 17th, and on the 19th it stopped again. Oh well.

 

[elorimer]

And now, again, on a completely different router, an AX88 with .6B1.

 

[dev_null]

And now, again, on a completely different router, an AX88 with .6B1.

I wish I had other ideas - but yours is the only report of this outside my initial testing (and if not for that, I wouldn't have even had any idea what was being described).

The maintainer of vnStat (the Linux app) reported an error with outdated snap on Debian, but that's obviously different. I'm happy to work with you by DM to see if i can re-reproduce it.

 

[elorimer]

Thanks; I'm just putting it out there in case it happens to someone else. But until I have something more to go on I think I'd just be wasting the time of both of us.

 

[bluzfanmr1]

When attempting to toggle and enable daily emails I am getting the following failure:

A choice of emails is available:
1.    HTML (includes images from WebUI + summary stats as attachment)
2.    Plain text (summary stats only)

e.    Exit to main menu

Choose an option:  1

Attempting to send summary statistic email

curl: (8) Weird server reply

Email failed to send

Press enter to continue...

I am currently not using Diversion but do have emails set up in amtm and it works just fine. Any thoughts on what might be happening?

 

[dev_null]

When attempting to toggle and enable daily emails I am getting the following failure:

A choice of emails is available:
1.    HTML (includes images from WebUI + summary stats as attachment)
2.    Plain text (summary stats only)

e.    Exit to main menu

Choose an option:  1

Attempting to send summary statistic email

curl: (8) Weird server reply

Email failed to send

Press enter to continue...

I am currently not using Diversion but do have emails set up in amtm and it works just fine. Any thoughts on what might be happening?

The email function of R2 is handled entirely by AMTM, I presume you don't see that message when you send a test message from AMTM?

What version of vnStat-on-Merlin are you running? What version of AMTM? Have you tried "plain text"?

Which provider are you using? Have you tried both the "secure" and "insecure" options? Does your provider require separate "app passwords" and do you have that configured in AMTM?

 

[bluzfanmr1]

The email function of R2 is handled entirely by AMTM, I presume you don't see that message when you send a test message from AMTM?

What version of vnStat-on-Merlin are you running? What version of AMTM? Have you tried "plain text"?

Which provider are you using? Have you tried both the "secure" and "insecure" options? Does your provider require separate "app passwords" and do you have that configured in AMTM?

Correct, I do not see that message when sending via amtm.

vnStat version 2.0.4. amtm version is 4.3. How do I try plain text?

I'm using iCloud, using the --insecure SSL flag, and a seperate app password that is configured in amtm. Like I said, it works just fine in amtm.

 

[dev_null]

Correct, I do not see that message when sending via amtm.

vnStat version 2.0.4. amtm version is 4.3. How do I try plain text?

I'm using iCloud, using the --insecure SSL flag, and a seperate app password that is configured in amtm. Like I said, it works just fine in amtm.

Mmm, I've never tested iCloud mail in anything non-iDevice.

I should have asked earlier, but I presume you set everything up via command line (and not the UI), in case there's some funky pasting thing going on?

Can you DM me the output of sh -x /jffs/scripts/dn-vnstat summary please. Don't post it here because it'll have your email addresses and stuff in it.

Also, testing plain text format is an option in the dn-vnstat email section (plain text vs HTML).

 

[bluzfanmr1]

Mmm, I've never tested iCloud mail in anything non-iDevice.

I should have asked earlier, but I presume you set everything up via command line (and not the UI), in case there's some funky pasting thing going on?

Can you DM me the output of sh -x /jffs/scripts/dn-vnstat summary please. Don't post it here because it'll have your email addresses and stuff in it.

Also, testing plain text format is an option in the dn-vnstat email section (plain text vs HTML).

I appreciate your help.

Everything was set up via command line.

I DM'd the output but had to split it up as it was more than 10,000 characters.

The plain text option slipped right past my aging eyes. I tried it and got the same result.

 

[dev_null]

I appreciate your help.

Everything was set up via command line.

I DM'd the output but had to split it up as it was more than 10,000 characters.

The plain text option slipped right past my aging eyes. I tried it and got the same result.

Got it and responded.

In case anyone is interested, it appears that in this instance at this time the email portion of the script is somehow being bypassed. Not sure if it's a script thing or an amtm email thing. Will post back when more information develops.

EDIT: or an iCloud thing.

 

[bluzfanmr1]

Got it and responded.

In case anyone is interested, it appears that in this instance at this time the email portion of the script is somehow being bypassed. Not sure if it's a script thing or an amtm email thing. Will post back when more information develops.

EDIT: or an iCloud thing.

A huge thanks to @dev_null for looking into this and finding the fix! All is well now.

 

[dev_null]

A huge thanks to @dev_null for looking into this and finding the fix! All is well now.

I'll be pushing a hotfix later today. Unless you're using an iCloud address there is no urgent need to update.

EDIT: for the curious, it was how dn-vnstat "curled" the email. Something about it that iCloud (specifically the me.com SMTP server) didn't like.