Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on July 06, 2013, 06:49:38 PM
-
Some new features and some tidying-up of details. I had intended to include usage monitoring in this version, but it's taking longer to sort out than I expected, so it should be in the next version.
(Note) The rewrite of the CRC and FEC code means that, if you have accumulated error data (in the file errors.dat) the averages will not be accurate until the next 24-hour period starts. You may like to reset the error data or delete errors.dat.
List of changes since v3.5:
- rewrite of code for CRC and FEC errors to try to deal with all possible deviations from the
normal continuous upward progression
- improved error trapping for situations in which contact with the internet is unavailable
- XML options are now saved in the .ini file
- router model is now saved in the .ini file
- fixed issue whereby the average error data was unnecessarily saved and reset
- added option to autodelete snapshots older than a specified number of days
- corrected small cosmetic error in Windows version (horizontal positioning of x axis
time values on graphs)
- corrected wrong CLI command prefix in router data for Billion 7700N and 7800N
- added feature to monitor the attenuation and report if it changes
- added option to auto-restart recording N minutes after a pause
http://dslstats.plainroad.me.uk (http://dslstats.plainroad.me.uk)
-
Thank you :flower:
-
I now run the Windows 32bit version on my W2K system and it is running fine. I will test the Linux 32bit as well but not as extensively.
Stuart
-
Thanks Stuart.
-
Been running fine overnight here.
I did have a 'play' with a couple of the features and all seems good. Thanks for adding the atten log, line seems to have been stable overnight and so no changes recorded.
-
Thanks. :)
-
[...] I had intended to include usage monitoring in this version [...]
From which source do you want to collect the traffic data? Do you plan to make a graph to visualize the traffic in real-time?
-
For routers with the normal Broadcom CLI there seem to be two sources for the data - cat /proc/net/dev and ifconfig
In either case I have to determine the correct interface out of several; it's called ppp256 on the routers I've looked at, and I'm hoping that it will always be called ppp<something>. For Thomson routers there's a simpler command ip iflist.
I'm not planning to plot real time traffic at present, just daily and monthly totals, but real time data is certainly a possibility.
-
In either case I have to determine the correct interface out of several; it's called ppp256 on the routers I've looked at, and I'm hoping that it will always be called ppp<something>.
I think it's not that easy because these are not default broadcom commands. Probably the interfaces are different on every device. Maybe it would be an option to generate a list to select the desired interfaces from.
On my device the ifconfig command is not available and this is the output of /proc/net/dev:
# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 45338 627 0 0 0 0 0 0 45338 627 0 0 0 0 0 0
sit0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
bcmsw:580706327 6193334 0 0 0 0 0 0 3944342981 13869651 0 0 0 0 0 0
eth0:558728680 5969188 0 0 0 0 0 0 3092001113 12236608 0 0 0 0 0 0
eth1:21977647 224146 0 0 0 0 0 0 852341868 1633043 0 0 0 0 0 0
dsl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
endpt0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ptm0:4294967295 7891953 0 0 0 0 0 51655 474995203 5895176 0 0 0 0 0 0
atm1: 0 0 0 0 0 0 0 0 0 0 0 71589 0 0 0 0
eth0.16:415466015 5969176 0 0 0 0 0 4356 426744435 1719989 0 0 0 0 0 0
eth1.16:16597375 224136 0 0 0 0 0 23 52284035 1108827 0 0 0 0 0 0
br1:407292247 6193324 0 0 0 0 0 8470 3698675989 12768343 0 0 0 0 0 0
br2:3214947406 11245717 0 0 0 0 0 51655 444432625 5895214 0 0 0 0 0 0
#
just daily and monthly totals
The counters are reset after 2³² bytes. It seems this is only possible if the program is running without interruption.
Things get more and more complicated, but I hope you don't give up... :)
-
Things get more and more complicated, but I hope you don't give up
You're right, and no, I won't be giving up.
I had expected that ifconfig would always be available because it's a standard Linux command. I'll have to try to cater for different commands on different router models.
-
On my device the ifconfig command is not available
Does /sbin/ifconfig work?
-
No, it seems this command was simply not compiled into this busybox version.
If I download a standard busybox binary to the device it is possible to execute ifconfig and all other commands, but this seems useless.
-
OK then, another little variation.
-
Got it working first time :)
On a WHS 2011
-
Thanks BB.
-
Hi Eric,
Still having the access violation here unforunately.
I've also noticed that when I get an access violation and close the program in the GUI, when I go into the CLI I can see the program is still running, and is using 100% CPU (I went to check as I noticed performance on the server has slowed)
I don't know if this is just a debian thing or what, but would appreciate any help :)
-
I really would like to get to the bottom of this, but I need a sequence of events leading up to the access violation so I can home in on the cause. I'm sure it's not related to Debian - I use Debian myself, and I've got both 32-bit and 64-bit machines which run DSLstats at various times.
The fact that the process is still running when it's closed after an access violation, and the 100% CPU, are possible clues. I'll have another look with those things in mind. The other thing I could do is build a debug version which you could try if you're familiar with using GDB.
-
Unfortunately not familiar with GDB, if it's not hard and I could find out what I'm looking for then I could help you out, but you might have to tell me :)
Thanks for your help :)
-
I'm afraid that GDB is a bit of a geek's tool, and I'm not competent to teach anyone else how to use it. I only use it within the confines of the development system, where it's integrated in a much more friendly fashion.
Looking back over the history of this issue, I'm tempted to conclude that there's something about the DGN2200 which DSLstats isn't handling correctly. Could you copy the contents of Telnet data --> Connection stats to me, and I'll check whether there's anything there which I'm missing.
By the way, I'm just about to release v3.7. It won't fix your problem, but I didn't want to hold it up. If I do locate the source of your problem I'll upload a fix immediately.
-
No problem, if you can't fix it you can't fix it! It appears no one else is having this problem so don't try and fix it especially for me :)
Thanks again.
-
It's certainly my intention to solve it, just proving a bit intractable at present.