Good question, my lantiq modem is in hibernation and I have not yet looked at the most recent changes, but I am confident that the shell code from old lantiq_dsl.sh that implemented dsl_cmd could be copied into a stand alone script and be used from there. Actually, I will have to look at that in the future again, but due to reliability and retrain issues with the lantiq modem I switched over to a broadcom modem.
It looks like
is still part of the package, which in the end should sifficie to talk to the firmware blob.
just my 2 cent... parse command output is always wrong... so really IMHO the ubus change should really improve the data sampling and script handling...
Also about the breakage... this is a new version so it's really just an update of the package...
it would be a breakage if the change was done in the same version (a minor update to 19.x changed the script)
They ported data to ubus that is the correct way to handle this kind of thing and we are complaining for the effort...
In all the time (years) I have used OpenWRT modem routers (now I use only BT Home Hub 5), I found 3 use cases for which it becomes necessary to query dsl parameters. OpenWRT support for these 3 use cases makes this firmware stand out against any proprietary modem/router:
manual query to check whether the line is performing as expected
manual query to troubleshoot connection issues
script to feed a database at regular intervals with data necessary to analyse line performance and degradation through time (particularly useful to support the case with stubborn ISPs when typical FTTC line degradation occurs over long periods of time)
Although a fast response time would be indeed desirable, none of those cases (especially 3) depend upon a response below 2".
However cases 1 and 2 depend upon a human readable report, whilst case 3 depends on scripts that are no longer available.
Therefore in light of the simple comparative impact analysis above, my assessment that the change applied adds no benefits is based on facts, rather than opinion.
To see added value I would have to see a positive impact on the 3 use cases above, instead, as a consequence of the change, none of the 3 use cases can be achieved now.
My impression on the other end is that your assessment is based on your opinion that does not take into account the typical use cases above.
On your following messages:
thank you for providing the vendor table.
I confirm that neither dsl_cmd nor lantiq_dsl.sh are in 21.02
I would like to ask what is your typical hardware configuration for xDSL (FTTC), I find myself stuck to BT Home Hub 5 which is an excellent modem router, but in some of my cases it has become a little too slow. On the other end I do not want to depend on a proprietary modem.
Except, that in the end, the source of the information here is always a query to the firmware-blob, which seems to report oddly formatted data packed in ASCII strings. So all methods query the same source. But I take it you argue against parsing the formatted output of dsl_control, to that I agree
I am upset because there was no user impact analysis. Practically they removed what made OpenWrt outstanding against proprietary xDSL modem/routers.
I suppose it can be added, but why not re-create the existing user interface as part of the change?
The response time is only a symptom, the problem is the load the "old way" caused.
Take LuCI for example. It displays DSL stats on the front page, and they are refreshed every few seconds. As a consequence, the "old way" lead to a load of ~ 0.5 just for keeping the front page open.
Calling status on an etc/init.d script should always have displayed the service status, this was finally codified back in 2018. dsl_control has been an exception for a long time, having historically used the "status" argument to output ... well, the line status. To bring it in line with other etc/init.d scripts, the change in syntax was necessary. This change happened separately, quite some time before the switch to ubus.
Addendum: I agree, there is no "beautiful" way to get DSL stats on the shell right now, at the moment it is purely machine-readable (though not impossible to parse for human eyes.) Reformatting the ubus output into a table should be easy to do, it's just up to somebody to create this reformatting script. That somebody ... could be you.
Sorry, it is based ob your assessment of facts, which in itself is a subjective judgement. A fact and an evaluation of a fact are two separate things. But I get your annoyance, I would be annoyed as well if my so far working solution stopped doing so to offer new features I would not need.
Which is your right to think. I happen to disagree and will offer https://github.com/moeller0/lantiq_dsl_parser as indicator that I might be more involved in that question than you might assume.
Well, then use dsl_cpe_pipe.sh as shown above, which should do the trick as well.
I only have a single link, and I used a HH5A as bridged Modem under OpenWrt as well. Since my ISPs vectoring line-cards are all Bradcom based and do not play nicely with the xrx200 ever since the ISP activated G.INP on both directions I switched to use a zyxel vmg1312-B30A (configured as bridge).
I actually tried that initially, but already ran into CPU issues when trying with a 50/10 link as router/firewall/SQM, so I relegated the HH5A to bridged modem only. Which worked well until the ISP activated vectoring and bi-directional G.INP and increased the Sync-limits to 116/40, at which point I got multiple re-syncs per week, sometimes per day...
Yes, I understand. I came from the same position and was simply "converted" by the lantiq becoming unstable (by no fault of lantiq) and the broadco proved to be rock solid. I since rewired my internal phone line to further increase the line (less FEC errors, zero CRCs). I am tempted to try the HH5A again, but that would also make a decent AP to increase WiFi coverage: decisions, decisions, decisions
None of my providers support vectoring (I have Infostrada and Vodafone in Italy, Plusnet and TalkTalk in the UK), however I am using vectoring Lantiq firmare as follows:
ATU-C Vendor ID: Broadcom 192.20
ATU-C System Vendor ID: Broadcom
Chipset: Lantiq-VRX200
Firmware Version: 5.9.1.4.0.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 55
Errored seconds (ES): Near: 0 / Far: 4
Severely Errored Seconds (SES): Near: 0 / Far: 0
Loss of Signal Seconds (LOSS): Near: 0 / Far: 0
Unavailable Seconds (UAS): Near: 173 / Far: 173
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.14 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 86.081 Mb/s / Up: 18.911 Mb/s
Line Attenuation (LATN): Down: 8.3 dB / Up: 8.6 dB
Signal Attenuation (SATN): Down: 8.3 dB / Up: 8.5 dB
Noise Margin (SNR): Down: 6.1 dB / Up: 8.0 dB
Aggregate Transmit Power (ACTATP): Down: -21.9 dB / Up: 13.9 dB
Max. Attainable Data Rate (ATTNDR): Down: 98.992 Mb/s / Up: 28.134 Mb/s
Line Uptime Seconds: 183692
Line Uptime: 2d 3h 1m 32s
The above is Vodafone IT as you can see the line is quite clean and never drops (the only restarts are due to my maintenance). But in Italy FTTC is 100% VDSL2 (no microfilters), telephone is supplied via VOIP. In the UK the service isn't as good, I always have had problems and they still share broadband with phone on the same line with microfilters.
I am wondering if I am missing something by continuing to use BT HH5.
The performance issues I was referring to were due to my requirements to run also TFTP and NFS shares (to boot diskeless servers), also my router on the 100/20 VDSL2 line is just about performing OK with software NAT offload. If I had a faster line I think it would become a bottleneck.
No idea, but here in Germany quite a number of folks using xrx200 modems reported issues after vectoring and G.INP activation. Not restricted to HH5As but also with the over-here quite popular AVM Fritzbox 7490. I believe AVM managed to get things improved enough to stop being an issue, but they are using more recent VDSL drivers than OpenWrt and matching firmware blobs. I have a hunch that these blobs might not work optimally with the older drivers in OpenWrt, but no proof for that hypothesis.
My own line was quite dirty, so the sub-optimal combination of lantiq modem and broadcom linecard was just struggling/limping along. I went for a broadcom modem as written above and it turned out that @takimata had already written a data collector for those that can be run as part of OpenWrt's statistics collection. in the end I got better monitoring for the new modem as well (plus dslstats to get QLN and SNRmargin/bit loading per carrier plots). I intended to go back to the HH5A after confirming that my line's instability was not caused by the lantiq modem... but it turns out the zyxel was stable immediately (albeit syncing a bit lower). So instead of complaining to my ISP and going back to the HH5A I simply stuck with the other modem (my family appreciates a stable internet way more then a slightly faster but less stable one )
Then over christmas, I repositioned the telephone socket in my apartment and got rid of 12 meter of wiring and as a result most of the CRC errors the broadcom modem was still collecting...
So maybe one of these might help your UK line as well?
I can believe that the HH5A is nice an compact, but the SoC was designed in a world of ~50/10 dsl plans, not necessarily 80/20 or 100/40... it had a good run.
Going back to "ubus call dsl metrics", working on a human readable report that reproduces "dsl_control status" I noticed that errors->[near|far]->fecs are always = 0 (this is a G.992.5 ADSL2+ line) whilst "es" increases. Which is quite not a likely result. Please could you double check whether "fecs" is picked correctly?
One more question: please, could you let me know where I can find latency status on the new json structure, equivalent to the following lucistat output:
dsl.latency_s_down="Interleave"
dsl.latency_s_up="Fast"
This is also quite an important parameter to check when lines go bad.
Since my HH5A is powered down, there is not much I can do right now, looking at the new code things look reasonably okay, but the C code used ioctl to actually query the values so that is a bit hard to confirm/debug without a working lantiq modem....
Not hands-on with a device, but parsing the code this information should now be contained in "upstream" and "downstream", as numeric "interleave_delay". The old code simply parsed a value >100 into the string "Interleave" and <= 100 into "Fast".
At the start of this thread you said that the way to retrieve lantiq dsl modem information is through "ubus call dsl metrics" which is what I am doing.
The script snippets you posted above do not take this information from the json structure returned.
Please could you let me know where do I find latency information in the json structure? I would not want to mix the information source in my report script, if I had to then why not just restore and make the previous dsl_control available as part of 21.02 distribution as I suggested initially?
