This is almost always the wrong thing to do as this simply defaults to the 14 bytes that the kernel traditionally reserves for src and dst MAC addresses and ethertype. Instead of going though this line by line, here is a proposal for a sqm config:
You need to try this out, because if this is about compatibility with your DSLAM's firmware there is no way figuring out from a different DSLAM (and I am not even in the UK so really could not tell you). That said, I would try with the latest release version "VDSL over ISDN incl. vectoring support" where the ADSL part is labeled as "ADSL Annex A".
No flashing required, just copy the extracted blob to a known location on the router, e.g. to:
just replace with the correct file name. There is no need to reflash the router's whole firmware to upload a different firmware blob for the dsl modem (think of the modem as its own little comnputer and the blob being the OS, driver, and DSL application code to run on that computer).
Ah, for simple.qos, I also need the output of tc -d qdisc, but realistically this is not going to fix your low level DSL sync issue, so maybe post-pone this until the DSL issue is addressed?
I cannot seem to extract the blob tried downloading from site and getting 404 error. I also tried wget and getting
"wget: SSL support not available, please install one of the libustream-.*[ssl|tls] packages as well as the ca-bundle and ca-certificates packages."
I really think you need to use a different machine to download and extract firmware blobs as that requires a number of tools that seem tricky to get working on OpenWrt.
Seems like great advice above and how about also posting on the Plusnet forum? They are pretty responsive there too. See, for example, this thread:
I don't suppose you are able to get onto one of the BT 'full fibre' packages? My mother is getting one of those and I feel rather envious!
I used to use Plusnet myself for a 25Mbit fibre line and helped my mother with hers. My experience is that their service deteriorated rapidly a couple of years or so ago. They advertise rate X but provide rate X - Y, where Y is significant, and glitches and downtime all over the shop. It took lots and lots of complaining to get things fixed.
Then I moved house to the middle of nowhere in the Scottish Highlands (I don't really like people very much). Now we only have copper ADSL here up to around 6Mbit/s download. Happily our new house is rather close to a Vodafone cell tower so just use a 4G router and get circa 25-70Mbit/s download and 30Mbit/s upload. With a little help from OpenWrt SQM it's fine for all our business and personal needs. These days 4G/5G connections can give some of the weaker ADSL/fibre services a run for their money, albeit a good fixed line fibre is still of course superior. Our local farmer complained a lot about lack of fibre but didn't know about 4G - I told him to try and now he is very happy with it like me.
I note from your first post, the Vendor ID is reported as Infineon (not Broadcom). It looks like you may be connected to a dreaded and rare ECI made FTTC cabinet (not Huawei/Broadcom). There was talk of trying to enable G.INP last year, but it may have been abandoned again.
I agree with @moeller0 with regards to trying a different firmware blob to see if it helps. The upload speed is abnormally low and it looks like a compatibility issue. As far as I'm aware, the firmware blob has not changed since LEDE 17.01.
well it depends on what modulation scheme is in use. The firmware will negotiate that scheme. a different firmware blob can potentially negotiate a different modulation which could enable the higher upload speed.
That's the max attainable with the firmware blob currently in use. The max attainable with a different modulation would be different (kinda like the difference between 802.11n and 802.11ac)
So for the upload at 24 dB attenuation DSLAM and CPE negotiated a transmit power of only -4.5 dB, which effortlessly explains the low sync, but the question is why the low transpit power setting. And that might be related to a mismatch between dslam and cpe firmware versions. I still think trying a few different firmware blobs to be easy enough to try. But I also agree that it is not guaranteed to help.
Regarding modulations there is not much slack in VDSL2 as far as I can tell, for each subcarrier 0 to 15 bits per dsl clock can be used but at the OP's low transmit power not much SNR margin exists and hence subcarriers will only get a low bitloading....
Also never underestimate the influence of half-broken cabling (in-house and patch cables, as well as the splitters and sockets; try the main service socket) - and yes, this individual bthub5 might also be a potential cause of problems (be is hardware damage of this particular devices, no vectoring blob loaded and being forced into a fallback profile or suboptimal compatibility between the DSLAM and this vr9 lantiq modem chipset).
One time my ADSL micro filter broke and I got weird stuff happening. Replaced that and that fixed the issue. Should definitely be checking results at the master socket too. Another time my extension cable got loose from master socket and had to just fiddle with that.