well it works on my HH5
line is stable but i guess has some noise now and then. When i moved in over a year ago i got 80/20 reported. now its down to 51/10 ish. Enough that i know not to bother paying for anything more than 40/10
That is curious, lots of errored seconds but almost no CRC errors that would account for them. I wonder what the underlying cause for the ES is.
Ah, good point, and nice link 
If I find a trick to make it stable I will post it here, but so far it is not much better than in the past, so the issue was neither the then high error rates on my link, nor the fact that vectoring error samples could not be sent... (or by using a more recent firmware blob I might now be running into totally new issues). As I said, I will likely revert back to the Zyxel, sure OpenWrt is nice as a modem OS, but it is even nicer not having to worry at all about a modem
In that case, a safe trip and enjoy!
Regarding collectd and exec scripts it is not even a competition, I am not even playing the same game
from the other thread on vectoring Vectoring on Lantiq VRX200 / VR9 - missing callback for sending error samples
https://xdarklight.github.io/lantiq-xdsl-firmware-info/ < dsl firmware versions if u want to play with other versions.
1 Like
Thanks, I have been there before 
turns out for me the dm200 5.8.1.5.0.7 (dsl_vr9_firmware_xdsl-05.08.01.05.00.07_05.08.00.09.00.01.bin) blob goes into a silent->handshake->fullinit->silent loop not sure why...
Thanks for these scripts - saved me time and taught me loads (I think!).
I have been using them for a few days and I may have found a solution to the STDERR problem - but I am a complete noob, so take what I say with a pinch of salt!
In exec-lantiqdsl.sh after you set the hostname I have set an interval and then wrapped the rest of the script (not the exit) in a function.
At the bottom, after the function end (but before the exit) I added a "while true" loop where I call the function I just wrapped the script in and also sleep for the interval. Obviously, the exit is now superfluous!
I got this idea from the SQM collectd scripts... I believe collectd/exec takes care not to create duplicate processes - and I read somewhere this is more efficient than making collectd/exec create a new process every time (but I seriously have no clue!).
At the same time as doing this I also removed some of the data collection (CRC's and FECS) that I wasn't interested in and added HEC errors - so I suppose it's possible this "loop" idea does nothing, and my other changes somehow got rid of the STDERR error.
Although, when I removed the while loop from the SQM script it too triggered a random STDERR daemon error from that script! Soooo... yeah!
My suspicion is that its something to do with STDERR buffering its writes.
Instead of my "loop" solution, maybe flushing STDERR before exiting the script would also work?
I haven't tried - mostly because I'm clueless about how to do it!
Feel free to point out any mistakes, bad practice, poor nomenclature... or if all of this is rubbish please just remove the post - no hard feelings!
1 Like
Quite the contrary, thank you for the input!
I am aware that this is one of the two possibilities:
- have collectd run the script periodically
- have the script run once in an endless loop and report values periodically
Functionally, both options do pretty much the same thing. With the latter option, of course it will never result in that STDERR error simply because the script never ends and never returns any exit codes or errors to collectd. However, it will also run "asynchronously" besides collectd, and to date I have not found any indication which one of the two options is more appropriate.
I will look into it. I have another router to convert to 21.02 soon, with a different script for a different modem, but doing the same thing, and I will take another stab at it.
1 Like