Advice / Repeated Fibre Disconnects / New Issue

[#1]

As an IT professional with what I'd consider heavy and experienced usage, over the last 6 weeks I have started receiving regular disconnects varying between every 6 hours - 24 hours.  Since Plusnet support seem to be overloaded, giving here a try for advice/assistance.

I'm idly wondering if Plusnet/BT are purposefully cycling something every few hours due to Covid-19 usage patterns?

Reliable for: 4 months without incidents.

Router replaced since fault manifested: yes, occurs with old and new router (including cable/power).  Now utilising Plusnet One. Previously: Draytek 2860

Any internal wiring/property changes: no

Any internal wiring downstream from master: no

Any devices connected/phones connected: none - don't use POTS

Master socket used.

DSL splitter faceplate used, replacement already tried.

POTS line still has signal during outage. 

1. Product name:	Plusnet Hub
2. Serial number:	+081441+NQ92873995
3. Firmware version:	Software version 4.7.5.1.83.8.263 Last updated Unknown
4. Board version:	Plusnet Hub One
5. DSL uptime:	0 days, 00:14:22
6. Data rate:	17108 / 57057
7. Maximum data rate:	16915 / 70681
8. Noise margin:	6.0 / 5.9
9. Line attenuation:	22.5 / 18.7
10. Signal attenuation:	22.3 / 18.6

System log of last two disconnects/restarts: 

today:

17:29:56, 25 Apr.	( 29.730000) System up, firmware version: 4.7.5.1.83.8.263
17:29:53, 25 Apr.	( 25.870000) WPA2 mode selected
17:29:53, 25 Apr.	( 25.870000) WPS enabled
17:29:50, 25 Apr.	( 23.430000) WPA2 mode selected
17:29:50, 25 Apr.	( 23.430000) WPS enabled
17:29:41, 25 Apr.	( 14.570000) System start
17:29:41, 25 Apr.	( 14.570000) Boot reason: watchdog reset (cause: 0x2)
16:48:58, 25 Apr.	(177458.560000) Device disconnected: Hostname:

Last night:

20:54:39, 24 Apr.	(105801.140000) PTM over DSL is up
20:54:29, 24 Apr.	(105791.420000) CWMP: session closed due to error: Could not resolve host
20:54:29, 24 Apr.	(105791.400000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
20:54:29, 24 Apr.	(105791.400000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
20:53:58, 24 Apr.	(105761.020000) CWMP: session closed due to error: Could not resolve host
20:53:58, 24 Apr.	(105760.970000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
20:53:58, 24 Apr.	(105760.960000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
20:53:58, 24 Apr.	(105760.570000) CWMP: Initializing transaction for event code 4 VALUE CHANGE
20:53:56, 24 Apr.	(105758.750000) PTM over DSL is down after 1761 minutes uptime
20:53:56, 24 Apr.	(105758.750000) PPPoE is down after 1760 minutes uptime [Waiting for Underlying Connection (WAN Ethernet 7 -​ Down)]
20:53:53, 24 Apr.	(105756.010000) PPP LCP Send Termination Request [User request]

[#2]

Sounds similar to what I'm seeing, and someone else I noticed on Twitter. The timings feel too inconsistent to be a deliberate cycling, but something's definitely broken.

These were my router logs (Asus):

Apr 25 05:57:22 miniupnpd[713]: Failed to get IP for interface ppp0
Apr 25 05:58:13 pppd[384]: Timeout waiting for PADO packets
Apr 25 05:59:28 pppd[384]: Timeout waiting for PADO packets
Apr 25 05:59:28 miniupnpd[713]: Failed to get IP for interface ppp0
Apr 25 05:59:28 miniupnpd[713]: Failed to get IP for interface ppp0
Apr 25 05:59:28 miniupnpd[713]: Failed to get IP for interface ppp0
Apr 25 06:45:20 miniupnpd[1235]: Failed to get IP for interface ppp0
Apr 25 06:46:11 pppd[384]: Timeout waiting for PADO packets
Apr 25 06:47:26 pppd[384]: Timeout waiting for PADO packets
Apr 25 06:48:41 pppd[384]: Timeout waiting for PADO packets
Apr 25 06:48:42 miniupnpd[1235]: Failed to get IP for interface ppp0
Apr 25 06:48:42 miniupnpd[1235]: Failed to get IP for interface ppp0
Apr 25 06:48:42 miniupnpd[1235]: Failed to get IP for interface ppp0
Apr 25 06:50:23 miniupnpd[2442]: Failed to get IP for interface ppp0
Apr 25 06:51:15 pppd[384]: Timeout waiting for PADO packets
Apr 25 06:52:30 pppd[384]: Timeout waiting for PADO packets
Apr 25 06:53:05 miniupnpd[2442]: Failed to get IP for interface ppp0
Apr 25 06:53:05 miniupnpd[2442]: Failed to get IP for interface ppp0
Apr 25 06:53:05 miniupnpd[2442]: Failed to get IP for interface ppp0
Apr 25 07:26:50 miniupnpd[2706]: Failed to get IP for interface ppp0
Apr 25 07:27:41 pppd[384]: Timeout waiting for PADO packets
Apr 25 07:27:42 miniupnpd[2706]: Failed to get IP for interface ppp0
Apr 25 07:27:42 miniupnpd[2706]: Failed to get IP for interface ppp0
Apr 25 07:27:42 miniupnpd[2706]: Failed to get IP for interface ppp0
Apr 25 20:47:16 miniupnpd[3508]: Failed to get IP for interface ppp0
Apr 25 20:48:07 pppd[384]: Timeout waiting for PADO packets
Apr 25 20:49:22 pppd[384]: Timeout waiting for PADO packets
Apr 25 20:49:22 miniupnpd[3508]: Failed to get IP for interface ppp0
Apr 25 20:49:22 miniupnpd[3508]: Failed to get IP for interface ppp0
Apr 25 20:49:22 miniupnpd[3508]: Failed to get IP for interface ppp0

Then I turned on debug and a few minutes later it died again:

Apr 25 21:10:49 kernel: klogd started: BusyBox v1.25.1 (2018-04-08 14:04:33 EDT)
Apr 25 21:13:00 pppd[384]: Serial link appears to be disconnected.
Apr 25 21:13:00 pppd[384]: Connect time 23.7 minutes.
Apr 25 21:13:00 pppd[384]: Sent 25985509 bytes, received 1028008085 bytes.
Apr 25 21:13:00 miniupnpd[17356]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Apr 25 21:13:01 WAN_Connection: Fail to connect with some issues.
Apr 25 21:13:01 stop_nat_rules: apply the redirect_rules!
Apr 25 21:13:06 pppd[384]: Connection terminated.
Apr 25 21:13:06 pppd[384]: Sent PADT
Apr 25 21:13:06 pppd[384]: Modem hangup
Apr 25 21:13:51 pppd[384]: Timeout waiting for PADO packets

[#3]

Hi @, sorry to hear you're having broadband issues.

I've had a check of the connection and there definitely seems to be something out of place somewhere as we can see the disconnections from this end, although our tests aren't picking up exactly what's causing the issue so we will have to do some troubleshooting to start ruling things out.

I'd recommend starting with basic checks here

And if that doesn't help the next thing would be to rule your internal wiring out by plugging the connection into your test socket which is under the faceplate of your master socket and seeing if the drops stop. This rules out internal wiring, face plates and extension sockets as being the cause. How to locate the test socket and set your connection into it can be found here

If the problem still persists from here we will go down the route of raising a fault, please click here and let us know once you've done the checks and raised the fault so we can progress it for you.

[#4]

Thanks.  You've clearly not read any of my original post, as being an IT professional, all your "basic checks" have already been performed.   As has "And if that doesn't help the next thing would be to rule your internal wiring out by plugging the connection into your test socket which is under the faceplate of your master socket and seeing if the drops stop. This rules out internal wiring, face plates and extension sockets as being the cause. How to locate the test socket and set your connection into it can be found".

I'm testing a theory of my own, if still required, I'll raise a case.  

[#5]

Did you find a solution? I'm currently in the same boat, and despite the PN techs confidence that he had fixed the problem, he 100% has not.

Thanks.

[#6]

Nope, I wasn't convinced forcing a different DHCP lease address was going to make any difference.  Whilst the speed is good, I still get disconnects which range from once every 48h to once every 5 days.  This shouldn't happen on xDSL.

Plusnet are either:

1. not technically knowledgeable enough to do anything (other than follow their basic script).

2. don't give a **** enough to do anything about it.  Or just plain lazy.

xDSL connections should NOT reset periodically or have any form of drop outs unless there is something wrong - I've come across xDSL connections which have been up for months without incident at customer premises.  They've not even been bothered enough to send an OR engineer to check outside cabling or replace the cable pairs.  Since OpenReach split from BT, one of the repeated consumer problems is getting the ISP to even ENGAGE with OpenReach since they can't comprehend anything more than "well the computer says the line tests OK".

Terrible customer service (despite Plusnet=BT).  Nobody is interested. 

North Tyneside area is one of the first getting 'full fibre' so hopefully I can dump Plus.net soon as FFTP will at least provide higher levels of diagnostics to customer premises rather than just being 'fobbed off' constantly.  Or back to Virgin.  At least that way I get a stable reliable connection (unfortunately at double the cost). 

[#7]

I should also add, since then I've also replaced the router with a completely different make/model, and again replaced all cabling into the master socket, and new routers still show the same disconnect issues.  Wi-Fi strength has improved however :). 

[#8]

Thanks for contacting us about your Wi-Fi, check out the help and support page here https://community.plus.net/t5/Plusnet-Blogs/How-to-boost-your-wi-fi/ba-p/1450193

[#9]

Once again with the above response, a COMPLETE AND UTTER LACK OF UNDERSTANDING FROM PLUSNET.  

THIS ISSUE HAS 

NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING NOTHING 

to do with WIFI SIGNAL STRENGTH. 

[#10]

@BigBadBoss 

Please stop shouting its rude and against forum rules apparently.

As to your issue Routers can reset/reboot if there internal memory becomes full (logs etc), although not every 4 hours usually I have found 30 days or so.

Have you logged a fault ticket? asking for GEA test etc. Its really the best way to get your issue resolved. faults.plus.net

if necessary it could then be escalated after the initial investigation from the fault ticket.

[#11]

@BigBadBoss I cannot identify a drop in your connection for over 3 days, I'll attach your GEA test here now.

[#12]

@BigBadBoss I cannot find a Fault raised on your account, please follow this link and complete the checks etc so it can be raised to our Faults Team. 

https://faults.plus.net

GEA Test Detail
Circuit ID	NA	Service ID

Test Outcome	Pass
Test Outcome Code	GTC_FTTC_SERVICE_0000
Description	GEA service test completed and no fault found .
Main Fault Location	OK
Sync Status	In Sync
Downstream Speed	70.8 Mbps
Upstream Speed	20.0 Mbps
Appointment Required	N
Fault Report Advised	N
NTE Power Status	PowerOn
Voice Line Test Result	Pass
Radio Frequency Ingress	Not Detected
Repetitive Electrical Impulse Noise	Not Detected
Cross Talk	Not Detected
Estimated Line Length In Metres	577.8
Upstream Rate Assessment	Very Good
Downstream Rate Assessment	Very Good
Interference Pattern	Regular Interference Observed Daily
Service Impact	No Impact Observed
Interference Duration Longest Occurrence	;00:00to23:45
Interference Location	Customer Premise
Interference Observed In Days	14
Home Wiring Problem	Not Detected
Downstream Policing Discard Rate	0.0
Customer Traffic Level	Upstream and Downstream traffic detected
Technology	VDSL
DP Type	External
Profile Name	0.128M-74M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
Time Stamp	2020-09-13T19:00:00

[#13]

It's been reported at least 2/3 times now, and never goes anywhere, with the same "computer says connected" and fault closed.  While this is a domestic connection with no QoS, even being synced for a month would be an improvement.  It's annoyingly intermittent.

I take what you're saying about buffer overload, but I fear this unlikely after 4 different routers, including different manufacturers based on different architecture, with the same result.  Those of us managing IT in industry would also probably be aware of it was, supporting our hundreds of users who now WFH due to Covid-19.

Again, sync time appears to mismatch remote testing, as I can see that the last successfully sync of the latest router was:

DSL Uptime

2 days 15 hours 53 minutes 9 seconds

this would mean last disconnect was approx: September 24, 2020, 03:41:04 AM

Past logs also show loss of sync at:

31/07 0735 2845min uptime

02/08  0715 2859min uptime

03/08 0835 1518 uptime

13/08 0244 14048 uptime  

20/08 1529 10843 uptime

21/08 2100 1770 uptime

24/08 0648 3467 uptime

28/08 0600 801 uptime

(new brand router replaced  after that to test further theory of chipset being the problem)

I wonder:

Line card fault? (very unlikely)

Loose cabinet punch down? (unlikely as I'd expect the POTS to disconnect too, which I can't validate)

Bad pairs, water ingress or damage causing intermittent interference? 

There was a problem provisioning the original service - something still not setup correctly? 

No customer downstream wiring/extensions.

No connected POTS equipment. 

Previous xDSL connection with rival was stable, albeit at a lower sync rate.  So a specific issue to Plusnet or a newly fault since approx March when started happening?

Previous comments have been "you've got a strange public IP address".  Even if that's the case, the DHCP renew phase shouldn't cause a loss of sync.   To troubleshoot, perhaps a static address and monitor? 

[#14]

Thanks for your time on the phone @BigBadBoss, I have now updated your fault ticket and sent confirmation of your visit.

[#15]

---

@BigBadBoss wrote:

Whilst the speed is good, I still get disconnects which range from once every 48h to once every 5 days.  This shouldn't happen on xDSL.

xDSL connections should NOT reset periodically or have any form of drop outs unless there is something wrong - I've come across xDSL connections which have been up for months without incident at customer premises

---

I think one disconnection every 2 to 5 days is not enough to be considered a fault. Yes you might find some xDSL connections that stay connected for months, but an occasional disconnection is quite normal and to be expected really. So there seems to be no fault and therefore nothing to fix here.