Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on May 16, 2017, 11:43:33 AM
-
Some small fixes and requested features:
- fixed non-working email alerts
- fixed lack of feedback when MDWS uploads time out
- added event log entry to record SNRM values after a resync
- increased telnet timeouts to reduce incidence of timeout errors
There are both archive and self-extracting installer versions (except for the Raspberry Pi- sorry). In view of recent events I've submitted the installers and the Windows executable to VirusTotal (https://www.virustotal.com/) and they're all assessed as clean.
This will be the basis for the next full release v6.0, and when I release that I will close down the old website permanently.
http://dslstats.me.uk/downloads.html
-
The standard Linux 64-bit (not the self-extracting installer) version was downloaded, installed and is currently executing. At a quick glance, everything appears to be correct. :)
-
Likewise with Rpi
-
Thank you both :)
-
hmmm
Tried the RPI version on my hg635 (using hg622 workaround) and received errors
"Error running hg622 workaround"
and in event log
"Unknown Event"
Unchecked hg622 workaround box.
and received
"Unable to login to modem/router"
Clicked "Reset Login Configuration" and re-entered my modems correct login details and still got the same errors.
I have rolled back to 5.9.3; if you require any more info just ask.
Ian
-
Windows version running fine here. Installed as I always do from zip file.
Stuart
-
Thank you.
@kitzuser87430: this must relate to the changes I made to increase the timeout time. I think that the error is limited to modems which require the HG622 workaround. I'll check it out tomorrow.
-
Linux 64Bit
Graphs look ok but in logs .
16 May 2017 22:03:13 Auto snapshots taken
16 May 2017 22:14:49 No response to login user name.
16 May 2017 22:14:49 Unable to login to modem/router
16 May 2017 22:15:06 Incorrect login name or password
16 May 2017 22:15:49 No response to login user name.
16 May 2017 22:15:49 Unable to login to modem/router
16 May 2017 22:18:36 Timeout while retrieving stats
16 May 2017 22:18:36 No stats received
-
pi3 updated and running fine with my 8800nl in bridge mode. Alerts tested and now working too - thanks very much for sorting
-
Thank you.
@tickmike: I guess that this is another consequence of the timeout changes. It doesn't do it on my Linux 64 bit system, so I'm not sure at present. I'll check it out tomorrow.
-
Hmm. Alerts seemed to work but now not getting the snr alert again. Anyone else? - rpi3
Thanks
-
When it sends an alert for SNRM dropping below the trigger threshold, the value which it fell to becomes the new trigger threshold. So you don't get another alert unless it falls to an even lower value. If you want to get an alert every time it falls below the original threshold, tick the box labelled "Keep trigger levels at the values set here".
-
Eric
Re earlier PM, using the Windows Installer for 5.9.4 this is now running fine on the MDWS server with no errors at all :drink:
I've always installed it in c:\DSLstats before now with no problems but the latest Win 10 updates have caused some problems as you observed.....
-
Thanks Tony, it does seem that recent changes in Win10 have caused this change of behaviour.
-
Thank you.
@tickmike: I guess that this is another consequence of the timeout changes. It doesn't do it on my Linux 64 bit system, so I'm not sure at present. I'll check it out tomorrow.
Just had a look at the log..
17 May 2017 18:06:27 Auto snapshots taken
17 May 2017 18:49:33 Timeout while collecting signal attn data
17 May 2017 18:49:33 Telnet timeout
17 May 2017 18:49:50 Timeout while collecting bitloading data
17 May 2017 18:49:50 Telnet timeout
17 May 2017 18:50:23 Timeout while collecting system uptime
17 May 2017 18:50:23 Telnet timeout
17 May 2017 18:50:47 *** Second stage login failure. Did you enable the option "Requires command to enter shell" by mistake?
17 May 2017 18:50:47 Second stage login failed
17 May 2017 18:51:16 Timeout while collecting firmware version
17 May 2017 18:51:16 Telnet timeout
17 May 2017 18:51:26 No response to login user name.
17 May 2017 18:51:26 Unable to collect stats 3 or more times in succession
17 May 2017 18:51:26 Unable to login to modem/router
17 May 2017 18:51:36 Unable to login to modem/router
17 May 2017 18:51:59 Timeout while retrieving stats
17 May 2017 18:51:59 No stats received
17 May 2017 18:52:09 Unable to login to modem/router
17 May 2017 18:52:20 Unable to login to modem/router
17 May 2017 18:52:34 Unable to login to modem/router
17 May 2017 18:52:49 No response to login user name.
17 May 2017 18:52:49 Unable to login to modem/router
17 May 2017 19:06:27 Auto snapshots taken
17 May 2017 20:06:27 Auto snapshots taken
17 May 2017 21:06:42 Auto snapshots taken
17 May 2017 22:06:42 Auto snapshots taken
-
@tickmike: Can you remind me what modem you're using?
-
@tickmike: Can you remind me what modem you're using?
I see that his signature block states an HG612.
-
Ah, thanks, I hadn't thought to look there. In that case I'm quite puzzled, because the HG612 isn't one of the 'difficult' modems which sometimes respond slowly. I think I'm going to have to revert to the previous telnet timeout procedure and think again.
-
Hi roseway and tickmike
I could be wrong but I think from memory I used to see similar to tickmike log, and unchecking second stage login, I think stopped these errors
As I say, I could be wrong, and went to look at previous logs, but I cannot seem to find them sorry, just empty folders with date names
I'll check though, early evening and let you know if there any similar errors shown in log
Many thanks
John
-
@tickmike: Can you remind me what modem you're using?
I see that his signature block states an HG612.
Correct .
16 May 2017 21:03:06 The configured modem/router is Huawei HG612
-
@d2d4j: Thanks, but the HG612 definitely does need the second stage option to be enabled. After logging in by telnet with name and password, you have to enter a further command ('sh') to get to the Busybox shell.
-
Hi roseway
Many thanks
Guess my stats are blank on mydsl and I'll have to turn it back on
We are hg612, and looking at the program, all stats look to be there though or is there an area which would show blank if you don't mind me asking
Many thanks
John
-
Hi roseway
I am sorry, but please could you check my stats on mydslwebstats (d2d4j) as all look to be there
I will recheck secondary login though if you say it does need it
I hope that's alright
Many thanks
John
-
Hi roseway
Apologies I must be having a seriously bad day sorry
Just looking at my login details, it shows requires command to enter shell ticked and disable special login ticked
So I guess the secondary login is working, but I did untick it a while ago I'm sure, so please ignore my posts sorry
Many thanks
John
-
Everyone's allowed to have a bad day, John. :)
-
When it sends an alert for SNRM dropping below the trigger threshold, the value which it fell to becomes the new trigger threshold. So you don't get another alert unless it falls to an even lower value. If you want to get an alert every time it falls below the original threshold, tick the box labelled "Keep trigger levels at the values set here".
Hi Roseway.
Not sure if this is pi specific but neither of the 2 units I use are sending resync alerts. Both provided a snr alert once but nothing since. My skyeci line resynced this morning but no alert. Test alerts work just fine. I have moved both to the 5.9.5 version.
Any thoughts appreciated.
Thanks
-
As far as I know, if DSLstats detects a resync then the alert system will respond. What's probably happening is that DSLstats didn't detect the resync, and one possible reason is that the connection dropped and reconnected within the minute between two samples. The way a resync is detected is that one sample notes that the connection has dropped, then a later sample detects that the connection is active again. If it all happens inside the time between two samples, then the resync won't be detected.
Concerning the SNRM alert, did you enable the option "Keep trigger levels at the values set here"?
-
Just now I recorded
22 May 2017 16:15:43 DSL connection restored. SNRMup = dB, SNRMdown = dB
22 May 2017 16:17:13 DSL connection restored. SNRMup = dB, SNRMdown = dB
22 May 2017 16:21:43 DSL connection restored. SNRMup = dB, SNRMdown = dB Can you tell me why they are there with no actual data? Please.
-
I don't know. It's obviously a bug. I'll look into it.
-
I noticed a discrepancy this morning.
Billion
Line Rate - Upstream (Kbps) 1016
Line Rate - Downstream (Kbps) 6651
DSLStata
Bearer: 0, Upstream rate = 952 Kbps, Downstream rate = 6649 Kbps
The down stream one is minimal, the upstream more obvious, though probably not particularly significant. , Nevertheless I'm curious why I am seeing this.
-
The line starting "Bearer: 0" is part of the main stats reported by the modem via its telnet interface. Those were the correct figures at the time. Presumably the other figures were those shown in the GUI? They were either out of date (hadn't caught up with the latest changes) or plain wrong.
-
Thanks! I had never seen that happen before! Perhaps I wouldn't have but for the dropped connections I've been suffering with reduced SNRm targets, that used to hold, but no longer it seems.
-
System crashed yesterday and in Windows Event Log is
Faulting application name: dslstats.exe, version: 5.9.4.0, time stamp: 0x00000000
Faulting module name: dslstats.exe, version: 5.9.4.0, time stamp: 0x00000000
Exception code: 0xc0000409
Fault offset: 0x000642ce
Faulting process id: 0x1cf8
Faulting application start time: 0x01d2d9daaa78bf6c
Faulting application path: C:\Users\Go****\dslstats-5.9.4\dslstats.exe
Faulting module path: C:\Users\Go****\dslstats-5.9.4\dslstats.exe
Report Id: 5a2da633-d53c-4d5c-93c8-30f89711faa2
Faulting package full name:
Faulting package-relative application ID:
In case it may be of use and for info, I post it here. Comments?
-
I'm sorry to hear that, but unfortunately Windows crash reports don't have any meaning to me. All I can suggest is that you clean out all remnants of DSLstats again and then configure it in a much lighter fashion. You're accumulating a vast amount of data which is way beyond what is likely to be useful in any future diagnosis. It may be that you're exposing bugs in the program which only appear when it's pushed hard. To be practical about it, I don't have the energy to investigate possible bugs which I can't reproduce and which are quite obscure.
Sorry to be rather blunt about it.
-
Quite understood! :)
If any Windows users have any comment, they have a chance to do that; don;t they?
Eric, what would you and others suggest I oust?
-
@renluop I use DSLStats on a small W7 machine and have never had a crash. I do monitor quite a large amount of stuff so probably push it quite hard. Crashses can be external to the program such as perhaps memory issues (possibly a failing memory stick) or even a dodgy HDD (less likely as once loaded the program is in memory). I guess it could be a memory leak but I'd expect others to see that unless your setup is very unique. Without knowing more about your setup is is difficult to comment.
Stuart
-
Stuart, I doubt that, as my brain is too small! ;) had you any particular peculiarity in mind? Machine is a Dell refurb.
Speccy file is attached just for info.
-
Nothing special in mind. Have you had any other crashes in any other applications? Usually memory problems show up on different applications depending on the order they are started as they may get different memory locations. If I get unexplained crashes I run Memcheck86 which is a stand-alone memory test program bootable from a CD/DVD or memory stick. You dont need to understand anything about any errors if you get them, it should run error free and if not you have a problem in one of the memory cards (if you have more than one, looks like you may only have one). Then it needs replacing, if it runs error free then obviously its not that.
Might be better to take this discussion to a separate thread if it continues....
Stuart
-
I wouldn't think it related, but sometimes getting a wireless connection is a !!!!!!!
As you say we'll leave it there on this thread.
-
Hi renluop
Your wireless connection is pertinent to this issue and a few others
Using wireless, if there is a break in wifi, it can cause floating point issues etc in dslstats.
I use wifi, and have seen a floating point issue after wifi had an issue
I have never reported this though, as the only advise I have seen for dslstats, is to use hardwire connection only, no wifi (guess that means wifi not supported due to issues wifi could give, which are not a result of dslstats)
I hope that helps a little
Many thanks
John
-
and thereby hangs another problem!
Some say that Billion 8800NL can play up, if there are both an Ethernet cable between router and computer active and also wireless. Wireless connects printer, wife's IPad and bedside radio. I use HomePlugs between router and digbox.
Since getting rid of cable from router tocomputer things seem much better connection wise.