I recently bought a BT Hub 5a which was already flashed on ebay.
Now that I've got it all configured, I'm wondering if it is possible to increase the speed. I was using a Fritzbox 7390 before which could achieve roughly 50mbit/s downstream.
Now with the BT Hub, even after switching to the modem blob of a 7490, I only achieve 20mbit/s.
Here is what LuCi tells me:
Line State: UP [0x0] Line Mode: G.993.2 (VDSL2) Line Uptime: 19m 27s Annex: B Profile: 17a Data Rate: 20.532 Mb/s / 1.603 Mb/s Max. Attainable Data Rate (ATTNDR): 22.143 Mb/s / 1.684 Mb/s Latency: 0.14 ms / 10.0 ms Line Attenuation (LATN): 8.3 dB / 3.8 dB Signal Attenuation (SATN): 8.3 dB / 3.8 dB Noise Margin (SNR): 6.2 dB / 10.9 dB Aggregate Transmit Power(ACTATP): 12.8 dB / 10.5 dB Forward Error Correction Seconds (FECS): 0 / 0 Errored seconds (ES): 0 / 3 Severely Errored Seconds (SES): 0 / 0 Loss of Signal Seconds (LOSS): 2 / 0 Unavailable Seconds (UAS): 1230 / 1230 Header Error Code Errors (HEC): 0 / 0 Non Pre-emtive CRC errors (CRC_P): 0 / 0 Pre-emtive CRC errors (CRCP_P): 0 / 0 ATU-C System Vendor ID: Broadcom 192.85 Power Management Mode: L0 - Synchronized
Without knowing all of the details this gives the impression of a vectoring conflict. I assume your DSLAM uses vectoring, but your firmware for the vdsl-modem does not support vectoring and the DSLAM put you on the fallback profile for non-vectoring capable CPE. At least deutsche telekom, does not use vectoring on the lowest 2.2MHz of the spectrum (otherwise, they would need to switch out all non-vectoring capable ADSL[1|2|2+] gear in the field with vectoring capable VDSL2 gear, probably too expensive) and any modem/CPE that does not negotiate vectoring with the DSLAM will be assigned a profile where it can only use those vectoring-free frequencies, as not to negatively interfere with the vectoring processing in the same binder.
Tl;dr: try a firmware blob that supports vectoring, and talk to your ISP as some DSLAMs need a manual port reconfigure (or similar procedure) to get a line out of the fall-back profile again.
Basically, the speed is agreed between your router and your ISP hardware based on their joint estimate of the noise level. Your SNR seem to be a bit high, and this might lead to more conservative speeds atm. You can either wait and see if the situation improves on its own — rapid connections and disconnections of your modem may also be counted as noise and contribute to high SNR estimate. You can get in touch with your ISP to ask them manually reset the line and wipe the stats. You can also upgrade to Snapshots and use the experimental SNR parameter to try to manipulate speeds from your side. Note that snapshots are not stable and you will need to install Luci via ssh.
I've tried different firmware blobs from this xdsl site and they all do more or less the same. How can I really make sure that I'm using a VDSL vectoring firmware?
Your Luci output does not tell us which blob you are currently using. You can see it if you log in your router via ssh (putty in windows) and execute /etc/init.d/dsl_control status as shown in my example above. For example, in my example it says:
root@OpenWrt:~# /etc/init.d/dsl_control status
...
Firmware Version: 5.9.0.12.1.7
This confirms that my blob is 5.9.0.C.1.7, which, according to the xdsl site includes vectoring support. Except my ISP does not support it yet.
I do not know, but if the DSLAM locks you into the non-vectoring fall-back profile you will not really see whether another firmware blob will help until the profile is reset. If you still have the FB around, connect that again and report the sync bandwidth (and maybe also post the spectrum view). If the FB syncs at 50Mbps, try the openwrt box again, with a firmware blob that should support vectoring, if the FB also syncs at 22/1 call your ISP...
I wonder, could you maybe add one more post to this thread explicitly noting which steps you took to actually get this working? So that others facing similar challenges might have an easier time in the future to get it fixed again? That would be great!
Using a different device temporarily was probably enough to convince the ISP's DSLAM to reset the port and do a new full link training without fallback profile.