Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on December 10, 2014, 07:12:07 PM
-
Changes since v5.2:-
- the "Reset values" button on the average errors page now resets the start time as well as the values
- when unreal high values of SNRM are reported by the modem, these values are changed to zero in the DSLstats
graphs and the uploaded MyDSLWebStats data
- added option in MyDSLWebstats configuration to select which data to upload
- changed the way CRCs and FECs are collected (using "Total time = ..." section instead of SFErr and RSCorr)
- completely removed the autodetection of HG622 to avoid false event log entries
- corrected wrong upstream SNRM per band values sent to MyDSLWebStats
- the system tray icon is now pulsed red/green after three successive samples failed to retrieve any stats
- added a graph of SES values, and added SES to the average errors table
- improved the detection of resync events
- added option to send an alert if MyDSLWebStats uploading fails (or will fail)
- if MyDSLWebStats uploading fails for a transient reason, the MDWS option is not disabled
- improved the MDWS validation key checking function to avoid multiple failed uploads
- fixed a rare error with MDWS uploads (some integers were wrongly assigned two decimal places)
http://www.s446074245.websitehome.co.uk/downloads.html (http://www.s446074245.websitehome.co.uk/downloads.html)
-
The 64-bit Linux version has been downloaded and is being given a "test-run". :)
-
I have to report a peculiarity. ???
The tarball was downloaded and its contents were extracted into the desired location. From a graphical interface, the dslstats icon was double left-clicked. Nothing appeared to happen. Checking the system processes, it showed that the utility was currently executing. The only option available to me was to send the process a SIGTERM signal. :(
-
That's odd. I just tried downloading the same version and duplicating what you did, and it worked normally.
Could you try launching it from a terminal to see if there are any error messages which could explain what happens?
-
The 32-bit Linux version starts without any problems.
- changed the way CRCs and FECs are collected (using "Total time = ..." section instead of SFErr and RSCorr)
Thanks for this change. What happens if some devices don't have the "Total time" section? Are the ES and SES values collected from the data above?
Do you know what happened with MDWS?
-
Result of testing from the command line --
[Duo2 dslstats64L-5.3]$ ls
bitloading.html combined.template crc.html fec.html LICENCE routers.dat ses.html snrmpbdown.html specialrouters.dat upload.l64
CHANGELOG connspeed.html dslstats fullstatstemplate.html README routertraffic.csv snrm.html snrmpbup.html statstemplate.html
[Duo2 dslstats64L-5.3]$ dslstats
TLResourceList.Sort 57 DUPLICATE RESOURCE FOUND: TBitchart:PNG
TLResourceList.Sort 58 DUPLICATE RESOURCE FOUND: TBitchart:PNG
TLResourceList.Sort 59 DUPLICATE RESOURCE FOUND: TBitchart:PNG
TLResourceList.Sort 60 DUPLICATE RESOURCE FOUND: TBitchart:PNG
TLResourceList.Sort 65 DUPLICATE RESOURCE FOUND: TLinechart:PNG
TLResourceList.Sort 66 DUPLICATE RESOURCE FOUND: TLinechart:PNG
TLResourceList.Sort 67 DUPLICATE RESOURCE FOUND: TLinechart:PNG
TLResourceList.Sort 68 DUPLICATE RESOURCE FOUND: TLinechart:PNG
TLResourceList.Sort 70 DUPLICATE RESOURCE FOUND: TLinediagchart:PNG
TLResourceList.Sort 71 DUPLICATE RESOURCE FOUND: TLinediagchart:PNG
TLResourceList.Sort 72 DUPLICATE RESOURCE FOUND: TLinediagchart:PNG
TLResourceList.Sort 73 DUPLICATE RESOURCE FOUND: TLinediagchart:PNG
TLResourceList.Sort 82 DUPLICATE RESOURCE FOUND: TSNRMperband:PNG
TLResourceList.Sort 83 DUPLICATE RESOURCE FOUND: TSNRMperband:PNG
TLResourceList.Sort 84 DUPLICATE RESOURCE FOUND: TSNRMperband:PNG
TLResourceList.Sort 85 DUPLICATE RESOURCE FOUND: TSNRMperband:PNG
TLResourceList.Sort 108 DUPLICATE RESOURCE FOUND: TTraffic:PNG
TLResourceList.Sort 109 DUPLICATE RESOURCE FOUND: TTraffic:PNG
TLResourceList.Sort 110 DUPLICATE RESOURCE FOUND: TTraffic:PNG
TLResourceList.Sort 111 DUPLICATE RESOURCE FOUND: TTraffic:PNG
^C
[Duo2 dslstats64L-5.3]$
-
Eric seems fine running the Windows version here on W7. Very minor issue with snapshots page the check box and the word All and g of graphs is partially obscured where it says "All graphs configured to autosave" which is under Autosave on Exit. Hope I described that OK.
Stuart
-
Just to say the 64bit Linux version starts OK for me and if I run it from a console I see those exact same errors as reported by burakkucat but it still starts OK.
Stuart
-
Just to say the 64bit Linux version starts OK for me and if I run it from a console I see those exact same errors as reported by burakkucat but it still starts OK.
Stuart
Yes, those messages aren't errors as such, they're just advisory messages, and they've always been there.
-
Result of testing from the command line --
... etc
Thanks for checking that. There's nothing wrong there, so I'm puzzled. Are you running it in a completely clean situation, or do you still have a ~/.dslstats directory from a previous version? If the latter, then could I presume on your patience a bit more and suggest that you delete or rename ~/.dslstats and try again?
-
The 32-bit Linux version starts without any problems.
- changed the way CRCs and FECs are collected (using "Total time = ..." section instead of SFErr and RSCorr)
Thanks for this change. What happens if some devices don't have the "Total time" section? Are the ES and SES values collected from the data above?
Do you know what happened with MDWS?
Thanks for confirming that. For modems which don't have the "Total time" section it should fall back to the previous sources using SFErr (or OHFErr) and RSCorr. The ES and SES values are collected from the section higher up (as before) but perhaps I need to review these as well?
MDWS did have some downtime on Monday, but it's running properly now. You may need to refresh your browser cache if it's not displaying correctly.
-
No problem.
- Moved the ~/.dslstats/ directory to a safe location.
- Removed the dslstats64L-5.3/ directory.
- Extracted a fresh copy from the tarball.
- Double left clicked on the icon. Nothing appeared. System process status showed dslstats was executing. Sent SIGTERM.
- Invoked dslstats from the command line. Messages appeared, as expected. No graphical screen was shown. Process interrupted.
Totally puzzled. ???
-
Eric seems fine running the Windows version here on W7. Very minor issue with snapshots page the check box and the word All and g of graphs is partially obscured where it says "All graphs configured to autosave" which is under Autosave on Exit. Hope I described that OK.
Stuart
Thanks Stuart. I can confirm that little display issue on the snapshots page in the Windows version. It will be corrected in the next release.
-
Totally puzzled. ???
Me too. I guess it might be a library issue of some sort. Do you have gdk-pixbuf installed?
-
No, gdk-pixbuf is not installed. :no:
Has reliance on that package been added since v5.2?
Edited to add: But gdk-pixbuf2 is installed.
[Duo2 ~]$ rpm -q gdk-pixbuf2
gdk-pixbuf2-2.24.1-5.el6.x86_64
[Duo2 ~]$
-
Has reliance on that package been added since v5.2?
No, I was grasping at straws, trying to work out how the program is apparently running while not displaying its GUI. I'll have to sleep on it.
-
I'll have to sleep on it.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.centos.toracat.org%2Fajb%2Ftmp%2Fbed.gif&hash=929535fa04b3a03dcbf953d36bc04cea0117c79c)
A wise move. I still have v5.2 available for use, so there is no great urgency.
-
Just started running Version 5.3 on Raspberry Pi, would have had it up an running hours ago but the boot-config just vanished after a reboot and zero display but putty was fine so just re-built the config.txt file and it's all good again ???
-
My probably naive question is, does the HLOg graph have any value in assessing ADSL/ADSL2+ connections?
-
It might have some value if it has a really unusual shape (indicating something badly wrong), but it's much more useful over the wider frequency range of VDSL2.
-
Thanks! As it happens I reckon mine would be OK with being pretty horizontal at lower down then ~30 deg slope.
-
I'll have to sleep on it.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.centos.toracat.org%2Fajb%2Ftmp%2Fbed.gif&hash=929535fa04b3a03dcbf953d36bc04cea0117c79c)
A wise move. I still have v5.2 available for use, so there is no great urgency.
Having slept on it and a bit more, I'm still unable to explain this. Either the program is hanging during initialisation, or something else is causing it not to display its window. All of the changes since V5.2 relate to things which happen during recording, not during initialisation, but there have been no significant changes in the initialisation.
My best idea at present is to make a diagnostic version which logs everything which happens during initialisation and saves it to a file. Would you be willing to give this a test?
-
My best idea at present is to make a diagnostic version which logs everything which happens during initialisation and saves it to a file. Would you be willing to give this a test?
Why, yes. Most certainly. But please do not make it a priority. :)
-
Thanks for the work improving things it is generally working well here on XP and will try raspberry pi soon. :) but: -
Just one issue spotted -- the 24 hours now reset correctly - with the exception of the SES. e.g. the modem uptime correctly shows
SES Up 0 0 0 0
Down 0 0 0.08 2.01
but the 24 hour right from the first start show strange large values including upstream ones e.g.
SES Up 0 0.17 10.0 241
Down 0.02 1.34 80.2 1925
On reset the 24 hour SES values don't go to zero but jump to much larger values suggesting some incorrect number that is not reset is being used.
-
Thanks for the report. I think that the SES issue will sort itself out, although I will check again.
-
Eric I am unable to understand the average values for SES when compared to the graph. The averages has values but scrolling the graph shows no SESs at all a straight line of zero since starting DSLStats.
Stuart
-
Stuart, I recognise this issue, which is the result of loading previously saved data into the new enlarged array which holds it. If you reset the values the issue will go away after a period. Alternatively if you shut down DSLstats, delete the file errors.dat from the directory where the configuration files are saved, then restart DSLstats, you should find that correct averages are shown from then on.
-
Restarting after deleting errors.dat seemed to have fixed the SES issue. But after one new SES a reset of the 24 hours does not reset the new 24 hour SES back to zero. The previous SES is continuing to be counted. I seem to always need to delete errors.dat and restart to get the correct response.
The SES in the 24 hours are behaving like the ES did in the previous version.
-
Eric the SES thing is not a huge issue for me as I dont seem to have any ;) but I do understand now why I see what I see....
Stuart
-
Eric the SES thing is not a huge issue for me a
Agreed, I am only trying to be helpful in reporting issues. To prove I now have the pi on 5.3. On the pi I never use the 24 hour reset. I find the reset is mainly handy when testing and after a resync.
-
Thanks for the reports guys. I've checked out the details now, and I see that I did miss a trick - if errors.dat is absent at startup time then all the average error values are set to zero as they should be, but when you press the "Reset values" button the SES values are not zeroed. This is now corrected, and I'll upload the corrected version in a few days.
-
I've discovered bug. If I disable monitoring Bitloading and SNR per tone, it enables itself after reboot of DSLStats.
Best regards
konrado5
-
Yes, you're right. I will correct this in the next release.
-
It seems some settings on the "Items to Monitor" page are not saved. Fore example "SNR per tone" and "Bitloading" are always enabled after a restart of the program.
-
with plusnet tg582N --do I need to alter any settings
attached shots of settings --no data
-
It seems some settings on the "Items to Monitor" page are not saved. Fore example "SNR per tone" and "Bitloading" are always enabled after a restart of the program.
Yes, that was reported by Konrado above. It will be corrected.
-
with plusnet tg582N --do I need to alter any settings
attached shots of settings --no data
You probably need to enter a password. I don't remember what the default password is for the Plusnet TG582N, but it may be the device serial number.
-
Yes, that was reported by Konrado above. It will be corrected.
Sorry, I missed it. Apart from that v5.3 runs fine on windows and linux.
-
No modem/router drop down lists under normal and special login.
tried removing .dslstats no change. :o
-
The modem/router drop-down lists are loaded from two files routers.dat and specialrouters.dat. These files should be in the same directory as the executable. Are they missing?
-
The modem/router drop-down lists are loaded from two files routers.dat and specialrouters.dat. These files should be in the same directory as the executable. Are they missing?
Yes they are there.
What I normally do is to have it start up at boot up but with the problems I have been having I disabled that and had a icon on the desktop to start it when I wanted, That is the problem if I click on 'dslstats' in it's own directory it works ok. :'(
Whats the best way to link it to the desktop ?
Had to take HG612 out of service and put my Speedtouch back, with the HG612 on the bench connected to a 32 Bit test computer DSLstats is accessing it ok and just reporting that there is no DSL connection (that's correct ) and no other log in complaints.
-
Whats the best way to link it to the desktop ?
Perhaps you need to create a small startup script:
#!/bin/bash
cd <Directory where dslstats executable is>
./dslstats
Call the script start-dslstats and mark it as executable. Create a desktop icon to run the script.
-
Thanks I will try that.
-
have tried all variations of password and still "no data returned in latest sample"
firewall is disabled in router to allow all access, tried re-booting router
have deleted and re loaded 5.3, tried 5.2
SUCCESS--Mistakenly trying to monitor newly installed 582n router when it is the 612modem I should be monitoring in the Stats set up---oops!!!!!! :-[ :-[
-
Perhaps you should ensure that you are able to telnet into the device before trying to configure DSLstats?
telnet IPv4_Address_of_tg582N
If you are unable to access the device via telnet then nor will DSLstats.
-
@konrado5 and morphium:
I've looked into why the bitloading and SNR per tone are always enabled after a restart of DSLstats. The reason is that you have these items enabled in the MyDSLWebStats options. Enabling these items in MDWS automatically enables them in "Items to monitor". If they are not enabled in MDWS, then the "Items to monitor" options work as expected.
I can probably handle this a bit better, and when I have some time I'll look at it.
-
I can say that the 'flashing paw' works, with my problems it being tested well ;)
-
Thanks for confirming that (although I'm sorry about your problems). :)
-
@roseway:
Thank you very much. Disabling bitloading and SNR per tone in MyDSLWebStats is helpful. But I've had to disable "Include with bit-loading" in SNR category to disable SNR per tone monitoring. It is additional bug.
Best regards
konrado5
-
@konrado5: Yes, that's correct. It will be fixed.
-
I think I found one bug too. The font used to display the current date in graphs has trouble with accented characters like "é", causing in-graph dates to appear as "18 d?c.2014". I live in France and windows' set to use french.
-
DSLstats is showing me to have had a resync ->
Uptime: 13 days 5 hours 28 min 13 sec
Resyncs: 1 (since 17 Dec 2014 17:25:48)
yet i have no info of this and HG612 modem stats viewer is correct.
Had a look back to-day at 17:25 and the only thing that changed was my IP address on the router so DSLstats must automatically think this is a resync :-\
17 Dec 2014 17:25:45 Configuration files stored in C:\Users\*****\AppData\Local\dslstats\
17 Dec 2014 17:25:45 Snapshot folder is C:\Users\*****\Documents\dslatats graphs\
17 Dec 2014 17:25:45 Average errors saved as 'errors15.txt' in snapshot directory
17 Dec 2014 17:25:45 Average error data reset
17 Dec 2014 17:25:48 Recording started
17 Dec 2014 17:25:56 IP address is now ***.***.***.185
17 Dec 2014 19:25:53 Auto snapshots taken
17 Dec 2014 21:26:53 Auto snapshots taken
17 Dec 2014 23:27:52 Auto snapshots taken
-
I think I found one bug too. The font used to display the current date in graphs has trouble with accented characters like "é", causing in-graph dates to appear as "18 d?c.2014". I live in France and windows' set to use french.
I'm sorry about that. I'll try to correct it, but it may take a little time.
-
@NewtronStar: I thought I'd got this right with the last changes, but obviously not. I'll take another look.
-
Just an idea. :hmm:
I found some old stats from 2.2014 but I can not remember which modem/router I was using, I looked on some of the stats but could not see any reference to modem etc.
Is it possible to put that say on the Event Log header ?.
-
That's a good idea. I don't know of any straightforward way to get the actual model which is in use, but I can record the model which is configured in the login setup.
-
Yes that's what I was thinking, if I come up with anything else I will let you know. :)
-
@NewtronStar: I thought I'd got this right with the last changes, but obviously not. I'll take another look.
It seems to think a resync has occured when you execute DSLstats, the RPi version is showing a resync: since 11 Dec 2014 02:33:15 thats the time I executed V5.3 on the raspberry pi
-
See my other post in the ADSL , DG634GT etc.
Not sure if it's a problem but Looks like FEC errors are not being recorded unless they are 0 all day :hmm:
-
I think I found one bug too. The font used to display the current date in graphs has trouble with accented characters like "é", causing in-graph dates to appear as "18 d?c.2014". I live in France and windows' set to use french.
I've had a look at this, and I can't reproduce the problem. On my WinXP test machine, accented characters are displayed correctly in the DSLstats graphs.
The graphs use the host system's default font and character set. I could use a specific character set, but that might lead to display issues for some other users. I'll see if it's practical to provide a user choice of font and character set.
-
@NewtronStar: I thought I'd got this right with the last changes, but obviously not. I'll take another look.
It seems to think a resync has occured when you execute DSLstats, the RPi version is showing a resync: since 11 Dec 2014 02:33:15 thats the time I executed V5.3 on the raspberry pi
I've reworked the way DSLstats detects resyncs (again). It's proving quite difficult to cover all possibilities without having false positives.
-
See my other post in the ADSL , DG634GT etc.
Not sure if it's a problem but Looks like FEC errors are not being recorded unless they are 0 all day :hmm:
This may be an issue with older models which don't report FECs directly. DSLstats should fall back to using RSCorr instead for these models, but it looks as though it's not doing so. One more for the list. :)
-
See my other post in the ADSL , DG634GT etc.
Not sure if it's a problem but Looks like FEC errors are not being recorded unless they are 0 all day :hmm:
This may be an issue with older models which don't report FECs directly. DSLstats should fall back to using RSCorr instead for these models, but it looks as though it's not doing so. One more for the list. :)
OK :)
Not sure if this is working as should >configuration>Items to monitor>other>include with bitloading ....If you tick it after re-boot tick goes away , it does not 'pin' it !.
Also just after system boot > click on tray 'paw' icon and it seems frozen then later it recovers, I did take a couple of memory dumps, not sure if you want them ?
-
I'm afraid the memory dumps wouldn't mean anything to me.
Is DSLstats set to run and start recording automatically after a reboot? If so, the freezing may be the initial sampling period if it's only a few seconds.
When you reboot or shut down the PC, do you close DSLstats first? If not, this might explain the unsaved option. There's no simple way in Linux for the OS to notify applications when it's closing down, so DSLstats will just be killed without exiting normally and saving its configuration.
-
I'm afraid the memory dumps wouldn't mean anything to me.
ok
Is DSLstats set to run and start recording automatically after a reboot? If so, the freezing may be the initial sampling period if it's only a few seconds.
Auto start.
Yes I did think it may be.
When you reboot or shut down the PC, do you close DSLstats first? If not, this might explain the unsaved option. There's no simple way in Linux for the OS to notify applications when it's closing down, so DSLstats will just be killed without exiting normally and saving its configuration.
No I do not close it first as I thought it was 'set to save' .... I see .
Thank you.
-
Re "Not sure if this is working as should >configuration>Items to monitor>other>include with bitloading ....If you tick it after re-boot tick goes away , it does not 'pin' it !."
I have tried clicking the 'x' before I shut down the laptop but it still does not stick and when DSLstats runs again after boot up the >configuration>Items to monitor>other>include with bitloading is UN-ticked . :'(
------------------------------------------------------
Will an older version of DSLstats work any better for this :-
Re "This may be an issue with older models which don't report FECs directly. DSLstats should fall back to using RSCorr instead for these models, but it looks as though it's not doing so. One more for the list"
-
Are you sure that you're closing down DSLstats and not just minimising it? The red 'x' may (depending on the configuration) just minimise the program.
Concerning the FEC issue, I have a new version just about ready for release, and this correctly falls back to RSCorr when FEC's aren't reported directly.
-
Are you sure that you're closing down DSLstats and not just minimising it? The red 'x' may (depending on the configuration) just minimise the program.
I get this "Do you want to close the program?" Yes
Maybe a script in '/etc/rc.d/rc0.d' might work ? to softly shut the system down after DSLstats has saved it's data !.
Concerning the FEC issue, I have a new version just about ready for release, and this correctly falls back to RSCorr when FEC's aren't reported directly.
8)
-
There is a bug on this version 5.3
The total time at the top and the bottom is different. The top say 65 days while the bottom say 49 days see below:
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 32213 Kbps, Downstream rate = 90457 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 8.9 14.7
Attn(dB): 11.3 0.0
Pwr(dBm): 12.4 -1.2
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 239 237
M: 1 1
T: 23 42
R: 0 16
S: 0.0955 0.3781
L: 20104 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Bearer 0
OHF: 3429477339 4227255
OHFErr: 14607 13627
RS: 0 4291836
RSCorr: 0 203809
RSUnCorr: 0 0
Bearer 0
HEC: 33431 0
OCD: 223 0
LCD: 223 0
Total Cells: 580617614 0
Data Cells: 3996794608 0
Drop Cells: 0
Bit Errors: 0 0
ES: 5553 3544
SES: 0 0
UAS: 27 27
AS: 5672791
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 3.98
OR: 116.09 64.22
AgR: 80103.09 20063.54
Bitswap: 1615/1615 42812/42812
Total time = 65 days 15 hours 47 min 23 sec
FEC: 0 203809
CRC: 14607 13627
ES: 5553 3544
SES: 0 0
UAS: 27 27
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 2 min 23 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 4 0
ES: 3 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 15 hours 47 min 23 sec
FEC: 0 1240
CRC: 578 55
ES: 115 35
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 5759
CRC: 964 383
ES: 118 95
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 49 days 17 hours 2 min 47 sec
FEC: 0 203809
CRC: 14607 13627
ES: 5553 3544
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
-
That's not a bug in DSLstats, it's a bug/feature in the modem firmware. The text you quoted is the raw output of the CLI command "adsl info --stats".
-
Its not a bug in DSLstats.. it appears to be something to do with the BCM chipset command adsl info --stats and it doesnt count days correctly
Mines the same on my Zyxel.. for some reason the bottom figure doesnt seem to go above 49 days.. and the top figure just plain counts the days wrong.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 30714 Kbps, Downstream rate = 83113 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79987 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.7 12.8
Attn(dB): 0.0 0.0
Pwr(dBm): 14.3 5.9
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.0955 0.3771
L: 20104 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 3144297494 2738972
OHFErr: 26243 304
RS: 0 4284286
RSCorr: 0 7104
RSUnCorr: 0 0
Bearer 0
HEC: 127267 0
OCD: 12392 0
LCD: 12392 0
Total Cells: 1044738347 0
Data Cells: 1386073927 0
Drop Cells: 0
Bit Errors: 0 0
ES: 14938 288
SES: 31 0
UAS: 4469 4469
AS: 5201597
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 6.15
OR: 116.09 202.87
AgR: 80103.09 20203.27
Bitswap: 38290/38290 251/251
Total time = 1 days 22 hours 19 min 4 sec
FEC: 0 7214
CRC: 33790 314
ES: 14938 288
SES: 31 0
UAS: 4469 4469
LOS: 1 0
LOF: 6 0
LOM: 0 0
Latest 15 minutes time = 4 min 4 sec
FEC: 0 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 4 0
ES: 3 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 22 hours 19 min 4 sec
FEC: 0 73
CRC: 255 1
ES: 224 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 104
CRC: 221 7
ES: 158 7
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 49 days 17 hours 2 min 46 sec
FEC: 0 7104
CRC: 26243 304
ES: 14468 278
SES: 18 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
-
Thanks again for this software, been working great for me.
Very quick question, I'm running on Debian x64, I clicked upgrade within the program GUI, just wondered where it downloads the files?
I'm going to download manually for now, but just interested for housekeeping :)
-
Thanks for the comments. If an upgrade is available an extra tab opens with all the information about the upgrade, including a selector where you can choose the download directory. By default it's the same directory as the configuration files, and this is listed in the event log.
-
Having strange fuzzy text from any of the xdslcmd outputs tabs it was working fine yesterday and have re-installed DSLstats 5.3.1 and still the text looks weird didn't change any font setting on the PC side the only things on the PC that's changed from yesterday to do-day are quite a few windows up-dates came in.
Any clue on how to fix this ?
-
Hmm . . . that does look somewhat "out of sorts". However, I don't think that is due to Eric's utility. I would point an accusative paw in the general direction of one of the latest updates that you have installed. :-\
-
DSLstats uses the host system's default monospaced font for these tabs. As far as I can tell, Windows systems normally use Courier New here, and your fuzzy font looks like Courier New with bits missing. If it was fine yesterday but not today, then it obviously must relate to something on the system which has changed in the last day, but at the moment I can't imagine what sort of change would give this result.
I could make the font used in the text pages a configurable item if it helps.
-
[/b]'s utility. I would point an accusative paw in the general direction of one of the latest updates that you have installed. :-\
I guess it's the only logical explanation for this anomaly the question is which one of the updates has caused this :-\
I could unintall all the updates below or do a system restore to the 11/2/2015 and see what happens.
-
I could make the font used in the text pages a configurable item if it helps.
Thanks eric that may be an option if i can't find what caused this.
.
-
Good news uninstalled those updates and text is back to normal on DSLstats the bad news is i don't know which one is the culprit :-[
-
Install one update set at a time and check the DSLstats display after each installation. ;)
-
Install one update set at a time and check the DSLstats display after each installation. ;)
Will do B*CAT and will let you know the outcome.
-
Found the culprit it's the Security Update for windows Vista (KB3013455) ;D
and this http://forums.moneysavingexpert.com/showthread.php?p=67696373 (http://forums.moneysavingexpert.com/showthread.php?p=67696373)
-
I am currently using my windows server to run DSLstats and monitor my Huawei hg635.
I have decided to monitor a few things on my new raspberry pi, but I am having trouble getting dslstats to login; the problem may be the username (!!Huawei), but this cannot be changed in the hacked firmware config I am using.
I have logged in using telnet with no problem; I have also tried substituting !! with %21%21 and mentioned here https://technodedigest.wordpress.com/2012/04/14/tackling-special-characters-in-proxy-passwords-on-linux/ (https://technodedigest.wordpress.com/2012/04/14/tackling-special-characters-in-proxy-passwords-on-linux/).
Anybody have any other options/ideas.
Ian
-
Found the culprit it's the Security Update for windows Vista (KB3013455) ;D
and this http://forums.moneysavingexpert.com/showthread.php?p=67696373 (http://forums.moneysavingexpert.com/showthread.php?p=67696373)
Excellent detective work. Let's hope that a fix will arrive promptly from M$.
-
Found the culprit it's the Security Update for windows Vista (KB3013455) ;D
and this http://forums.moneysavingexpert.com/showthread.php?p=67696373 (http://forums.moneysavingexpert.com/showthread.php?p=67696373)
Yes, that was good detective work. It's good to know there's an explanation.
-
I am currently using my windows server to run DSLstats and monitor my Huawei hg635.
I have decided to monitor a few things on my new raspberry pi, but I am having trouble getting dslstats to login; the problem may be the username (!!Huawei), but this cannot be changed in the hacked firmware config I am using.
I have logged in using telnet with no problem; I have also tried substituting !! with %21%21 and mentioned here https://technodedigest.wordpress.com/2012/04/14/tackling-special-characters-in-proxy-passwords-on-linux/ (https://technodedigest.wordpress.com/2012/04/14/tackling-special-characters-in-proxy-passwords-on-linux/).
Anybody have any other options/ideas.
Ian
The username is case sensitive, I think. The password certainly is. Are you definitely getting that right?
DSLstats should be able to cope with the exclamation marks, but it's just possible that they have some special significance in the networking library which handles this.
-
Are you definitely getting that right?
Yes...double and triple checked.
Ian
-
I had no trouble with a HG635 and dslstats. I used the default usernames and passwords. I selected the modem type as HG622 although I recall I also used the Hg635 type. I set the IP address be be the one I set in the HG635. If your troubles persist I will try mine again with the current/latest dslstats. When I last used it I think dslstats also had automatic Hg622 type detection so selecting that manually is worth a try.
-
I presume you were using the raspberry pi.... It works OK with windows
-
I've recently tried v5.3 in win8.1 and am unable to get it to login to my HG635, gone back to using DSLstats v5.2 and that's fine with theHG635.
I had assumed it's something silly I was doing but as v5.2 suited my needs I haven't investigated the issue.
I'm happy to try again with v5.3 and the HG635 if it helps.
-
gone back to using DSLstats v5.2
I will try the beta pi v5.3.2 if not i may request the older 5.2 version for the pi.
Ian
-
Got it working....beta version 5.32 and as les-70 mentioned tick "Modem/router is hg622 type" ???
Ian
-
The HG622 issue is a small quirk of that model (and possibly some others) in combination with the networking library I use in DSLstats. It seems that the telnet interface needs an extra 'kick' after supplying the login details before the prompt reappears, and the HG622 option enables this kick.
It's a fudge, but it's the only way I could get it to work with these particular models. Auto-detection proved problematic, so now it's a user option.
-
@roseway Thanks.
I can now monitor stats with the pi, but it seems unable to upload to mdws, username and key are verified (Checked OK), curl is identified correctly and no errors in the event log.
I have also checked the time on the PI.
Any ideas?
Ian
-
If you look on the RPi at the directory /home/pi/.dslstats/mydslwebstats you should see several files including one called CurlResult. This is a plain text file, and its contents may give a clue.
(I don't know if you're familiar with Linux, but .dslstats (note the dot at the beginning) is a hidden directory, and if you're following the path above in a file manager you'll need to enable the option "Show hidden files" to see it.)
-
Found that file and it contains
"USER MISMATCH 0......"
Ian
-
You appear to be already uploading to MDWS from a Windows machine. MDWS doesn't support simultaneous uploads from different machines.
-
How long should I leave it between machines...
ie switch of windows uploads....wait X mins.....start pi uploads?
I have waited up to 10 mins with the same result.
Ian
EDIT: windows uploads stopped now.
-
There's no need to wait any time. That's probably not the problem. Although DSLstats has checked the username and key, it appears that there is a mismatch, so please make absolutely certain that you've entered the correct values.
I'll try to contact tbailey2, to see if he can see the cause of the problem on the MDWS server.
-
Thanks.
-
We've worked out the answer now. It relates to one particular character in your validation key which gets corrupted in the uploading process. The version of DSLstats which you're using with Windows (v5.2) doesn't have this problem.
I'm about to release a new version (5.4) but before I do so I'll correct this bug. It won't take long.
-
Thanks roseway, I will keep a look out for the new version.