Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on February 17, 2015, 10:23:01 AM
-
This release consolidates various changes made in pre-release versions since v5.3, and adds some small additional improvements. In particular, it resolves an issue in the Linux/Raspberry Pi versions which caused MDWS uploads to fail if there is a $ in the user's validation key.
Changes since pre-release version 5.3.1/2:
- MDWS 'per-tone' values are now rounded to one decimal place
- DSL uptime is now shown correctly with Zyxel VMG1312-B30B
- DSL mode is now detected correctly with OvisLink OV303RG
- G.INP status is now reported in the Stats summary (no details, just 'Enabled' or 'Not enabled')
- fixed MDWS 'USER MISMATCH' error with validation key containing $ character
Changes since previous release v5.3:
- corrected small cosmetic error on Snapshots page in Windows version
- when the average error values are reset, the SES values are now included
- when the MDWS options "SNR per tone" and "Bitloading" are enabled, the corresponding
options in "Items to monitor" cannot now be disabled
- when the option "SNR per tone" is disabled in "Items to monitor", its sub-items "Show as
separate graph" and "Include with bitloading" are also disabled
- empty text files of error averages are no longer autosaved
- eliminated false positives in detecting resync events
- added option to select the font used in the graphs
- the configured modem/router model is noted in the event log on startup and after changing
- with modems which don't report FECs directly, DSLstats now falls back to RSCorr for FECs
- uploads to MDWS from locales which use a comma as the decimal divider are now converted
to the UK format before uploading
- modified the telnet login function slightly to accommodate modems which apply extra
formatting to the login prompt
- corrected errors in MDWS functions in Raspberry Pi version
- simplified the collection of MDWS data to reduce CPU load during sampling (for Raspberry Pi)
http://www.s446074245.websitehome.co.uk/downloads.html (http://www.s446074245.websitehome.co.uk/downloads.html)
(PS I can confirm that it works with the new Raspberry Pi 2 as well as the earlier versions.)
-
Thanks Eric, :) I will try it tonight as I'm just going to have lunch and have a short walk (just getting over a chest infection :( ) being it's a nice sunny day.
-
Downloaded to The Cattery and tested. Result was as we expected. I have saved a textual logfile of the output produced when the utility was executed under the control of strace.
-
Thanks Mr Cat. :)
-
Thanks for the update but I'm sorry to report I was unable to login to my HG635 with v5.3 and I'm still unable to login with V5.4 windows version.
It's using the same dslstats.ini file as v5.2, which works ok with the Huawei, so don't see what more I can do at this end.
Note the telnet login name for the HG635 is !!Huawei, could it be the exclamation marks causing the problem?
Unfortunately there's no know way to change the telnet login name with this router.
-
Thanks for the update, all seems to be working ok here. :)
One tiny thing that's not important. I usually update direct via the website and download files to my desktop. This time I clicked the 'update' button and then spent 10 mins trying to find where the updated version had been downloaded to. I know I was trigger happy, but it was only when I looked at dslstats event log file that I realised it had been put in C:\Users\kitz\AppData\Local\dslstats.
afaik I have everything set to C:\Users\kitz\Desktop\Connection\dslstats... and I dont use any local\AppData for anything if I can avoid it. Have I missed a setting somewhere?
-
@npr: Yes, sorry I haven't been able to sort this out yet. I'll give it some attention now.
-
Kitz when in the website use the save as option you won't need to go hunting for the DSLstats zipped file.
-
@kitz: Thanks for the confirmation.
The download directory is configurable on the page which is revealed when an update is available. By default in Windows it's the same as the directory advised by the OS for saving the config files. I believe that is the directory you mentioned.
If you want to avoid this happening in the future you could edit dslstats.ini to set it to your directory of choice. It's in the [misc] section and is called DownloadDir.
-
@NS - cheers, thats how I normally do it, this time I just clicked the button when dslstats advised me there was an update. I was rushing and thought it would save me some time.
@eric. Thank you - found it in the .ini file. Have changed it for future downloads. :)
Minimise on close=1
DownloadDir=C:\Users\kitz\Desktop\Connection\dslstats\
Diagnostics=1
-
Thanks for the update but I'm sorry to report I was unable to login to my HG635 with v5.3 and I'm still unable to login with V5.4 windows version.
It's using the same dslstats.ini file as v5.2, which works ok with the Huawei, so don't see what more I can do at this end.
Note the telnet login name for the HG635 is !!Huawei, could it be the exclamation marks causing the problem?
Unfortunately there's no know way to change the telnet login name with this router.
Looking back over the other comments on the HG635, it looks as though this model needs the option "Modem/router is HG622 type" to be set. v5.2 attempted to detect this requirement automatically, but got it wrong sometimes, so I dropped the autodetection in v5.3. If you haven't already, could you try setting this option please?
-
It seems ok but :-
See Tone bit loading graph, as it now goes off bottom of graph on RHS :'(
-
Looking back over the other comments on the HG635, it looks as though this model needs the option "Modem/router is HG622 type" to be set. v5.2 attempted to detect this requirement automatically, but got it wrong sometimes, so I dropped the autodetection in v5.3. If you haven't already, could you try setting this option please?
The first time HG622 is ticked I can login and start recording and stop and start recording with no problems. It's when the program has been stopped, when next started it will not login, I get the message at the top "Unable to login to modem/router".
If the HG622 tick is simply removed and replaced I can login again until the next time the program is restarted.
-
@ tickmike: I don't think I've ever seen SNR values below zero before. The graph assumes that zero is the lowest value, so if the modem reports lower values they get plotted like that. I'll make a note to convert any negative values to zero in the next release.
-
@npr: OK, thanks, I think I see where the problem lies now. I'll try to sort it out ASAP.
-
Glad you've got a idea where the problem lies.
No rush from this end, v5.2 is working fine, please let me know if you need any testing.
-
If it provides a fixup you might just try setting the modem type itself to HG622. Provided the IP and password/username are edited to be correct the rest of the settings should be correct. I believe that is what is I used to do but I am not sure of the version of dslstats in place at the time.
-
@ tickmike: I don't think I've ever seen SNR values below zero before. The graph assumes that zero is the lowest value, so if the modem reports lower values they get plotted like that. I'll make a note to convert any negative values to zero in the next release.
Note the difference on the two graphs.
I set my laptop to use the new DSlstats this morning but I have not rebooted Modem !.
-
I'm not sure about that. The two graphs were snapped at different times, so the modem may not have been reporting any negative values when the first snap was taken.
-
I'm not sure about that. The two graphs were snapped at different times, so the modem may not have been reporting any negative values when the first snap was taken.
Do you want me to send you the SNR per Tone text file via a PM ? or will it display on this forum ?.
-
I'm not sure what text file you mean, but you should be able to include it in a forum message by enclosing it in code tags.
-
Glad you've got a idea where the problem lies.
No rush from this end, v5.2 is working fine, please let me know if you need any testing.
I think I've fixed the problem. You can download the fixed Windows version v5.4.1 here: http://www.s446074245.websitehome.co.uk/files/dslstats32W-5.4.1.zip
This makes two changes:
1. When you select the Huawei HG635 from the Modem/router drop-down list, the "HG622 type" option is set automatically.
2. When you restart DSLstats after a shutdown the "HG622 type" option is properly restored (which it wasn't before).
-
Pleased to report v5.4.1 is working fine with the HG635 and windows. :thumbs:
That's using either the normal login or using the special login.
I've since tried v5.4 on a raspberry pi and that has the same login problem, but I expect you know that.
Thanks roseway, for all your work on this program it's much appreciated. :clap2:
Can anyone please point me to a tutorial about running dslstats on a RPi?
Mainly I need to know how to auto start it on boot ---- that and about a million other things.
-
I think I've fixed the problem. You can download the fixed Windows version v5.4.1 here:
Same as npr, can you please fix the pi version when you get a chance.
npr....I have been tring to sort out the pi version, the only advice I can give at the moment
1)Install Raspbian
2)open terminal and
sudo apt-get update
sudo apt-get install telnet
3)Download roseways's dslstats and extract into any directory.
4) Open the file explorer and browse to the extracted files...double click on dslstats....click excecute.
This is now where I am experiencing troubles
Sudo apt-get install xrdp
This installs a rdp server on the pi but......rather randomly..... your gui session is not always restored after a disconnect and reconnect....you may logon to a new blank session.
I have not yet investigated an auto run (mainly because of the hg622 and rdp problems).
This should get you started.
Ian
-
Thanks for confirming that v5.4.1 works properly. I'll try to build the Linux and Raspberry Pi versions tomorrow.
-
A trivial thing. I find the paw print icon missing in this version (run in XP). I just used the icon from a previous version to have tidy shortcut but you may want to fix this some time.
-
A trivial thing. I find the paw print icon missing in this version (run in XP). I just used the icon from a previous version to have tidy shortcut but you may want to fix this some time.
I can certainly include an icon in the archives in future. I don't recall ever including one before. Are you referring to "dslstats.ico"?
-
Good question - I may not be being clear!
Previously the exe file showed up in its folder with a paw print and creating a shortcut lead to a shortcut with the same paw print icon. I put the shortcut on my desktop. The notification paw print icon when the exe is actually run does work in all versions but I had to manually enable the icon for the shortcut with the latest versions.
-
Oh I see, yes. Various icons are stored within the executable, but I recently changed the way they're stored and used. I'm not sure at present why the application icon doesn't show, but I'll look into it.
-
I'm not sure what text file you mean, but you should be able to include it in a forum message by enclosing it in code tags.
Sorry, The 'SNR per Tone' text file (is that used to make the graphs ?).
All the 'SNR per Tone' text files have negative values each day, maybe it was DSLstats 5.3 was not showing them ! and 5.4 is correct ?.
This is a Netgear DG834GT modem/router.
-
I'm pleased to report the RPi version of v5.41 works fine with my HG635, both normal login and special login are good.
@kitzuser87430
I don't use xrdp, I use tightvncserver on the RPi and tightvnc viewer on the PC.
Instructions for installing tightvncserver and more importantly how to make it auto start can be found here.
http://www.penguintutor.com/linux/tightvnc
All up and running on the RPI, just need a way to auto start dslstats.
-
@nrp
http://www.raspberrypi.org/forums/viewtopic.php?f=26&t=18968 (http://www.raspberrypi.org/forums/viewtopic.php?f=26&t=18968)
How to autostart apps (and create desktop shortcuts)
Ian
-
Thanks guys.
By the way, I use tightvncserver on the RPi and tightvncviewer (on Linux) too. It works well with the RPi running headless. I used parts of this guide to enable SSH and tightvnc: http://otapi.com/2015/02/10/raspberry-pi-2-freepascal-lazarus-and-delphi/
-
I'm not sure what text file you mean, but you should be able to include it in a forum message by enclosing it in code tags.
Sorry, The 'SNR per Tone' text file (is that used to make the graphs ?).
All the 'SNR per Tone' text files have negative values each day, maybe it was DSLstats 5.3 was not showing them ! and 5.4 is correct ?.
This is a Netgear DG834GT modem/router.
It certainly looks as though the SNR values are being plotted correctly now. I don't want to rescale the SNR per tone included on the bitloading graph because that will mess up the visual relationship between the two parts of the graph. The negative values have no practical significance, so I propose to convert them to zeroes. I suspect that's what newer Broadcom firmwares do anyway.
-
I have attached an example from a G.DMT connection.
I'm not 100% sure, but I think the data came from a ZyXel or Billion modem.
-
Thanks for that Paul. I'd never seen it go below 0 dB before, but clearly it does happen. As my graphs are now plotting the negative values correctly (albeit off the scale on the combined bitloading/SNR graph) I'm going to stick with the plan to make the negative values zero on the combined graph and leave the SNR per tone graph to autoscale as it already does.
-
Just another datum point. When I was using a HG612 (on an ADSL2+ circuit) I occasionally saw negative SNR values. The HG612 would remain in synchronisation with the MSAN until the SNR reached -1.9 dB, at which point the connection was dropped.
Edited to strike out the nonsense.
-
Are you talking about the same thing? I remember you reporting occasions on which the SNRM fell below 0 dB without losing sync. But the issue here is SNR per tone. Sorry if I'm misunderstanding you.
-
Hmm . . . Ah, yes. You are right and I am wrong. :-[
Please ignore the irrelevant caterwauling. :paperbag:
-
It certainly looks as though the SNR values are being plotted correctly now. I don't want to rescale the SNR per tone included on the bitloading graph because that will mess up the visual relationship between the two parts of the graph. The negative values have no practical significance, so I propose to convert them to zeroes. I suspect that's what newer Broadcom firmwares do anyway.
With the HG612 on the 5.3 software it did not report any negative values for this. :hmm: I will note what happens when I next put the HG612 back with 5.4.
-
I got this at "20 Feb 2015 02:20:38 Bitswaps per min snapshot failed" (repeated in error log !) and I have No 'Bits swap per min' graph :o on the main display it's all grey page in area for graph , no grid lines or detail, top of page tabs ok, bottom of page graph detail tick box's etc. ok.
-
Do you have other graphs also set to autosave, and if so, which ones?
Did the autosaves work properly up to that point in time?
Did the program continue running properly apart from the Bitswaps per min graph?
Did autosaves continue to work after that point in time?
-
Do you have other graphs also set to autosave, and if so, which ones?
Yes, see PM I can not see a way to send screen shots in a pm :'(
Under 'Items to monitor' all tick box's ticked for ADSL connection.
Did the autosaves work properly up to that point in time?
Yes but graphs in auto save directory for 'SNRM per band Downstream and SNRM per band Upstream' are always blank and was with 5.3.
Did the program continue running properly apart from the Bitswaps per min graph?
Yes.
Did autosaves continue to work after that point in time?
Yes.
-
Thanks for that information.
Yes but graphs in auto save directory for 'SNRM per band Downstream and SNRM per band Upstream' are always blank and was with 5.3.
Those two graphs are only available on a VDSL2 connection, so it looks as though there's a bug which allows you to select them for autosnapshots. I'll make a note to correct that.
From your information it looks as though this was a one-off event which DSLstats should have trapped so it didn't cause any after effects. I'll see what I can do to stop it happening again, but if it does happen again please let me know.
-
Should I re-start DSLstats via re-booting laptop ?.
-
I have the RPi version up and running but just have the following couple of difficulties.
In the Configuration > Graphs tab, by default the sample time is set to every 30 seconds.
If I change this figure, after a program restart the sample time returns to every 30 seconds.
This is the same in the windows version and the RPi version.
Is there a known issue with the webserver feature in the RPi version? -- I haven't tried the windows version. html files are placed in the webserver folder but I can't access them from another PC on the LAN.
Does dslstats contain a server or do I need to install one?
-
Should I re-start DSLstats via re-booting laptop ?.
You don't need to reboot the laptop, just restart DSLstats.
-
@npr: For the webserver, have you followed the instructions here: http://www.s446074245.websitehome.co.uk/webserver.html (http://www.s446074245.websitehome.co.uk/webserver.html) ?
I'll check the other issue.
-
Yes I've followed those instruction, even disabled the PC's firewall.
I've now tried with the windows version with the same result.
-
Sorry to labour the point, but it does work on all four types of OS here. At present I have DSLstats running on this PC, which has a LAN IP address of 192.168.1.32. The webserver is running on port 55555. Several types of graph are enabled, including SNR Margin.
I go to another machine on the LAN, open a browser. and enter 192.168.1.32:55555/snrm.html, and the SNR margin graph is displayed in the browser.
-
Should I re-start DSLstats via re-booting laptop ?.
You don't need to reboot the laptop, just restart DSLstats.
I did not want to re-start DSLstats for now as my line has been better this week and I wanted the graphs up.
Just another few pennies worth about the graph that failed, I found out I can use the 'scroll' wheel on the mouse to go back though the last few days and Noticed that all other days the graphs are blank except they have red and green on the zero line, it's like the y-axis 'Bitswaps per min' is not being generated.
Hope it helps in your diagnosis.
-
Thanks for that extra information.
-
Yes I'm trying to access the web server correctly I also disabled windows firewall just to be sure that's not blocking these high port numbers.
Nmap shows a server is active on the RPi's port 55555, it's just not serving any web pages on my system.
I notice the path to the webserver folder follows that specified for "snapshots". I changed this from default before I tried the webserver, could it be the path I'm using is causing my problem.
I have now installed another webserver on the RPi and that's serving web pages as expected from the webserver folder. The only difference in the way they are both accessed is the port number. I would prefer not to have this second server running especially as the one in dslstats is proved to be working on your system. Any thought on what I can try will be very much appreciated.
-
I'll set up my RPi tomorrow and try to reproduce your experience. I guess the change of webserver folder might be the issue. What did you change it to? And are there any relevant entries in the event log?
-
I changed the snapshots directory to /home/pi/dslstats
Which makes the webserver folder /home/pi/dslstats/webserver
There's also a folder home/pi/.dslstats which holds:
dslstats.ini errors.dat es.data traffic.ini
Event log:
20 Feb 2015 22:33:15 Configuration file stored in /home/pi/.dslstats/
20 Feb 2015 22:33:15 The configured modem/router is Huawei HG635
20 Feb 2015 22:33:15 Error restoring login configuration
20 Feb 2015 22:33:15 Snapshot folder is /home/pi/dslstats/
20 Feb 2015 22:33:15 Webserver folder is now /home/pi/dslstats/websetver/
20 Feb 2015 22:33:15 Webserver started
20 Feb 2015 22:33:15 Recording started
-
Thanks for the information.
20 Feb 2015 22:33:15 Webserver folder is now /home/pi/dslstats/websetver/
websetver? Is that what it really said?
-
No, sorry that's a typo by me.
-
I'm afraid I haven't made any progress because I can't reproduce the problem. I've set up my RPi and started with a freshly downloaded copy of DSLstats. First I configured it to use the default snapshot folder and I enabled the webserver with the SNRM and bitloading graphs. It worked properly and I could access it from any other machine on the network.
While it was running I reconfigured the snapshot folder to /home/pi/dslstats/ and it transferred the webserver over to that folder and carried on working properly. I tried changing other things and adding more items to be monitored. I closed down and restarted DSLstats, and it carried on working.
This is grasping at straws, but I'm guessing that /home/pi/dslstats is the folder where you copied the main DSLstats files. I just wonder if there could be some conflict in also using this for the webserver files (although I can't see it). Could you try reverting to the default snapshot folder /home/pi/.dslstats (or create a new folder for the purpose) if you haven't already tried this?
-
No, sorry that's a typo by me.
Are you sure you have No typo's on the pi config :hmm:
-
Thanks roseway, but I've made no progress getting the webserver to work on my system.
Yes dslstats was installed to the /home/pi/dslstats folder, there is also a /home/pi/.dslstats folder containing dslstats.ini.
The GUI will not allow changing the snapshot folder to a hidden folder, the only way I see to do that is by editing the dslstats.ini file which I haven't as yet tried.
I have tried reinstalling dslstats afresh on the RPi, this time to the folder home/pi/dslstats.5.4.1 with the webserver folder at home/pi/webserver. ---- nothing I tried worked.
If you wish to investigate this further I'll be more than happy to test anything you can suggestion.
From my point of view though I've found the following solution which is working very well for uploading the stats to my web site.
http://forum.kitz.co.uk/index.php?topic=14844.msg277288#msg277288
-
Thanks for trying that. At the moment I'm out of ideas, but I'll do some more head scratching.
-
Thanks for trying that. At the moment I'm out of ideas, but I'll do some more head scratching.
What about folder directory permissions ?.
-
I've been wondering about that, although it's working up to the point where it's copying the html files to the webserver directory. The only part which isn't working is the webserver itself. That could be a permissions problem, I guess.
-
From post #52:
Nmap shows a server is active on the RPi's port 55555, it's just not serving any web pages on my system.
Also testing dslstats in windows 8.1 shows port 55555 tcp to be listening when the webserver is enabled and stop listening when it's no enabled.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi57.tinypic.com%2F2d170bt.jpg&hash=4c0df48673fe8e7a39a8c14dd95560bb53bb69a8)
There's little doubt the webserver is running and on the correct port.
Also I can see the html files being created in the webserver folder.
I have the same problem whether running dslstats on windows 8.1 or on the RPi
The webpage doesn't even display when I try: 127.0.0.1:55555/whatever.html
I've also tested using a different router to the Huawei ---- with no success.
-
This is perhaps a silly question, but you have enabled some items to include in the webserver setup, haven't you? My apologies if it's a daft question.
-
This is perhaps a silly question, but you have enabled some items to include in the webserver setup, haven't you? My apologies if it's a daft question.
I too have never been able to get the webserver to work. I remember Eric mentioning it seems some routers or network setups don't seem to work?
-
I think what I was probably referring to there was that some routers seem to have a problem with port forwarding, which is needed for external access to the webserver. But you don't need this for LAN access.
-
:) No questions are daft.
Yes, as proof the .html files are appearing in the webserver folder.
Just tried on my win8.1 machine running dslstats as "administrator"with firewall disabled.
Couldn't access any html page from a browser on the same machine (http://127.0.0.1:55555----etc)
or from the browser in my android phone or for completeness from the browser in the RPi.
Interestingly the error message in the Pi's browser was:
" oops! It was not possible the show this website
The website at http://192.168.1.2:55555/snrm.html seems to be unavailable. the precise error was:
Message Corrupt"
snip unimportant stuff.
Also if I double click the file snrm.html in the webserver folder it displays ok in my browser, so the html file is not corrupt.
@ jid,
Thanks for confirming it's not just me. :)
-
Hi
I hope you don't mind but I quickly tried dslstats and confirm same for me on win 7 64 bit
From a netstat -a, it appears only to be running on 0.0.0.0:55555, localhost and pc ip not showing any state for 55555, so could be a binding issue.
I hope it helps
Many thanks
John
-
The server is running, as the port is visible on the Pi, its just the server doesn't deliver the pages.
I use an FTP script on the Pi to upload the webserver folder to my own webspace, as never got the server working.
-
Hi jid
Yes, web server is running, but it's bound to all networks but not showing as bind to localhost or ip addresses, therefore cannot server content on your web browser.
I believe it should be bind to localhost and your pc IP address
I'm sorry if I'm wrong
Many thanks
John
-
The puzzling thing is that it works perfectly here on all operating systems, including two types of RPi - version 1 model B and version 2. You can see it working on my website: http://www.s446074245.websitehome.co.uk/livestats.html (you may need to flush your browser cache).
I'm going to have to put this aside for the time being, as there are other pressing matters to attend to. I'm sorry about that, but it looks as though jid's workaround will fill the gap for the moment.
-
No problem.
When you revisit these issues can I remind you about the graphs sampling time sticking at 30 seconds as per post #45.
Thanks roseway, your work on dslstats is much appreciated.
-
The puzzling thing is that it works perfectly here on all operating systems, including two types of RPi - version 1 model B and version 2. You can see it working on my website: http://www.s446074245.websitehome.co.uk/livestats.html (you may need to flush your browser cache).
I had to enable port 55555 on my hardware firewall (smoothwall )
Then I could see your stats. ;) (I wished mine were like that :( )
-
Hi
Sorry, after a good nights sleep I realise this morning my earlier posts are wrong over bindings, as it does bind to all networks.
Sorry for putting in a red heron
Many thanks
John
-
The puzzling thing is that it works perfectly here on all operating systems, including two types of RPi - version 1 model B and version 2. You can see it working on my website: http://www.s446074245.websitehome.co.uk/livestats.html (you may need to flush your browser cache).
I'm going to have to put this aside for the time being, as there are other pressing matters to attend to. I'm sorry about that, but it looks as though jid's workaround will fill the gap for the moment.
For reference, here's the workaround: http://forum.kitz.co.uk/index.php?topic=14844.0
:)
-
Sorry, after a good nights sleep I realise this morning my earlier posts are wrong over bindings, as it does bind to all networks.
Sorry for putting in a red heron
No problem, thanks for clarifying that.
-
Sorry for putting in a red heron
John
Um. Maybe Red Herons (if they exist) catch the Red Herrings you meant to refer to :lol:
-
Just installed this program.. thought I'd just say how good it is, and how its running perfectly on my setup so far.
-
Thank you. :)
-
I seem to be getting frequent Floating point errors when running the 5.4 version of DSLstats.
Previous versions ran perfectly with no errors or hangs.
See attached Screen caps for Error message & Checksum of DSLstats.exe
The popup window is often hidden behind other windows, meaning the stats are not being collected while waiting for user input.
Any ideas what I can do ?
More than happy to run a debug version if that helps. (Assuming that it is possible and it would be helpful to resolve error.)
-
Can you tell me what was the last version which you used which performed properly, please?
(By the way, the checksums are fine).
-
The last version that work properly was DSLstats 5.2.
I noticed the new 5.4 version announcement and upgraded.
I missed 5.3 and did not update DSLstats.
-
Thanks for that, it will help me try to identify what changes might have led to your problem.
-
To AArdvark: it's just possible that this applies: http://forum.kitz.co.uk/index.php?topic=15149.0
-
Just a comment, in passing, but I note that DSLstats v5.2 (64-bit, Linux flavoured) was the last version that operated correctly for me. :-\
-
Yes, I haven't forgotten that :)
I'm still unable to put my finger on the difference.
-
To AArdvark: it's just possible that this applies: http://forum.kitz.co.uk/index.php?topic=15149.0
Thanks I checked this just in case.
I run in a directory with full permissions and even if I run as Administrator the same thing happens eventually.
I have switched back to version 5.2
Not a major problem.
-
Thanks for confirming that anyway.
I'll come back to you as soon as I can.
-
Is there a special trick to get the webserver pages working? I seem to be able to connect but I just get a completely blank pages? The files are being generated in the webserver directory.
Using RPi2.
Thanks
-
I suspect that this is something to do with file/directory permissions, because the webserver works fine for me on both the RPi model B and the RPi2. I haven't been able to get to the bottom of it yet, and I've had to set it aside while I attend to other issues. In the meantime, jid has posted a workaround here: http://forum.kitz.co.uk/index.php/topic,14844.0.html
-
I suspect that this is something to do with file/directory permissions, because the webserver works fine for me on both the RPi model B and the RPi2. I haven't been able to get to the bottom of it yet, and I've had to set it aside while I attend to other issues. In the meantime, jid has posted a workaround here: http://forum.kitz.co.uk/index.php/topic,14844.0.html
Do any other RPi2 users have any tips what could be causing this.
It appears dslstats does not work with the webserver and it does not allow connection to MyDSLWebStats also (at least on my RPi2). I click the Check Now button and it says Unable to check at present regardless of what is in the username and key fields. The path to curl is also correct. Could it be specific to a Curl version? What port does MyDSLWebStats use to upload the data? Thanks.
-
I click the Check Now button and it says Unable to check at present regardless of what is in the username and key fields. The path to curl is also correct. Could it be specific to a Curl version? What port does MyDSLWebStats use to upload the data? Thanks.
I had that and it turned out to be something silly but I dont quite remember what. It may have been related to needing to start/stop recording.
-
The reason I suspect that it's a permissions problem is that both the webserver and MDWS do work, on both the original RPi model B and the RPi2. In the latter case, this is with a vanilla Raspbian installation, so I know that the version of curl is OK.
If you extracted the files from the downloaded zip file using Windows, there may be an issue with permissions. To avoid this I suggest that you copy the downloaded zip file to the Pi user's home directory (/home/pi) and extract the files using the command line utility unzip. Run the program from there as an ordinary user.
-
Thanks I will do some more testing. I wget and unzipped on the pi itself so it should have kept permissions correct. Using the standard raspbian image feb 2015 and dslstats 5.4. Very strange.
-
Is it possible to disable all local graph/text file creations and just use MDWS? Or does dslstats do calculations on the data it uploads to MDWS? Thanks
-
No, it's not possible. I could probably make it an option, but it would involve quite a lot of work, and it would be on the end of rather a long todo list.
Most of the data uploaded to MDWS is 'delta' data, i.e. it's the difference between successive samples.
-
I have noticed since the 5.4.3 release the MAX/Attainable down stream rate in the telnet data connection stats becomes stuck this is happening daily only on the PC version the RPi is fine.
The only way to get the correct attainable is to turn off DSLstats and restart DSLstats on the PC.
-
I've responded to your other report in the v5.4.3 thread.
-
Howdy!
Hopefully you've recovered from your birthday? :D
1. Dunno if it's been mentioned but DSLstats appears to be sending all power values as positive to MDWS. My aggregate upstream is -13 odd I think.
2. Some time ago HLOG changed slightly. I think you mentioned elsewhere you only plot the tones in use as opposed to the full HLOG values. Might it be possible to have the option for both or just revert to full?
I may have misunderstood tbh but the graphs definitely changed to gaps instead of dips. Dips are much more useful for noobs like me :)
Keep up the excellent work. Please.
:D
-
Thank you, I have recovered :)
1. This was raised elsewhere recently. I'd never seen negative aggregate values personally, so I was wrongly assuming that these values would always be positive. It's now corrected for the next release.
2. The gaps in HLog (and also in QLN) are not directly to do with unused tones, but are sections of the graph where the reported values are not true. These values are -160 dBm/Hz for QLN and -96 dB for HLog. Somewhere in a specification it says that these values are, in effect, dummy values which the modem uses when it doesn't have a proper value to report. Plotting these values wouldn't add any more useful information, but perhaps I could plot them in dotted lines. I'll have a look at this.
-
Gotcha, thanks!
The JDSU docs suggest any irregularities in the HLOG are copper faults. 'Fault' is relative I guess so whether that's worth highlighting or not I dunno :)
-
The sections we're talking about are not irregularities in that sense.
-
Are you 100% sure?
-
Yes. Although the judgement DSLstats makes is based on the baseline values I mentioned, the tones in question are also the tones which are not included in the band plan. Although I don't know the details of how these figures are determined by the modem, I've no doubt that it's quite normal for these tones to show baseline values in the QLN and HLog graphs.
-
My line uses all tones available to it; it is only 100m long, so doesn't lose out on anything.
However, the QLN values don't always come out.
Attached are 3 graphs as an example (from the other program ;) ); these are consecutive resyncs - and the associated HLog, SNR and Bit graphs don't show any differences.
I'd say it was an anomoly in the modem.
-
I agree that it's extremely unlikely that the HLog, QLN and SNR details wouldn't change at all between resyncs. I suppose you didn't retain similar data from DSLstats, did you?
-
I'd say it was an anomoly in the modem.
Do the Plink logs for those resyncs also show similar raw data (i.e. as obtained directly from the modem)?
If so, I would agree that it probably is due to a modem anomaly as the connection will have been fully synced by the time the stats were obtained.
-
I would like to report what I think is a bug in the average error rate report, the SES Down is reporting very high errors while my actual stats show no down SES errors.
This is with the RPI version 5.4.5 but I believe previous versions also showed this problem.
I get the same result whether monitoring a Huawei HG635 or ZyXEL VMG8924B10A.
Average error rates over a 24 hour period
24 hours starting 10 Apr 2015 17:07:04
Per second Per minute Per hour Per day
CRC Up 0 0 0 0
Down 0 0.01 0.59 14.3
FEC Up 0 0.22 13.1 314
Down 2.57 154 9246 221908
HEC Up 0 0 0 0
Down 0 0.01 0.59 14.3
ES Up 0 0 0 0
Down 0 0.01 0.59 14.3
SES Up 0 0 0 0
Down 4.23 254 15227 365437
Total time = 5 days 2 hours 49 min 37 sec
FEC: 1893569 2619
CRC: 181 0
ES: 35 0
SES: 0 0
UAS: 522 522
@rosway, if it helps, I can PM you the URL for my online stats.
-
@npr: I think that, if you press the "Reset values" button so that the averages start again from scratch, the averages after that will be accurate. There is a bug there somewhere, but I haven't traced it.
-
Thanks, that works.
-
I'd say it was an anomoly in the modem.
Do the Plink logs for those resyncs also show similar raw data (i.e. as obtained directly from the modem)?
Yes, Plink shows the same raw data - the graphs reproduce it properly.
-
Can anyone confirmed if this will work with Netgear DGND3700v1 please under Linux 64 bit?
-
If it works with DSLstats then it should work with MDWS.
-
Sorry Kitz but what is MDWS?
-
MDWS = http://mydslwebstats.co.uk/
-
oops my bad. For some reason I thought I was replying in the MDWS thread :D
-
Can anyone confirmed if this will work with Netgear DGND3700v1 please under Linux 64 bit?
I did have it working myself at one time, but you have to put it in debug mode to get telnet access, and it seems to lose this after a period.
-
Hi
Does anyone know if Email alerts should work ok for version DSLStats on the raspberry pi (using 5.4.5).
It works fine on the windows version but I keep getting the message:
“17 Apr 2015 18:18:10 Failed to sent email alert - SSL error: TSendMail
17 Apr 2015 18:18:10 Alert: Test alert”
in the event log.
I am using the same settings as used on the windows version.
Thanks
-
It should work, but I haven't tested it recently. Is LibSSL installed on the RPi?
-
Is LibSSL installed on the RPi?
I thought it was but just reinstalled LibSSL and all working now.
Thanks
-
Excellent. Thanks for confirming it.
-
Is anyone else getting duplicate upload errors associated with the MDWS service? I only have one instance of this program running naturally, yet since 19.04 I've received 32 'Duplicate Upload File Error' emails.
-
I'll try to work out how this can happen.
-
Hi
Does anyone know if Email alerts should work ok for version DSLStats on the raspberry pi (using 5.4.5).
It works fine on the windows version but I keep getting the message:
“17 Apr 2015 18:18:10 Failed to sent email alert - SSL error: TSendMail
17 Apr 2015 18:18:10 Alert: Test alert”
in the event log.
I'm also having this problem, having recently installed DSL Stats v5.4 on a Raspberry Pi.
SMTP server smtp.gmail.com
Use TLS/SSL [YES] (also tried NO)
Port : 587 (also tried 465)
Any combination of the above settings will fail with the same error "SSL error: TSendMail" when I click "Test"
Raspberry Pi Raspbian is up to date as of several hours ago. How would I check if I have LibSSL?
Thanks
Ian
-
It appears that it isn't installed by default, so you need to install it yourself. The package is actually called libssl1.0.0, so open a terminal and type
sudo apt-get install libssl1.0.0
-
It appears that it isn't installed by default, so you need to install it yourself. The package is actually called libssl1.0.0, so open a terminal and type
sudo apt-get install libssl1.0.0
Thanks for the help, I tried looking for libssl but didn't get anywhere!
Unfortunately it seems I already have libssl1.0.0, as when I try to install using apt-get as you suggest, it tells me this :
"libssl1.0.0 is already the newest version
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded."
:(
Ian
-
I'll fire up my RPi tomorrow and check it out.
-
Thanks :thumbs:
Ian
-
I used
sudo apt-get install libssl-dev
on mine.
-
I used
sudo apt-get install libssl-dev
on mine.
Yep, that works for me too! Installing libssl-dev allows DSLstats 4.5 to send email alerts on a Raspberry Pi without any SSL errors :)
Thanks
Ian
-
That's a bit strange, but I'm delighted that it works. :)
-
To follow up the original report, the last duplicate upload file error happened 7:08PM 29.04, so hasn't happened for a bit.
-
Thanks for that.
-
I'm using DSLstats (the current release)on a RPi monitoring a Billion 8800NL serving Plusnet fibre.
I've just noticed that CRC error graph doesn't appear to match the telnet data - it seems to give a graph showing higher values......I wonder if there's some scaling issue?
eg Last resync was 3h 59miins ago and telnet data shows 27 errors, but the per-minute CRC graph for the same period showed 5 individual plotted values of 4, 56, 12, 4 and 12 spread over that 3h 59m ie a total of 88
I've now switched back to per sample and restarted so as to see how that goes.
Any thoughts on that?
15min later: restarted DSLstats on per-sample CRC, and the graph now accurately reflects the data so far.
-
I've just noticed that CRC error graph doesn't appear to match the telnet data - it seems to give a graph showing higher values......I wonder if there's some scaling issue?
Are you talking downstream only here? I'll try to check this out as soon as I can.
-
Yes Eric......just talking about Downstream on per-minute - the per-sample seems OK so far.
-
I think this is normal if the sampling period is smaller then one minute. I guess yours is around 20 seconds. DSLstats seems to extrapolate the received values to one minute if the per minute option is selected.
-
Sampling interval was/is 15 secs, so your estimate wasn't far out!
Sounds a plausible explanation; if that's so, then I can stick with the per-sample display.
DSLstats is a lovely tool though, and it has allowed me to ditch the sole, old Windows machine that I used purely to run Routerstats 24*7.....the Pi is much handier!
-
I think this is normal if the sampling period is smaller then one minute. I guess yours is around 20 seconds. DSLstats seems to extrapolate the received values to one minute if the per minute option is selected.
Yes, you're right. The CRC and FEC graphs calculate a per-minute rate based on the change in the totals between successive samples, and the time between samples.
-
For the last 10 days, I've had adhoc 'duplicate upload file error's again, 24 of them.
-
For the last 10 days, I've had adhoc 'duplicate upload file error's again, 24 of them.
They only occur after three consecutive attempts at inserting a duplicate record into the database, that is one where the time in the modem file you upload, which is always a whole date/time minute with no seconds, already exists in the database. This can be caused by all sorts of things, usually running two instances of an upload program at once or having a clock that's suddenly lost or gained time. There is no easy way round this but 99.9% of the time there is no problem.
In your case, it's a bug because you are uploading almost exactly on the minute but varying by a few secs due to the time you take to process the data and rounding to the nearest sec at the server is causing the duplicates. If you stop DSLstats for 10 secs and restart it should stop this.
In theory you can have 1440 a day. I banned someone 4 months ago who had managed 5000 bum uploads consecutively - and they were still sending them but e-mail is invalid. Still have to be processed though, so blocked the IP.
-
I have quit and started dslstats up again - for reference I have uptimes of 0.5-1 month, incase something is getting out of sync.
Time keeping has been accurate on this Debian Testing machine for about a month now (prior to that, it was using a NIST server that never bothered to return the time...).
I can increase the sample period if needed (atm on the Configuration -> Graphs tab its set to 60 seconds).
-
I should probably refine the DSLstats timing arrangement. It's designed to avoid uploading to MDWS during the critical period of the last few seconds of the minute (offhand I don't recall how many seconds that is), but I think I should give the timing a bit more safety margin to allow for differing times taken for sampling. I'll do this in the next release or pre-release.
In the meantime, if you avoid pressing the green button during the last 15 seconds of the minute you should be safe. So long as your PC clock is accurate, the long term stability of DSLstats' timing is very accurate.
-
Sorry, where is the green button for reference? The program is normally left alone to run.
-
Sorry, where is the green button for reference? The program is normally left alone to run.
I was referring to the "Start recording" button at the top left. If you have DSLstats configured to start recording automatically when it starts up, perhaps for the moment it would be better to disable this.
-
OK, I have disabled that option and stopped the current instance recording for now.