WAN Connection drops frequently after contract renewal

[#1]

Hi

Since renewing my contract on 8th May my WAN connection has been dropping frequently - at least once a day.  Sometimes it stays up for 16+ hours, sometimes for only 4 hours.  This happens day and night, which is incredibly inconvenient as I'm working from home and I need a reliable connection.

Prior to the contract change, I had no problems whatsoever.  The new contract is for 24 months but I can't put up with two years of this!

Any advice, please, anyone?  Some log entries from the last known drop/reconnect are below.

Thanks.

IX

08:35:09 12 May. admin login success from 192.168.1.196
01:44:20 12 May. PPP IPV6CP Send Configuration Request
01:44:18 12 May. NTP synchronization success
01:44:18 12 May. NTP Server: ntp.plus.net
01:44:16 12 May. PPP IPV6CP Send Configuration Request
01:44:13 12 May. PPP IPV6CP Send Configuration Request
01:44:10 12 May. CWMP: HDM socket closed successfully.
01:44:10 12 May. PPP IPV6CP Send Configuration Request
01:44:10 12 May. CWMP: HTTP authentication success from pbthdm.x.x.x
01:44:10 12 May. CWMP: HDM socket opened successfully.
01:44:10 12 May. CWMP: session completed successfully
01:44:10 12 May. CWMP: HDM socket closed successfully.
01:44:10 12 May. CWMP: HTTP authentication success from pbthdm.x.x.x
01:44:10 12 May. CWMP: HDM socket opened successfully.
01:44:09 12 May. CWMP: HDM socket opened successfully.
01:44:09 12 May. CWMP: Server URL: https://pbthdm.x.x.x; Connecting as user: ACS username
01:44:09 12 May. CWMP: Session start now
01:44:09 12 May. CWMP: Initializing transaction for event code 4 VALUE CHANGE
01:44:07 12 May. PPP IPV6CP Send Configuration Request
01:44:06 12 May. SIP WAN UP
01:44:05 12 May. SIP WAN DOWN
01:44:05 12 May. NTP synchronization start
01:44:05 12 May. UPnP is enabled
01:44:05 12 May. WAN Sensing Auto sensing Complete
01:44:04 12 May. WAN Sensing Auto sensing Running
01:44:04 12 May. Success - secondary DNS servers
01:44:04 12 May. Success - primary DNS servers
01:44:04 12 May. WAN connection WAN2_INTERNET_PTM connected
01:44:04 12 May. PPP: IPCP up
01:44:04 12 May. PPP IPCP Receive Configuration ACK
01:44:04 12 May. PPP IPCP Send Configuration Request
01:44:04 12 May. PPP IPCP Receive Configuration NAK
01:44:04 12 May. PPP IPCP Send Configuration ACK
01:44:04 12 May. PPP IPCP Receive Configuration Request
01:44:04 12 May. PPP IPV6CP Send Configuration Request
01:44:04 12 May. PPP IPCP Send Configuration Request
01:44:04 12 May. PPP: CHAP authentication succeeded
01:44:04 12 May. PPP CHAP Receive success : authentication successful
01:44:04 12 May. PPP CHAP Receive Challenge
01:44:04 12 May. PPP: LCP up
01:44:04 12 May. PPP LCP Receive Configuration ACK
01:44:03 12 May. PPP LCP Send Configuration ACK
01:44:03 12 May. PPP LCP Receive Configuration Request
01:44:03 12 May. PPP LCP Send Configuration Request
01:44:03 12 May. PPP: Received PADS
01:44:03 12 May. PPP: Sending PADR
01:44:03 12 May. PPP: Received PADO
01:44:03 12 May. PPP: Sending PADI
01:43:58 12 May. PPP: Sending PADI
01:43:53 12 May. PPP: Sending PADI
01:43:48 12 May. PPP: Sending PADI
01:43:45 12 May. DSL Link Up: Down Rate=79999kbps
01:43:43 12 May. PPP: Sending PADI
01:43:38 12 May. PPP: Starting PPP daemon
01:43:37 12 May. WAN Auto-sensing detected port DSL WAN
01:43:09 12 May. SIP WAN DOWN
01:43:08 12 May. WAN Sensing Auto sensing Complete
01:43:08 12 May. WAN Sensing Auto sensing Running
01:43:08 12 May. WAN connection WAN2_INTERNET_PTM disconnected.[ERROR_NO_CARRIER]
01:43:06 12 May. PPP: Stopped PPP daemon(0
01:43:06 12 May. PPP LCP Send Termination Request (User request)
01:43:06 12 May. PPP: IPCP down
01:43:06 12 May. PPP: LCP down
01:43:06 12 May. DoS(Port Scanning): IN=ppp1 OUT= MAC= src=1.34.85.243 DST=51.9.245.198 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=33612 DF PROTO=TCP SPT=19189 DPT=50960 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=28471 MARK=0x8000000
01:43:06 12 May. DoS(Spoofing): IN=ppp1 OUT= MAC= src=1.34.85.243 DST=51.9.245.198 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=33612 DF PROTO=TCP SPT=19189 DPT=50960 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=28471 MARK=0x8000000
01:43:06 12 May. DoS(Spoofing): IN=ppp1 OUT= MAC= src=1.34.85.243 DST=51.9.245.198 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=33612 DF PROTO=TCP SPT=19189 DPT=50960 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=28471 MARK=0x8000000
01:43:06 12 May. DSL Link Down: duration was 19670 seconds

[#2]

Hello,

I have a similar issue, regular drops and only a router restart seems to fix it. Did you find a resolution?

I've had two replacement Hub 2 routers but it's made no difference. I've even bought a new tp-link router, connected it to the WAN port and disabled the wifi on the Plus hub to offload the wireless processing (customer support said I had too many devices @ 26 - really ???) to see if this makes a difference, but it's still the same.

It must be something on the line / exchange end but Plusnet have tested my connection (when it's working) and it's obviously fine. 

Cheers. 

TGG.

[#3]

Hi @Ix thank you for taking the time to contact us, I'm sorry to hear of the issues with the connection. 

I'm keen to look into this further, can you please DM me your account username so that I can take a look. 

@tgg Thank you for your time on call this afternoon, as discussed this has now been raised with Openreach. 

[#4]

Hi Tina,

Many thanks for your call just now I look forward to tomorrow when hopefully the Openreach engineer will find and fix my issue.

I'll update this thread with the outcome.

Many thanks.

TGG.

[#5]

Hi.

Thanks for your reply,  After I posted the initial message, things look to have settled down a bit. The connection has now been stable for over three days.

[#6]

Coincidences are always possible ... but given the reoccurrence of reports of issues (instability) following re-contract this is worth a closer look.

@tgg - you do not state explicitly that you recently re-contracted, only that you had a similar instability issue.  If yours is a re-contract can you please answer the questions below.

@Ix - can you please answer the following questions

1. Was this a re-contract like for like, that is FTTC + POTS services
2. A switch from FTTC + POTS to SOGEA
3. SOGEA renewal

(1) I would expect to be purely a commercial arrangement not requiring a change to the BT Wholesale configuration.

(2) would certainly require a change to the BT Wholesale and BT Openreach configuration, which would probably put the line back into training mode, hence the initial instability - have you noticed any change in speed?

(3) unsure if this would give rise to a service configuration change.

[#7]

My issue turned out to be a significant fault on the line which an Openreach engineer has fixed this morning. On his diagnostic tools, he was seeing over 7600 errors on my line in the last 48 hours. The fix was to connect the property to the unused copper lines. I'm now seeing only a few errors (which is normal) and my connection stability has improved significantly.

All thanks to the call from Tina yesterday after the post I had pout on here.

[#8]

@Townman - It was a switch from FTTC + POTS to SOGEA. 

The good news is that the connection has now been stable for over 7 days so perhaps it was just retraining itself.  (No change in speed that I've noticed.)

IX

[#9]

---

@Townman wrote:

Coincidences are always possible ... but given the reoccurrence of reports of issues (instability) following re-contract this is worth a closer look.

---

Rather than possible, I reckon that it is distrinctly probable.

Ignoring the probability of a fault occurring and just taking new faults. Based on a 24 month contract the probability of a random fault being detected on a fault free connection within:

! month of recontracting is: 1 in 24

! week of recontracting is: 1 in 104

! day of recontracting is: 1 in 730

Taking the total number of Plusnet customers reporting a problem, this happens a significant number of times to those who experience a fault.