26,00: that is the T.35 country code for China
48,49,53,49: HISI could be HiSilicon/Huawei?
It's a Huawei cabinet (Huawei stamp on the cabinet) but I have no idea what chip is used inside. It should be Broardcom but why it's not listed as the ATU-C Vendor that's another mystery.
1 Like
JFTR, after a bit back and forth, the fix has been merged into master and 19.07 (just in time to be included in today's 19.07.1). If the PPPoE bug is caused by this issue and fixed by the patch -- and I have high hopes it does -- it solves a really, really long standing bug with DSL on Lantiq.
At any rate, the bugfix will solve stability problems with DSL on Lantiq, so upgrading to 19.07.1 or a current master is certainly not a bad idea anyway, if only to rule out stability issues with the system before looking into minute differences of DSL firmware blobs.
2 Likes
Since the audience of this thread might be interested in that as well:
https://forum.openwrt.org/t/simple-tool-to-query-lantiq-modem-statistics-and-diagnostics-useful-for-modem-routers-running-openwrts-dsl-cmd/53857
Might be helpful to get Bitloading, SNR, H(log) and QLN plots out of lantiq modems under OpenWrt...
Sorry for the distraction.
zyxel,p-2812hnu-f1
OpenWrt 19.07.0-rc2 r10775-db8345d8e4
ATU-C Vendor ID: Broadcom 192.244
Firmware Version: 5.7.5.6.1.7
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Line Uptime: 5d 0h 52m 54s
So, basically I'm not sure whether this is conclusive or not, but my dis-/reconnects have a strange pattern. I observed it during the last 14 days.:
Monday 10.02.20 19:00
Thuesday 11.02.20 20:00
Wednesday 12.02.20 10:20
Thursday 13.02.20 ---
Friday 14.02.20 ---
Saturday 15.02.20 19:30
Sunday 16.02.20 15:00
Monday 17.02.20 13:00
Tuesday 18.02.20 ---
Wednesday 19.02.20 20:00 20:15
Thursday 20.02.20 ---
Friday 21.02.20 18:00 18:35
Saturday 22.02.20 ---
Sunday 23.02.20 ---
Monday 24.02.20 ---
Tuesday 25.02.20 17:00
It is +/- 3 minutes, but still weird. It seems this isn't caused by my router but the ATU?
The version 5.9.1.4.0.7 is unstable for me.
5.7.8.12.0.7, aka 5.7.8.C.0.7 is stable for me.
bt,homehub-v5a
OpenWrt 19.07.1 r10911-c155900f66
ATU-C Vendor ID: Broadcom 177.191
Firmware Version: 5.7.8.12.0.7
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Line Uptime: 3d 11h 11m 3s
Vdsl2 with no vectoring an everything stable on whatever firmware I push to W8970. Currently on 5.9.1.4.0.7 annexa and 5.4 kernel
1 Like
That's a first. AFAIR everyone who used v9.x ended up regretting the decision because it simply doesn't work.
same for me, stable whatever firmware... can't notice any differences in performance.. TD-W8970 in bridged mode 19.07.2 stable..
ATU-C Vendor ID: Broadcom 164.154
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 Uptime: 13d 31h 24m 53s
All firmware I can find is here.
I own a BT Hub 5A and have tested several firmwares during the last 14 days. I can say that in my case 5.9.0.12.1.7 has been by far the most stable and this is what I am going to stick with.
5.9.1.4.0.7 was less stable and a few promising versions as per users' feedback (5.7.8.12.0.7 and 5.7.11.5.0.7) were quite annoyingly unstable with around 2 line drops per day.
My ISP has VDSL2 with Vectoring and DSLAM's chip is a Broadcom 177.166.
I think that each user has to test several firmwares to find the ideal combo for each particular case. I am not so sure if a general rule of stable and unstable firmwares exists.
@takimata, I think you generalize things a bit in relation to the origin of the cloud and maybe it is not appropriate in this instance; at least provide some concrete evidence to support your argument. Fyi, I did SHA1 checksum for firmware 5.9.0.12.1.7 (in both 6.85 and 6.86 folders of the aforementioned zip file) and they are identical between each other. Furthermore, I compared such SHA1 with the values of the firmwares located in: https://xdarklight.github.io/lantiq-xdsl-firmware-info/
As you can see below, the values are identical, hence I do not see anything dodgy, at least in the firmware that I checked:
5.9.0.C.1.7-5.9.0.A.0.2
SHA1: 756553dcb16ffee8bc1a92f13ae1670d6db35a79
905028 bytes
Name: vr9-B-dsl.bin
Size: 905028 bytes (883 KiB)
CRC32: 2FDD75F2
CRC64: 7238377B27BEC622
SHA256: 8644CBB409BB8DE9FBB088A490FAB7EB12BD733015E01963400BB1382DBDEE49
SHA1: 756553DCB16FFEE8BC1A92F13AE1670D6DB35A79
BLAKE2sp: 268C63E2CC20F8A6CBAE9A0D1B65D316E42ADB75571EED921BC8166EEFCA5356
I can confirm that I am stable, fast and happy with firmware 5.7.8.12.0.7 on a Zyxel 2812 with stock OpenWRT 19.07.2 on KPN WBA (Telfort) VDSL in Netherlands. Since last reboot, 10 days uptime and counting. I have a stable line, and with telco firmware on the 2812 I would easily get months of uptime. I hope to be able to get the same with this OpenWRT-firmware combo.
The DSLAM is Broadcom 177.191.
Interestingly, I do seem to hit a bug where my actual line speed (as measured with iperf3) is quite a bit higher than the data rate reported by dsl_control. I will investigate this further.
mmmh, I wonder, does your ISP use G.INP?
Could you post the outpout of the following 4 commands as issued on your vrx200' command line, please?
. /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 0
. /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 1
. /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 0
. /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 1
I get (vdsl2 with vectoting and bi-directional G.INP/ReTx):
root@vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 0
nReturn=0 nDslMode=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=-1
root@ vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 1
nReturn=0 nDslMode=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=-1
root@ vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 0
nReturn=0 nDslMode=1 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=1 b20BitSupport=-1
root@ vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 1
nReturn=0 nDslMode=1 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=1 b20BitSupport=-1
As far as i can tell nDslMode=1 means VDSL, so only the last two should be relevant, in my case bReTxEnable=1 indicates the G.INP retransmissions are active (which can have an influence on the estimated rates, eithter gross rates or rates with some deductions for likely retransmit loss).
Hi @moeller0 here you go, same output by the looks of it?
# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 0
nReturn=0 nDslMode=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=-1
# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 1
nReturn=0 nDslMode=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=-1
# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 0
nReturn=0 nDslMode=1 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=1 b20BitSupport=-1
# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 1
nReturn=0 nDslMode=1 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=1 b20BitSupport=-1
Thanks, yes, that would indicate that G.INP is in use. Now we would need to get access to the ReTx statistics:
root@vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd ReTxStatisticsGet 0
nReturn=0 nDirection=0 nRxCorruptedTotal=1580226 nRxUncorrectedProtected=1367016 nRxRetransmitted=0 nRxCorrected=213210 nTxRetransmitted=193672
root@vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd ReTxStatisticsGet 1
nReturn=0 nDirection=1 nRxCorruptedTotal=381223 nRxUncorrectedProtected=344923 nRxRetransmitted=0 nRxCorrected=36300 nTxRetransmitted=488171
to confirm that ReTx is actually in use. Unfortunately that command is not supported out of the box, see
Blockquote for the necessary patches. But that is going to cost some time and is not guaranteed to go anywhere. The reason I bring this up is simply that ReTx introduced a new reported speed category that (if retransmits do happen) is lower than the real sync speed and as long as no retransmits eat into the sync budget that achievable speed will be above that ReTx corrected Rate. It could be that either driver or blob differ in which rate they report... But I see no real actionable outcome for figuring this out, if a driver/firmware combination is robust and stable, I would happily accept a slightly oddity in reported sync numbers 
instead of getting correct/precise numbers from an unstable combo.
I am not sure if the developers will pick up patches from bugs.openwrt.org.
When you consider the patch ready to be integrated into OpenWrt, I suggest to follow the Submitting patches guide. You can mention the bug number in the commit message like this:
Fixes: FS#2792
1 Like
Thanks! Good idea. I had hoped that at least somebody else, preferably on a non G.INP/ReTx VDSL link coud actually test this for side-effects, but I guess just hoping for that to happen was quite naive 
So my situation has changed in the last few days and I can attest to that statement. Yesterday, one of my lines changed to a 100/40 vectoring line. For me, 5.7.8.9.0.7 does the trick (quite appropriately so, as it originally comes from a FritzBox 3370 image, and is now running on a FritzBox 3370 again), whereas 5.9.0 or 5.9.1 firmwares were unstable with frequent disconnects.
Oh, I wholeheartedly agree that it is a really handy collection of firmwares if you need to try out a few to find the one that works for you. I may have overreacted a bit, and yes, you can be sufficiently safe if you compare checksums. But please keep in mind that it is still technically illegal to redistribute firmware blobs. There is a reason why the xdarklight page does not offer them for direct download, as handy as that would be.
avm,fritz7360sl
OpenWrt 19.07.1 r10911-c155900f66
ATU-C Vendor ID: Broadcom 178.5
Firmware Version: 5.7.4.4.1.7
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Line Uptime: 24d 4h 30m 6s
1 Like