What I'm doing right now is I set logging to max, and I'm watching the log to see if I can catch the moment things go awry. It's definitely not obvious because I can clearly see many, many times that this IP is being correctly extracted, then at some point it looks like the usageIn or dbUsageIn calculations are going awry.
I'm hoping I'll catch the problem at the moment it happens, so I can send that chunk of log to help narrow it down. Of course, after staring at it for two hours, it's not happening. <sigh>
The only thing that's "weird" about this particular IP is that it's on a VM that has automated programs running (ie. no user interaction), so has a near-constant trickle of data flow, but usually fairly small amounts.
With any luck I'll have something for you later today or by tomorrow morning.
Brad.
Brad - look in the log file for a message:
`*** Incorrect number of rules for <IP> in ACMON`
I'm guess that somehow your ACMON table is picking up a second entry for that IP address and then the weirdness gets started... the next question is why the second entry gets added and why doesn't the current flush call actually get rid of that entry???
You don't happen to have two instances of the script running do you? In theory, that should not be possible but I've managed to do that once or twice.
If there are two instances running, you'll see twice the expected number of updates in the log file (i.e., updates less than 10 seconds apart). To kill both instances, delete `/tmp/ac_mon.lock` and wait ~20 seconds... you'll see two shutting down messages in the log file. Once you see both of these, run the startup script again.
(I recently found a better way to prevent two instances of the script from running and will add that shortly)
Hmm, scratch that. I'd had the page up self-refreshing, but when I did an *actual* refresh, it all fell into line.
But I notice the "Monthly Totals" tab has what looks like a bit of a "legend" table or something peeking out from behind the chart on the right side. What's that?
I was using the old bandwidth monitor in this thread for years and I have to say this new version is awesome!
I might have missed any discussions previously on these but these are a few things I noticed while setting it up:
1. The config file points to data being in /YAMon/data but the zip file has the data folder in /YAMon/Setup/data, took me a while to figure out why my old data wasn't showing up and kept getting an error about the user file not being found from the web page.
2. Modifying the last line in the startup script to "/mnt/YAMon/Setup/yamon.sh /mnt/YAMon/Setup/config.file" applied the config file since it wasn't in the default directory, made sure to change _baseDir to /mnt/YAMon.
3. Since I set my USB key up with optware I renamed the startup script to S96yamon and the shutdown script to K04yamon and put them in the /opt/etc/init.d folder with a chmod +x, it starts the script on bootup and shuts it down when it reboots.
I just set it up today so I will see how it goes, hopefully this info helps someone.
I did notice since I have over a years worth of data from the last version when I try and "Add another Interval" past 2013-01-01 it just keeps adding 2013-00-01 and then I can't delete those. Also the pie chart to the right seems too big and it cuts off some of the txt from the table.
Really awesome work Al, I'm really happy you took the time to improve on this script
Thanks for the feedback.
With regards to #1 - I'll check/fix the zip file
With regards to #2 - You can pass the path for the config file as a parameter to the script
- e.g., sh yamon.sh <path2config>
If you do not include the parameter, the script assumes that the file is in the same directory as the script. I'll try to document this better (in the readme.txt)
As for your past data, I've found that I can reproduce the error here too so I'll be able to fix it shortly. Back to you ASAP.
Hmm, scratch that. I'd had the page up self-refreshing, but when I did an *actual* refresh, it all fell into line.
But I notice the "Monthly Totals" tab has what looks like a bit of a "legend" table or something peeking out from behind the chart on the right side. What's that?
Yeah... I added the legend but the google chart is obstructing it (and apparently does not obey the css z-index property). I'll move the legend somewhere else.
Joined: 27 Sep 2008 Posts: 446 Location: Port Of Spain
Posted: Mon Jul 22, 2013 15:24 Post subject:
Just a suggestion al, maybe you can put the legend somewhere to the top by summary,settings,changes, etc.
New version 1.05 working as expected no more negative values on my TPLINK WDR3600 _________________ Buffalo WZR-600DHP - 23838
TP Link WDR3600 - 21676
Linksys WRT54G-TM - 12548 (NEWD Eko Mega)
Well, now I have a new problem. The file "01-07-2013-mac_data.html" is not getting populated. It had up till the 17th but nothing after that. Hmmmm Can't figure out why not. It gets copied from the off line storage properly (I've got a 4Gb USB stick mounted to mnt).
Jeff
p.s. I just checked the date on the router and it thinks today is July 22nd (which it is) so it's getting the correct date and time from the NTP server.
Last edited by Canadian Geek on Mon Jul 22, 2013 18:12; edited 1 time in total
Joined: 27 Sep 2008 Posts: 446 Location: Port Of Spain
Posted: Mon Jul 22, 2013 18:47 Post subject:
follow the instructions in the readme file from version 1.03. I guess al forgot to add this file in new versions _________________ Buffalo WZR-600DHP - 23838
TP Link WDR3600 - 21676
Linksys WRT54G-TM - 12548 (NEWD Eko Mega)
bw_monitor.sh is the original script. It's a bit unclear from the forum thread, but this is an entirely new script, based on but separate from the old bw_monitor.
And the .sh file doesn't update, that's the actual script (program).
bw_monitor.sh is the original script. It's a bit unclear from the forum thread, but this is an entirely new script, based on but separate from the old bw_monitor.
And the .sh file doesn't update, that's the actual script (program).
I'm think that after 40 pages, we might start a new thread... relating just to the new script.