Will Upgrade to BT Smart Hub 6 solve PPP LCP termination request problem?

[#1]

I have had intermittent router disconnects with "PPP LCP send termination request [user request]" logs. I understand this is a widespread issue that has been resolved by exchanging the Plusnet Hub for another router.

Is it known that changing to the BT Smart Hub 6 has resolved this for others? Or otherwise, has anyone a suggestion for a router that has solved this issue? Many thanks.

[#2]

I've seen users with similar issues indicate they've switched to Fritzbox 7530's.  I am considering the same.  Will these units work with fibre?  Looking at the docs, and my limited understanding, I'm finding it hard to get a conclusive answer.

[#3]

@Paulwm The Fritz!Box works perfectly well with Fibre or ADSL - it is standard issue for my ISP.

[#4]

@Paulwm - there is no recognised issue I'm aware of with the later Hub One firmwares that would lead to what you're describing.

What is important, are the log entries either side of the LCP termination event. More often than not, these events are a consequence of the physical broadband signal dropping.

A different router with a different xDSL chipset may perform better depending on your circumstances, but it's not guaranteed. 

[#5]

Thanks @bobpullen  - interesting to know.  I have requested a firmware upgrade.

If you can make anything of the following logs from Sat 19 Jun at around 1828 when I last noticed a disconnect that would be amazing:

23:15:27, 19 Jun.	ath10: STA fe:c6:4b:6e:83:51 IEEE 802.11: Client associated
23:15:27, 19 Jun.	ath10: STA 58:d9:c3:6e:83:51 IEEE 802.11: Client disassociated
23:03:14, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client associated
23:03:14, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client disassociated
22:00:53, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client associated
22:00:50, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: WiFi registration failed
21:54:09, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client associated
21:46:29, 19 Jun.	ath10: STA fe:c6:4b:73:bd:f2 IEEE 802.11: Client associated
21:33:15, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client associated
21:30:50, 19 Jun.	ath00: STA 58:d9:c3:6e:83:51 IEEE 802.11: Client disassociated
21:30:50, 19 Jun.	ath00: STA 58:d9:c3:6e:83:51 IEEE 802.11: WiFi registration failed
21:29:07, 19 Jun.	ath10: STA 58:d9:c3:6e:83:51 IEEE 802.11: Client associated
21:27:28, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client associated
21:26:17, 19 Jun.	ath10: STA fe:c6:4b:6e:83:51 IEEE 802.11: Client disassociated
21:21:15, 19 Jun.	ath00: STA 58:d9:c3:6e:83:51 IEEE 802.11: Client associated
21:16:12, 19 Jun.	ath10: STA fe:c6:4b:6e:83:51 IEEE 802.11: Client associated
21:16:12, 19 Jun.	ath10: STA fe:c6:4b:6e:83:51 IEEE 802.11: Client disassociated
20:51:12, 19 Jun.	(2268781.070000) Wire Lan Port 1 up
20:51:09, 19 Jun.	(2268778.070000) Wire Lan Port 1 down
20:43:28, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client associated
20:38:51, 19 Jun.	ath10: STA fe:c6:4b:73:bd:f2 IEEE 802.11: Client disassociated
20:37:42, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client associated
20:37:25, 19 Jun.	ath10: STA fe:c6:4b:6e:83:51 IEEE 802.11: Client associated
20:30:34, 19 Jun.	(2267542.090000) Admin login successful by 192.168.1.69 on HTTP
20:30:21, 19 Jun.	(2267529.900000) Admin login FAILED by 192.168.1.69 on HTTP
20:30:05, 19 Jun.	(2267513.320000) New GUI session from IP 192.168.1.69
20:25:06, 19 Jun.	(2267214.100000) Wire Lan Port 1 up
20:24:56, 19 Jun.	(2267204.860000) Wire Lan Port 1 down
20:22:12, 19 Jun.	(2267040.560000) Admin login successful by 192.168.1.71 on HTTP
20:21:13, 19 Jun.	(2266982.000000) New GUI session from IP 192.168.1.71
19:04:46, 19 Jun.	ath10: STA d8:61:62:2d:ac:05 IEEE 802.11: Client associated
18:31:49, 19 Jun.	ath10: STA fe:c6:4b:73:bd:f2 IEEE 802.11: Client associated
18:30:37, 19 Jun.	(2260345.990000) CWMP: session closed due to error: Timeout
18:30:22, 19 Jun.	ath10: STA fe:c6:4b:73:bd:f2 IEEE 802.11: Client disassociated
18:30:07, 19 Jun.	(2260315.960000) CWMP: HTTP authentication success from https://pbthdm.bt.mo
18:30:01, 19 Jun.	(2260309.330000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
18:30:01, 19 Jun.	(2260309.320000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
18:29:59, 19 Jun.	(2260307.510000) WAN operating mode is VDSL
18:29:59, 19 Jun.	(2260307.510000) Last WAN operating mode was VDSL
18:29:58, 19 Jun.	(2260306.110000) PPP IPCP Receive Configuration ACK
18:29:58, 19 Jun.	(2260306.110000) PPP IPCP Send Configuration Request
18:29:58, 19 Jun.	(2260306.100000) PPP IPCP Receive Configuration NAK
18:29:58, 19 Jun.	(2260306.100000) PPP IPCP Send Configuration ACK
18:29:58, 19 Jun.	(2260306.090000) PPP IPCP Receive Configuration Request
18:29:57, 19 Jun.	(2260305.820000) PPP IPCP Send Configuration Request
18:29:56, 19 Jun.	(2260304.600000) PPPoE is up -​ Down Rate=76708Kbps, Up Rate=12642Kbps; SNR Margin Down=3.1dB, Up=6.1dB
18:29:56, 19 Jun.	(2260304.590000) CHAP authentication successful
18:29:56, 19 Jun.	(2260304.540000) CHAP Receive Challenge
18:29:56, 19 Jun.	(2260304.540000) Starting CHAP authentication with peer
18:29:56, 19 Jun.	(2260304.530000) PPP LCP Receive Configuration ACK
18:29:56, 19 Jun.	(2260304.530000) PPP LCP Send Configuration Request
18:29:56, 19 Jun.	(2260304.520000) PPP LCP Receive Configuration Reject
18:29:56, 19 Jun.	(2260304.520000) PPP LCP Send Configuration ACK
18:29:56, 19 Jun.	(2260304.510000) PPP LCP Receive Configuration Request
18:29:56, 19 Jun.	(2260304.510000) PPP LCP Send Configuration Request
18:29:11, 19 Jun.	(2260259.510000) CWMP: session closed due to error: Could not resolve host
18:29:08, 19 Jun.	(2260257.050000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
18:29:08, 19 Jun.	(2260257.050000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
18:29:05, 19 Jun.	(2260254.080000) PTM over DSL is up
18:28:34, 19 Jun.	(2260222.780000) CWMP: session closed due to error: Could not resolve host
18:28:34, 19 Jun.	(2260222.760000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
18:28:34, 19 Jun.	(2260222.750000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
18:28:34, 19 Jun.	(2260222.460000) CWMP: Initializing transaction for event code 4 VALUE CHANGE
18:28:32, 19 Jun.	(2260220.600000) PTM over DSL is down after 2524 minutes uptime
18:28:32, 19 Jun.	(2260220.590000) PPPoE is down after 2523 minutes uptime [Waiting for Underlying Connection (WAN Ethernet 7 -​ Down)]
18:28:29, 19 Jun.	(2260217.760000) PPP LCP Send Termination Request [User request]
17:52:00, 19 Jun.	ath10: STA fe:c6:4b:73:bd:f2 IEEE 802.11: Client associated
17:45:59, 19 Jun.	ath10: STA fe:c6:4b:73:bd:f2 IEEE 802.11: Client disassociated
17:04:08, 19 Jun.	(2255156.790000) Wire Lan Port 1 up
17:03:59, 19 Jun.	(2255147.790000) Wire Lan Port 1 down
17:03:44, 19 Jun.	(2255132.790000) Wire Lan Port 1 up
17:03:41, 19 Jun.	(2255129.790000) Wire Lan Port 1 down

Moderator's note by Mike (Mav): Two duplicate posts released from Spam Filter and subsequently removed.

[#6]

This is the key entry:-

18:28:32, 19 Jun.	(2260220.600000) PTM over DSL is down after 2524 minutes uptime

Indicates that the broadband signal was lost as expected.

This matches with the view presented by our supplier systems (blue line shows disconnection events):-

The Orange line shows that your line is operating with little room for noise interference (looks to be running with a 3-4dB noise margin). There might be some benefit in us moving you to a more stable line management profile to try and force that up to something more sensible like 6dB.

[#7]

Thanks @bobpullen .  How should I best go about getting this done?

[#8]

@Paulwm - consider it done.

It will take a day or two to come into effect.

[#9]

Amazing!  Thanks very much @bobpullen 

[#10]

@bobpullen I've just noticed another disconnect.  Are you able to tell me whether the change you mentioned is in effect now?  Here are the logs for the disconnect that occurred at 1118 (1018 GMT) just now.

10:21:26, 28 Jun.	IN: BLOCK [16] Remote administration (TCP [199.19.224.201]:55627-​>[51.7.28.75]:80 on ppp3)
10:20:29, 28 Jun.	(3008527.660000) CWMP: session closed due to error: Timeout
10:19:59, 28 Jun.	(3008497.440000) CWMP: HTTP authentication success from https://pbthdm.bt.mo
10:19:56, 28 Jun.	(3008494.230000) Admin login successful by 192.168.1.82 on HTTP
10:19:50, 28 Jun.	(3008488.220000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
10:19:49, 28 Jun.	(3008488.210000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
10:19:47, 28 Jun.	(3008485.790000) WAN operating mode is VDSL
10:19:47, 28 Jun.	(3008485.790000) Last WAN operating mode was VDSL
10:19:45, 28 Jun.	(3008483.970000) PPP IPCP Receive Configuration ACK
10:19:45, 28 Jun.	(3008483.960000) PPP IPCP Send Configuration Request
10:19:45, 28 Jun.	(3008483.950000) PPP IPCP Receive Configuration NAK
10:19:45, 28 Jun.	(3008483.950000) PPP IPCP Send Configuration ACK
10:19:45, 28 Jun.	(3008483.940000) PPP IPCP Receive Configuration Request
10:19:45, 28 Jun.	(3008483.940000) PPP IPCP Send Configuration Request
10:19:44, 28 Jun.	(3008482.320000) PPPoE is up -​ Down Rate=76434Kbps, Up Rate=13549Kbps; SNR Margin Down=3.1dB, Up=6.0dB
10:19:44, 28 Jun.	(3008482.300000) CHAP authentication successful
10:19:44, 28 Jun.	(3008482.240000) CHAP Receive Challenge
10:19:44, 28 Jun.	(3008482.240000) Starting CHAP authentication with peer
10:19:44, 28 Jun.	(3008482.240000) PPP LCP Receive Configuration ACK
10:19:44, 28 Jun.	(3008482.230000) PPP LCP Send Configuration Request
10:19:44, 28 Jun.	(3008482.230000) PPP LCP Receive Configuration Reject
10:19:44, 28 Jun.	(3008482.230000) PPP LCP Send Configuration ACK
10:19:44, 28 Jun.	(3008482.220000) PPP LCP Receive Configuration Request
10:19:44, 28 Jun.	(3008482.220000) PPP LCP Send Configuration Request
10:19:22, 28 Jun.	(3008460.950000) New GUI session from IP 192.168.1.82
10:18:59, 28 Jun.	(3008437.580000) CWMP: session closed due to error: Could not resolve host
10:18:56, 28 Jun.	(3008434.700000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
10:18:56, 28 Jun.	(3008434.700000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
10:18:52, 28 Jun.	(3008431.010000) PTM over DSL is up
10:18:27, 28 Jun.	ath10: STA fe:c6:4b:73:bd:f2 IEEE 802.11: Client associated
10:18:23, 28 Jun.	(3008401.330000) CWMP: session closed due to error: Could not resolve host
10:18:23, 28 Jun.	(3008401.300000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
10:18:23, 28 Jun.	(3008401.300000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
10:18:22, 28 Jun.	(3008400.970000) CWMP: Initializing transaction for event code 4 VALUE CHANGE
10:18:20, 28 Jun.	(3008398.750000) PTM over DSL is down after 1953 minutes uptime
10:18:20, 28 Jun.	(3008398.750000) PPPoE is down after 1952 minutes uptime [Waiting for Underlying Connection (WAN Ethernet 7 -​ Down)]
10:18:17, 28 Jun.	(3008395.610000) PPP LCP Send Termination Request [User request]
10:17:04, 28 Jun.	IN: BLOCK [16] Remote administration (TCP [139.162.205.179]:49714-​>[51.7.28.75]:8080 on ppp3)
10:17:00, 28 Jun.	(3008319.140000) Device disconnected: Hostname: android-​dhcp-​9-​fe-​c6-​4b-​73-​bd-​f2 IP: 192.168.1.71 MAC: fe:c6:4b:73:bd:f2
10:17:00, 28 Jun.	ath10: STA fe:c6:4b:73:bd:f2 IEEE 802.11: Client disassociated
10:16:02, 28 Jun.	OUT: BLOCK [7] ICMP replay (ICMP type 3 code 1 51.7.28.75-​>35.186.224.47 on ppp3)
10:16:00, 28 Jun.	BLOCKED 3 more packets (because of ICMP replay)

[#11]

Yes, change is in effect - however your downstream noise margin is still very low. It might take some time for things to readjust. Ideally, you'd hope for this figure to increase over time:-

SNR Margin Down=3.1dB

[#12]

Many thanks @bobpullen .  Over what sort of time frame should I wait for improvement before seeking another solution?  The more I think about it, the more I have a sense that this was something that was done a couple of years ago when I reported the same issue.  Is this a fundamental line problem or would changing provider make any difference?

[#13]

You're at the mercy of Openreach's dynamic line management platforms, and for some reason - it is establishing that your line is stable enough to run with a reduced noise margin overhead of 3dB. This is despite the fact that your line is dropping occasionally.

I have moved you to a management profile that favours stability over speed to a degree, but it's still down to the Wholesale systems to start increasing the target margin back towards the default of 6dB (which would marginally decrease your headline speed).

Problem is, with your line typically dropping less than once a day, it might not be enough to breach any thresholds and trigger a change.

As for next steps:-

• Raise a fault ticket for investigation - Will require some patience/persistence and likely to result in an engineer visit and may incur a charge if they don't find anything wrong with the physical line
• We move you to the most aggressive DLM policy - Not guaranteed to work but potentially worth a try
• You try a different router - As mentioned previously, different DSL chipsets can be found to be more resilient to certain noise/error conditions. The Hub One has an Intel/Lantiq chipset. You could look to source something with a Broadcom chipset instead (read: any of the recent BT Smarthubs). Again, no guarantees here
• Somebody like @Gandalf may know of a back office process that allows us to request your target margin is fixed to 6dB. I'm not particularly close to the current processes, so I'm unsure whether or not this is an option.

Whether or not you'd see a similar issue on another ISP is again - a bit of a guessing game I'm afraid 😕

[#14]

@bobpullen 

Do you think a reboot of the hub causing the DSL to be dropped then reconnected would help kick the DLM into life?

@Paulwm 

If you go down the BT Smarthub route then they are cheap from auction sites. See here for link to settings https://community.plus.net/t5/My-Router/Using-A-BT-Smarthub-An-Update/m-p/1795292#M24601

[#15]

@bobpullen, Unfortunately we can't fix a target margin like we can (Sort of) on ADSL where we'd set a custom threshold to tell DLM not to make positive changes/lower the target margin to 3dB unless there are zero errors.

Historically we could email a team within BT to fix a target margin, but that was only ever on ADSL.

@Paulwm, As long as we can see a problem, the connection dropping regularly, we shouldn't charge if the engineer finds no fault. We'd more than likely arrange another engineer, if there's still a problem.

I'd recommend though to cover all checks as there may be a charge if the fault's with internal equipment or wiring. 

As well as checking/replacing the router as it's a good few years old now so it may potentially have developed a fault, I'd recommend plugging your router into the test socket as explained Here making sure there's no extension cabling between the telephone socket and your router to rule out any internal wiring issues.

I'd see how things go on the new stability profile Bob's put you on first though, it could take around 7 to 14 days for this to fully take effect. If your connection's still dropping, try the test socket and another router.

Failing that, faults.plus.net I'd say would be the way to go, so we can arrange an engineer visit to investigate further. 

Feel free to keep us posted here on how it goes.