BTHub 5a reduced VDSL speed and no vectoring

Installing and Using OpenWrt
1

Let me start by saying that I've done my relative search and research, such as:

I am with EE if that matters, and I have a Broadband Plus, which offers a theoretical 75Mbps. Using their shitty router, I get consistently 51Mbps which also happens to be the minimum guaranteed speed. Recently I replaced their box with an eBay bought BT Hub 5a flashed with OpenWrt.

So whereas the EE router can consistently get that 50+Mbps, the BT Hub 5a can only do 31Mbps. Digging around with the settings, I found out that vectoring is set to false. It seems to me that the BT Hub/OpenWrt is downgrading the connection to VDSL from VDSL2, and thus I lose the extra speed I could get and pay extra for.

How do I go about solving this? (Please don't tell me to change the router!)

Cheers!

2

Openreach does NOT support Vectoring in the UK.

Your maximum broadband speed is determined by the quality of your DSL line.

How did you measure the speed? Was it via ethernet or Wifi ?

Or did you read the DSL line speed from the DSL status page in LuCI?

Have you studied the installation guide?
https://www.dropbox.com/sh/c8cqmpc6cacs5n8/AAA2f8htk1uMitBckDW8Jq88a?dl=0

Try turning on packet steering as it is off by default. Enabling Software Flow Offloading may also help.

50 Mbps to ethernet LAN is possible with PPPoE on Openreach with LEDE 17 and OpenWrt up to 19.07.

Speeds via Wifi speeds will likely be lower. ie. if you are losing speed only when using wifi, consider installing a separate access point (running OEM firmware), or get a new off the shelf modem wifi-router (eg. TPlink VR series).

3

Hi, so much information my head hurts.
To answer your questions; I have FTTC with EE. I have occasionally gotten 68Mbps even 70Mbps. It was always over WiFi 5G using the same speedtest server to keep it consistent.

No I haven't studied this guide, I didn't install it. I'm also using OpenWRT 21.02.03 so I'm not sure if this guide applies anymore?

Now, something interesting happened. I switched back to the old router for an hour, and when I switched back to the new BT Hub/OpenWRT the speed went up. I didn't change anything. It is still considerably lower than the 50+ Mbps I got with the EE Router, but it shot up from 31Mpbs to 41Mbps.

For reference, here's my dslstats:

{
	"api_version": "4.17.18.6",
	"firmware_version": "5.7.9.9.0.6",
	"chipset": "Lantiq-VRX200",
	"driver_version": "1.5.17.6",
	"state": "Showtime with TC-Layer sync",
	"state_num": 7,
	"up": true,
	"uptime": 6,
	"atu_c": {

	},
	"power_state": "L0 - Synchronized",
	"power_state_num": 0,
	"xtse": [
		0,
		0,
		0,
		0,
		0,
		0,
		0,
		2
	],
	"annex": "B",
	"standard": "G.993.2",
	"profile": "17a",
	"mode": "G.993.2 (VDSL2, Profile 17a)",
	"upstream": {
		"vector": false,
		"trellis": true,
		"bitswap": false,
		"retx": false,
		"virtual_noise": false,
		"interleave_delay": 0,
		"data_rate": 10123000,
		"latn": 30.100000,
		"satn": 30.100000,
		"snr": 6.200000,
		"actps": -90.100000,
		"actatp": 13.200000,
		"attndr": 10122000
	},
	"downstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": true,
		"virtual_noise": false,
		"interleave_delay": 130,
		"data_rate": 59021000,
		"latn": 21.100000,
		"satn": 19.500000,
		"snr": 3.100000,
		"actps": -90.100000,
		"actatp": 7.500000,
		"attndr": 59993316
	},
	"errors": {
		"near": {
			"es": 148,
			"ses": 67,
			"loss": 0,
			"uas": 184674461,
			"lofs": 4165,
			"fecs": 0,
			"hec": 0,
			"ibe": 0,
			"crc_p": 1,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0,
			"rx_corrupted": 1845256,
			"rx_uncorrected_protected": 811107,
			"rx_retransmitted": 0,
			"rx_corrected": 1034149,
			"tx_retransmitted": 0
		},
		"far": {
			"es": 2897,
			"ses": 10,
			"loss": 0,
			"uas": 184674461,
			"lofs": 0,
			"fecs": 7165,
			"hec": 0,
			"ibe": 0,
			"crc_p": 0,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0
		}
	}
}

I've been messing around with SNR offest, and I've explicitbly placed the DSL firmware in my configuration. So it all looks like this:

config dsl 'dsl'
	option annex 'b'
	option tone 'a'
	option ds_snr_offset '-65'
	option line_mode 'vdsl'
	option xfer_mode 'atm'
	option firmware '/lib/firmware/lantiq-vrx200-a.bin'

config device
	option name 'dsl0'
	option macaddr '18:62:2c:13:58:51'

config interface 'wan'
	option proto 'pppoe'
	option ipv6 '0'
	option username 'PRODUCTIONHQNUNXXXXXX@fs'
	option password 'XXXXXXX'
	option mtu '1492'
	option device 'dsl0.101'
	option ifname 'dsl0.101'

At this point I'm suspecting that EE is actually throttling the speed down, thinking there's an error or something similar? I'm just puzzled by the fact that their own router consistently has better speed.

I have a second router I use internally for my work and other wifis (a LinkSys) but it doesn't have a DSL interface. I can re-run speed tests over ethernet if you think that will make a difference, but all speed tests I've run so far were over Wifi and the discrepency is there.

Also, I am frequently getting disconnections, with the following error:

Thu Aug 11 12:59:42 2022 kern.warn kernel: [48787.856813] enter showtime
Thu Aug 11 12:59:42 2022 kern.info kernel: [48787.858425] IPv6: ADDRCONF(NETDEV_CHANGE): dsl0: link becomes ready
Thu Aug 11 12:59:42 2022 daemon.notice netifd: Network device 'dsl0' link is up
Thu Aug 11 12:59:42 2022 daemon.notice netifd: VLAN 'dsl0.101' link is up
Thu Aug 11 12:59:42 2022 daemon.notice netifd: Interface 'wan' has link connectivity
Thu Aug 11 12:59:42 2022 daemon.notice netifd: Interface 'wan' is setting up now
Thu Aug 11 12:59:42 2022 kern.warn kernel: [48787.870613] enter showtime
Thu Aug 11 12:59:42 2022 daemon.err insmod: module is already loaded - slhc
Thu Aug 11 12:59:42 2022 daemon.err insmod: module is already loaded - ppp_generic
Thu Aug 11 12:59:42 2022 daemon.err insmod: module is already loaded - pppox
Thu Aug 11 12:59:42 2022 daemon.err insmod: module is already loaded - pppoe
Thu Aug 11 12:59:42 2022 daemon.info pppd[13298]: Plugin rp-pppoe.so loaded.
Thu Aug 11 12:59:42 2022 daemon.info pppd[13298]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
Thu Aug 11 12:59:42 2022 daemon.notice pppd[13298]: pppd 2.4.8 started by root, uid 0
Thu Aug 11 12:59:42 2022 daemon.err pppd[13298]: Interface dsl0.101 has MTU of 1492 -- should be at least 1500.
Thu Aug 11 12:59:42 2022 daemon.err pppd[13298]: This may cause serious connection problems.
Thu Aug 11 12:59:53 2022 kern.warn kernel: [48799.117007] leave showtime
Thu Aug 11 12:59:53 2022 daemon.notice netifd: Network device 'dsl0' link is down
Thu Aug 11 12:59:53 2022 daemon.notice netifd: VLAN 'dsl0.101' link is down
Thu Aug 11 12:59:53 2022 daemon.notice netifd: Interface 'wan' has link connectivity loss
Thu Aug 11 12:59:53 2022 daemon.err pppd[13298]: select (waitForPADO): Interrupted system call
Thu Aug 11 12:59:53 2022 daemon.warn pppd[13298]: Timeout waiting for PADO packets
Thu Aug 11 12:59:54 2022 daemon.err pppd[13298]: Unable to complete PPPoE Discovery
Thu Aug 11 12:59:54 2022 daemon.info pppd[13298]: Exit.

I've been on the phone with EE and they refuse to help, saying that they don't support 3rd party routers! At the same time the speedtest now returned 65.67Mbps over the Wifi.

4

The installation guide is relevant to 21.02 for basic VDSL2 setup with UK ISP.

option xfer_mode 'atm'
It should be set to 'ptm' btw.

"data_rate": 59021000,
Should see 55 Mbps on ethernet speed test?

Also the ds_snr_offset figure -65 doesn't look right but I could be wrong.

Have you checked the 'up time', and actual DSL data rate (in the DSL stats section in the Luci Overview page), to see if DSL is 'dropping', and whether the speed is fluctuating wildly between reconnects?

Speed test using HH5a wifi, is not a reliable measure on HH5a with openwrt imho.

If you are not witnessing frequent disconnections with original EE hub, have you considered the BT hub's DSL port could be faulty if it is a 'used' item. If it was bought off ebay, most sellers probably don't even test the DSL port for any length of time if at all, prior to sale.

The black HH5a were introduced in 2013 and discontinued in 2016/17 btw.

I'm not familiar with the new white EE hub I've seen advertised on TV.

No major UK ISP will help if you use a 3rd party router.

fwiw, you could configure the Openwrt HH5a to run in Bridge mode (section 9.8). That will allow you to use any modem-less wifi router with PPPoE. I've not tested bridge mode with OpenWrt 21.

fwiw, cheapest brand 'new' Broadcom based VDSL2 'bridge' modem is probably TPlink TD-W9970 for around £30

0bridge
0bridge816×328 38.7 KB

5

Hi, thanks for the help and suggestions.
I suspect you're correct, the DSL port may be dying. I've spent two hours staring at "network device not present". Thank god I had backups from last night when it worked.

I am currently getting only 31Mbps. Same test but EE router saw 65Mbps.

I think I might try it in bridge mode, so that I rely on the WRT1900ACS for my actual needs, and just use this one for VDSL.
I suspect there's a setting wrong somewhere that causes it to drop the speed.

I'm gonna try the setup you suggested now, and then maybe try to bridge it.

EDIT:
I forgot to ask, how can I calculate the SNR offset? Or should I leave it at zero for now?

6

This means there is no DSL sync with the green FTTC cabinet. The LuCI status page will also report line is down and no DSL info.

SNR offset should be left at Zero

Check the data rate reported in Status page. It is not clear from your posts, is the 'data rate' currently 31 Mbps, or are you still measuring speed via wifi ?

If the data rate is indeed 31 Mbps reported by LuCI (or dslstats), then I'm afraid no amount of fiddling with settings will resolve what looks like a hardware fault. It does not look like a line fault given EE hub is synching fine at higher speed.

7

Are you using the stock Openwrt dsl driver?
This thread may help:

The stock Openwrt lantiq dsl driver has no support for vectoring, and while Openreach do not support vectoring, there are some PCP cabinets with vectoring enabled.
It may be worth trying a vectoring enabled driver.

8

I suspected so. What really bothers me is that this only happens with BTHub/OpenWRT. Plug in the EE router and the problem goes away.

Done! As well as the PTM.

I was measuring over wifi. I run the same test over the ethernet (bear in mind it is bridged over my powerline adapter) and I now got 52.79Mbps.
dslstat reports:

"upstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": false,
		"virtual_noise": false,
		"interleave_delay": 0,
		"data_rate": 10219000,
		"latn": 30.000000,
		"satn": 29.700000,
		"snr": 6.000000,
		"actps": -90.100000,
		"actatp": 13.500000,
		"attndr": 10219000
	},
	"downstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": true,
		"virtual_noise": false,
		"interleave_delay": 130,
		"data_rate": 59622000,
		"latn": 21.100000,
		"satn": 19.500000,
		"snr": 3.400000,
		"actps": -90.100000,
		"actatp": 7.300000,
		"attndr": 60533520
	},

I've been wondering if it is indeed a hardware fault or if I'm overloading that poor router with WAP, VLANs and whatnots, and maybe just bridging it may help it.

I am indeed! Thank you I'll take a look!

9

Your ethernet speed test result of 52 Mbps is in the right vicinity for DSL line sync of 59,622,000 bits/sec, unlike the HH5A wifi speed test returning 31 Mbps.

The disconnections remain unexplained if they are still occurring.

10

I'm still confused; how is the EE router achieving higher rates? Different firmware?

11

You haven't posted any DSL stats from EE hub, so I can't comment. You've only reported wifi speed tests of 51 Mbps for the EE hub in your OP, which suggests the DSL data rate may be 55-60 Mbps which would be similar to what BT Hub data rate of 59 mbps. ie. possibly little or no difference on ethernet.

New EE hub may be using broadcom chipset which can offer slightly faster DSL data rates than Lantiq based devices (HH5a) if you are connected to a Huawei FTTC cabinet. eg. My Plusnet Hub Two (broadcom) can sync at crazy/unreliable 70 mbps whereas HH5a running any firmwares struggles for 65 mbps data rate.

I think the current white EE hub has been around since 2020? Comparing the arrangement of the rear sockets and Reset hole, it would not surprise me if the EE hub is just a rebadged Broadcom based 2019+ BT Smart Hub 2 (2022 Plusnet Hub Two), which I think feature a dual core 1GHz ARM ? processor, that likes to run very hot like all Broadcom devices.

Plusnet Hub Two (2022) - rebadged 2019+ BT Smart Hub 2
0plusnet

EE hub (2020)
0eehub2020

1 Like
12

Sadly I can't get much more than a small technical log. I'm happy to post it here if it will help.

Thanks, that's what I was suspecting. Yes that's the one I have, I'm happy to carefully open it if it will help. Is it supported/flashable with OpenWRT?

13

The newer smart hubs are NOT supported by OpenWrt and never will.

If the menus in the EE smart hub are the same as the BT and Plusnet equivalents, the Technical Log should offer DSL information such as Data Rate, Max data rate, Noise margin, attenuation etc. which you can compare with HH5a DSL stats ?

0bridge
(The DSL uptime and Data rate in above image are blank, due to a firmware bug when Hub Two is operating in 'Bridge mode' (It is available in Event Log). BT Retail, and EE smart hubs do not offer bridge mode.)

14

This is not what is happening, VDSL while a predecessor of VDSL2 is incompatible both with ADSL[1|2|2+] and VDSL2 and has seen very little deployment in Europe.

That is what I ended up doing with my HH5A, after it did not manage PPPoE/NAT/firewalling/sqm/WiFi on a 50/10 plan. Now as bridged modem only with a modern vectoring capable firmware blob (my ISP requires this) I can reach sync of 116.8/37.0 Mbps and speedtests reach up to 106/35 (directions measured sequentially, the CPU is maxed out during those tests though). IMHO after recent changes in OpenWrt HH5As make decent bridged-modems, but really are overtaxed with doing router task in addition.

I think this is at least part of the root cause...

This will depending on encapsulation and IP version allow up to (VLAN, PPPoE, IPv4, TCP):
59.622 * 64/65 * ((1500-8-20-20)/(1500+26)) = 55.86 Mbps
of measurable throughput in your typical on-line speedtest. Real tests often stay a few percentage points below this theoretical celling. I agree with Bill 32 is underwhelming.

1 Like
15

Thanks so much for the help and patience bill! I'll take a screenshot later, as I've currently got tons of work to do and can't be messing around with the internet connection.

Hi, I'm a bit confused by the above statement. Not about the PPPoe/NAT/Firewall/Wifi, I get all that. But what you're saying implies that you did indeed get it to clock speeds attainable only with VDSL2 and not just VDSL? Is this because you used a different firmware blob for the DSL device? I've already started moving most operations to my LinkSys so I'm definitely interested in your solution.

16

Again VDSL1 has never been deploted in the UK or Germany at all, only VDSL2. These are two related but incompatible standards.
Yes I was able to use my HH5A with the default OpenWrt firmware blob at 50/10, but then my ISP upgraded to requiring vectoring, so I had to switch to a vectoring enabled firmware blob (I took the current one from AVM's FritzBox 7490, as that devices uses the same DSL chip as the Hh5A).
This is likely a german pecularity, but after the vectoring activation on my DSLAM the non vectoring firmware only synced up to ~20/5 Mbps (I forgot the exact numbers) as non vectoring modems are only permitted to use the first 512 subcarriers. The rationale is that ISPs did nit want to exchange all ADSL modems in the field with vectoring friendly ones and hence simply excluded those subcarrieres used by ADSL from vectoring. It is unlikely but not impossible that something similar is happening in your case, although I would first assume overload.
On github you can find tools to get information about how your modem synchronized and SNR and bitloading spectra:

Maybe try to collect the output when using the HH5A and post it here?

17

So this is a case about VDSL2 using and not using vectoring essentially? Thanks for the link I'll take a look and see what I can do with it. I think I'll spend some evenings playing with it to see what I can get out of it. Thanks for the help and explanation!

18

At least for Germany, this part is not quite correct. Early VDSL deployments in Germany which were served from the central (former) 'post office' (direct copper cable between both endpoints) started out as VDSL1 (BRAS platform). Only connections terminated at the outdoor DSLAMs (the bigger, actively cooled cabinets in the streets) were exclusively deployed as VDSL2 (using the BNG platform) from the start. The cutoff between VDSL1 and VDSL2 for new deployments must have been sometime between late 2014 and early 2016 (and all should have been switched to VDSL2 and the BNG platform until 2018/ 2019).

1 Like
19

This is really news to me, and wikipedia for what it is worth. I will not rule out VDSL1 (ITU-T G.993.1 ) pilots in selected areas, but as far as I know Deutsche Telekom never had a mass market internet product based on VDSL1. As far as I know they switched from only-ADSL2+ to VDSL2 and ADSL2+ for too long lines (as one of the earlier ISPs to select VDSL2 in 2006). I can not even find documentation for a telekom speedport modem supporting VDSL1 at all (so which modems did telekom use at that time?).
But I will refine my argument to "VDSL1 has not seen quantitative mass deployment in Germany" and probably is extinct already.

This is seems to indicate that what you call "VDSL1" really is VDSL2 ( ITU-T G.993.2), but not VDSL2 with vectoring (ITU-T G.993.5). Deutsche Telekom started its VDSL2 deployment ( ITU-T G.993.2) in 2006... the 50/10 product was based on VDSL2. Vectoring introduction was later as this required regulatory changes;the way vectoring works it needs to control all lines in a wire bundle, so it is not compatible with local loop unbundling, where multiple ISPs have DSLAMs in the central office and lines are patched to the DSLAM of the ISP an end user is customer of, in vectoring all (VDSL2) lines in a bundle need to terminate at the same DSLAM. It took a while for the regulatory agency Bundesnetzagentur to come to grips with this unfortunate reality, but in the end "re-monopolisation" of physical access lines and "virtual unbundling" was selected as least worst option.

And, yes the ITU nomenclature and numbering scheme might be logica, but intuitive it is not.

CORRECTION: according to https://en.wikipedia.org/wiki/List_of_VDSL_and_VDSL2_deployments BT did actually deploy VDSL1 in the UK, but in recent Openreach's SIN 498 documents only VDSL2 is mentioned, so if the UK did see some VDSL1 deployment in the past it is long gone; however my hunch is that wikipedia is simply confused, the timeline seems to indicate that the section UK (VDSL) really just shadows the early parts of UK(VDSL2), but this could also be wishful thinking on my side :wink:

1 Like
20

So, it happened again I got kicked out of the DSL. I'm starting to think this is the heatwave affecting the local cabinets and not my router. And of course it happened during the week's sprint review :rofl:

Here's the screenshot from EE's Broadcom Router.

EE DSL Screenshot
EE DSL Screenshot733×578 45.3 KB

I'm gonna plug back in the BT Hub and check the logs, see if there's anything of use. I think I'll need to install the xDSL library for stats to make some more sense out of it.

Also I just run a speed test using the same server as always over the EE router, and it scored 45Mbps, same as the BT hub yesterday, so there's definitely a fluctuation and degradation during working hours and heat waves.

EDIT:

The openwrt logs don't reveal much:

Fri Aug 12 16:07:12 2022 kern.warn kernel: [84364.502544] leave showtime
Fri Aug 12 16:07:12 2022 daemon.notice netifd: Network device 'dsl0' link is down
Fri Aug 12 16:07:12 2022 daemon.notice netifd: VLAN 'dsl0.101' link is down
Fri Aug 12 16:07:12 2022 daemon.notice netifd: Interface 'wan' has link connectivity loss
Fri Aug 12 16:07:12 2022 daemon.info pppd[31446]: Terminating on signal 15
Fri Aug 12 16:07:12 2022 daemon.info pppd[31446]: Connect time 851.2 minutes.
Fri Aug 12 16:07:12 2022 daemon.info pppd[31446]: Sent 1144007912 bytes, received 2400462811 bytes.
Fri Aug 12 16:07:12 2022 daemon.notice netifd: Network device 'pppoe-wan' link is down
Fri Aug 12 16:07:12 2022 daemon.notice netifd: Network alias 'pppoe-wan' link is down
Fri Aug 12 16:07:12 2022 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Fri Aug 12 16:07:12 2022 daemon.err odhcp6c[31498]: Failed to send RS (Permission denied)
Fri Aug 12 16:07:12 2022 daemon.err odhcp6c[31498]: Failed to send SOLICIT message to ff02::1:2 (Permission denied)
Fri Aug 12 16:07:12 2022 daemon.notice netifd: Interface 'wan6' is now down
Fri Aug 12 16:07:12 2022 daemon.notice netifd: Interface 'wan6' is disabled
Fri Aug 12 16:07:12 2022 daemon.notice netifd: Interface 'wan6' is enabled
Fri Aug 12 16:07:17 2022 daemon.notice netifd: Interface 'wan' is now down
Fri Aug 12 16:07:17 2022 daemon.notice netifd: Interface 'wan6' is disabled
Fri Aug 12 16:07:17 2022 daemon.notice netifd: Interface 'wan' is disabled
Fri Aug 12 16:07:17 2022 daemon.notice netifd: Interface 'wan' is enabled
Fri Aug 12 16:09:06 2022 kern.warn kernel: [84478.677244] enter showtime
Fri Aug 12 16:09:06 2022 kern.info kernel: [84478.678843] IPv6: ADDRCONF(NETDEV_CHANGE): dsl0: link becomes ready
Fri Aug 12 16:09:06 2022 daemon.notice netifd: Network device 'dsl0' link is up
Fri Aug 12 16:09:06 2022 daemon.notice netifd: VLAN 'dsl0.101' link is up
Fri Aug 12 16:09:06 2022 daemon.notice netifd: Interface 'wan' has link connectivity
Fri Aug 12 16:09:06 2022 daemon.notice netifd: Interface 'wan' is setting up now
Fri Aug 12 16:09:06 2022 kern.warn kernel: [84478.695896] enter showtime
Fri Aug 12 16:09:06 2022 daemon.err insmod: module is already loaded - slhc
Fri Aug 12 16:09:06 2022 daemon.err insmod: module is already loaded - ppp_generic
Fri Aug 12 16:09:06 2022 daemon.err insmod: module is already loaded - pppox
Fri Aug 12 16:09:06 2022 daemon.err insmod: module is already loaded - pppoe
Fri Aug 12 16:09:06 2022 daemon.info pppd[25779]: Plugin rp-pppoe.so loaded.
Fri Aug 12 16:09:06 2022 daemon.info pppd[25779]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
Fri Aug 12 16:09:06 2022 daemon.notice pppd[25779]: pppd 2.4.8 started by root, uid 0
Fri Aug 12 16:09:06 2022 daemon.err pppd[25779]: Interface dsl0.101 has MTU of 1492 -- should be at least 1500.
Fri Aug 12 16:09:06 2022 daemon.err pppd[25779]: This may cause serious connection problems.
Fri Aug 12 16:09:21 2022 daemon.warn pppd[25779]: Timeout waiting for PADO packets
Fri Aug 12 16:09:21 2022 daemon.err pppd[25779]: Unable to complete PPPoE Discovery
Fri Aug 12 16:09:21 2022 daemon.info pppd[25779]: Exit.