Plusnet fibre broadband does not cope with uploads and will disconnect you...

[#1]

This is my Cabinet.

Exchange MAIDENHEAD is served by Cabinet 35

The frustrating thing is that I haven't had any problems with BT infifinity for the last 4-5 years.

I had an email saying that a new router was its way..... news to me!

Featured Products	Downstream Line Rate(Mbps)		Upstream Line Rate(Mbps)		Downstream Range(Mbps)	WBC FTTC Availability Date	WBC SOGEA Availability Date	Left in Jumper
	High	Low	High	Low
VDSL Range A (Clean)	71.6	55	20	16.7	--	Available	--	--
VDSL Range B (Impacted)	54.5	27.4	17.9	7.8	--	Available	--	--
Featured Products	Downstream Line Rate(Mbps)		Upstream Line Rate(Mbps)		Downstream Range(Mbps)	WBC FTTP Availability Date		Left in Jumper
FTTP on Demand	330		30		--	Available	--	--
ADSL Products	Downstream Line Rate(Mbps)		Upstream Line Rate(Mbps)		Downstream Range(Mbps)	Availability Date		Left in Jumper
WBC ADSL 2+	Up to 8.5		--		6 to 11.5	Available	--	--
WBC ADSL 2+ Annex M	Up to 8.5		Up to 1		6 to 11.5	Available	--	--
ADSL Max	Up to 6		--		5 to 8	Available	--	--
WBC Fixed Rate	2		--		--	Available	--	--
Fixed Rate	2		--		--	Available	--	--
Other Offerings						Availability Date
VDSL Multicast	--		--		--	Available	--	--
ADSL Multicast	--		--		--	Available	--	--

[#2]

Maidenhead 35 is a Huawei cabinet, same as mine, so that eliminates cabinet type as a factor. It was a bit of a long shot anyway. About all we are left with, is gateway.

[#3]

We have another user reporting the same problem also using a Hub One and on the 40/2 package and ... wait for it ... he's on psb-ir01

[#4]

I think we have sufficient evidence now to report to PlusNet that there is a definite, reproducible problem. Users with the combination of

• Plus One Modem
• 40/2 package
• Gateway psb-ir01

who try to upload large files get disconnected. Is it the general feeling that it is time to escalate this?

[#5]

I would say 'yes'.

I would like to thank all of you that worked to look for the common factors - and put time into this. Plus net did email me to say to they are sending me a replacement router to see if that makes any difference FYI.

[#6]

---

@uk144 wrote:

Plus net did email me to say to they are sending me a replacement router to see if that makes any difference FYI.

---

That's great. If it works and fixes the problem, then everyone else knows what to do; ask for a new modem. If it doesn't then we know what to do next anyway - report a generic problem with the gateway.

[#7]

---

@bobminors wrote:

I think we have sufficient evidence now to report to PlusNet that there is a definite, reproducible problem. Users with the combination of

• Plus One Modem
• 40/2 package
• Gateway psb-ir01

who try to upload large files get disconnected. Is it the general feeling that it is time to escalate this?

---

Has it been confirmed that this definitely doesn't happen on any of the other IR's? Is it specific to psb/Southbank?

[#8]

---

@bobpullen wrote:

Has it been confirmed that this definitely doesn't happen on any of the other IR's? Is it specific to psb/Southbank?

---

We can't honestly tell, with only three cases that all happened to be on the same IR. Is it possible to transfer one of them onto a different IR, so that he can see if the problem goes away? I'm on the old network and can't reproduce the fault myself. Can you transfer me to the new network, so that I can run some tests? I don't know how it works with transferring users. Is it a big thing, or as simple as throwing a switch?

[#9]

I honestly can't see how the IR would be the culprit. It doesn't send PADT packets and is not responsible for authentication.

I can modify a line here in the office to 40/2 and try replicating the issue with a Hub One but it's quite a lot of effort, so want to be sure there are definite commonalities before I do.

Having said that, any testing I do from here would be via Colindale.

Transferring you would probably be possible but it's not going to be a like for like test unless you have a dynamic IP. It would also take a couple of weeks at best.

It's not practical to change individual customer's routing, especially not when there are only three customers citing problems.

[#10]

---

@bobpullen wrote:

I honestly can't see how the IR would be the culprit. It doesn't send PADT packets and is not responsible for authentication.

I don't know either. I'm just going by the phenomenology and trying to look for common factors. Is it true that the new network handles bandwidth profiles differently, or am I imagining having read that somewhere? Even so, I'm clutching at straws.

I can modify a line here in the office to 40/2 and try replicating the issue with a Hub One but it's quite a lot of effort, so want to be sure there are definite commonalities before I do.

Before you do that, we really need more data. Perhaps we could find some 40/2 Hub One users who are already on the new network and ask them to test uploading and tell us which gateway they are on.

It's not practical to change individual customer's routing, especially not when there are only three customers citing problems.

Understood, I guessed it might be non-trivial but though it was worth asking.

The other way to get more data would be a sort of mini-survey. I think what I will do next is to post a new thread here as an open call to help gather data from more users.

---

Thanks for picking this up. It's still possible that when the OP gets his new router it will solve the problem, in which case it's a no-brainer anyway.

[#11]

The only other thing for the people experiencing the problem to do, besides waiting for the replacement Hub One to arrive, or if the replacement doesn't solve the problem, would be to buy themselves a different VDSL2 modem router.

The upload bandwidth might not even matter, it's just easier to saturate for longer if the upload bandwidth is only 2Mb.

[#12]

---

@ejs wrote:

The upload bandwidth might not even matter, it's just easier to saturate for longer if the upload bandwidth is only 2Mb.

---

That's a fair point. If you are on 80/20, you would need to be uploading, say, a 5GB file to work the upload for the same number of minutes. How often do people do that, I wonder?

[#13]

Am I missing something, but has anyone tried the same tests with another application or end point? It seems to me another possibility is the end to end control of the upload is not being controlled, either by the application or the end point.

[#14]

Well I swapped over the new router. I didnt get any disconnects when I was in the computer(s). Not disconnects at all (for 10 hours)  However when i checked the logs I noticed it has rebooted. I think a similar thing in the logs....

01:06:27, 22 Oct.(61663.910000) PPP LCP Send Termination Request [User request]
00:08:54, 22 Oct.( 138.270000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
00:08:54, 22 Oct.( 138.260000) CWMP: Session start now. Event code(s): '1 BOOT,M Reboot,4 VALUE CHANGE'
00:07:57, 22 Oct.( 81.460000) CWMP: session closed due to error: Could not resolve host
00:07:57, 22 Oct.( 81.440000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
00:07:57, 22 Oct.( 81.430000) CWMP: Session start now. Event code(s): '1 BOOT,M Reboot,4 VALUE CHANGE'
00:07:27, 22 Oct.( 51.190000) CWMP: session closed due to error: Could not resolve host
00:07:22, 22 Oct.( 45.550000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
00:07:22, 22 Oct.( 45.540000) CWMP: Session start now. Event code(s): '1 BOOT,M Reboot,4 VALUE CHANGE'
00:07:21, 22 Oct.( 45.310000) CWMP: Initializing transaction for event code 1 BOOT
01:06:26, 22 Oct.(61662.770000) CWMP: session completed successfully
01:06:26, 22 Oct.(61662.780000) The system is going DOWN for reboot.
01:06:25, 22 Oct.(61661.580000) CWMP: HTTP authentication success from https://dbtpnhdm.bt.mo
01:06:22, 22 Oct.(61658.870000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
01:06:22, 22 Oct.(61658.860000) CWMP: Session start now. Event code(s): '6 CONNECTION REQUEST,4 VALUE CHANGE'
01:06:22, 22 Oct.(61658.620000) CWMP: Initializing transaction for event code 6 CONNECTION REQUEST
00:08:58, 22 Oct.( 141.990000) NTP synchronization success!
00:08:54, 22 Oct.( 138.010000) NTP synchronization start

[#15]

---

@Mustrum wrote:

Am I missing something, but has anyone tried the same tests with another application or end point? It seems to me another possibility is the end to end control of the upload is not being controlled, either by the application or the end point.

---

Yes, you are missing something. Uploading as much as you like as fast as you can, should not cause the PPP session to disconnect. It does not matter how controlled or uncontrolled the upload is (the TCP connection will ensure all the data arrives at the other end, so there will always be some degree of control, it would be rather unusual to do a bulk upload using UDP).