Connection drop on uploads with new fibre router only on ethernet.

[#1]

I swapped to FTTC last week and every time I try uploading large files to soundcloud or youtube the connection will drop randomly and then resync. Im using the router plusnet sent me (hub one i believe).

Now this is the strange bit - I tested today using my laptop over wifi and it uploaded no problem. Then switched to my desktop over ETHERNET and it dropped within first few mins off upload starting.

Has anyone else had problems uploading large files using a wired Ethernet connection to router.

I suspect the router may have a small bug.

[#2]

@sekonz

Which package are you on? If it's the "Unlimited" rather than the "Extra", your upload will be limited to 2Mbps and it is not really intended for uploading large files quickly to the cloud.

[#3]

Nothing to do with speed. Yes Im on Unlimited 38MB/2MB package.

Its the router. Drops when uploading via a wired ethernet connection from pc. Wifi is fine.

Within the advanced settings page of router there are 2 tabs, one labelled "Internet", the other "Connection". The connection one never drops. Only the Internet one drops(router goes from blue to yellow light). Always reconnects straight away.

There is a bug in routers firmware or a fault with router, I reckon just a bug though as its totally fine uploading over wifi.

[#4]

Is there any newer firmware for this router?

[#5]

The problem may be with the software you are using to upload to the cloud if it is using UDP datagrams rather than TCP protocol.

When you connect over ethernet, it is going to try to shovel data up the line at 1000Mbs without checking if the data is getting through to the other end. But the router can only pass on 2Mbps of that. What is supposed to happen to the other 998Mbps? The router will try to buffer it but there's a limit to how much RAM it has inside it. Soon it will be full but it can't tell the uploading software to wait, because it isn't listening. So all the router can do is reset itself.

When you connect over wireless it's not so bad because wireless is a lot slower than ethernet.

It would be just the same with a different router.

The answer is to use cloud software that uses TCP rather than UDP. The difference is that TCP sends the data one packet at a time and waits for a reply before sending the next packet, so it doesn't matter however fast or slow the connection is.

Basically you are trying to stream data at 1000Mbps over a 2Mbps connection and it doesn't work.

[#6]

Im just using firefox to upload to a website. Youtube or soundcloud. Used to upload on 0.5MBps upload all the time no problem.

[#7]

---

@bobminors wrote:

Basically you are trying to stream data at 1000Mbps over a 2Mbps connection and it doesn't work.

---

To be honest, this is nonsense! 

The whole internet works on different size pipes, if you were on a 2MB DSL link and tried to download a file from a server that can send data faster you would always lose your conenction too?!

If the pipe is too small packets will get discarded and overflow, think of it like a hosepipe, only so much water goes in before it spills over but it wont burst the pipe.

Likewise, when someone DDoS's you and send more UDP data than your connection can handle your line doesn't drop, it will be full and nothing else comes down but it wont drop.

Most file uploads to cloud storage will use TCP (see https://en.wikipedia.org/wiki/TCP_congestion_control) but if they used UDP the application builds in control for congestion (e.g. watch a video stream that is bigger than your link).

The DSL link (if that is what is dropping?) is unrelated to what you do over the top of it.

If the DSL link is dropping when uploading over ethernet but fine on wifi it sounds like a hardware fault, if software then there would be a lot more people complaining on here!

[#8]

---

@sekonz wrote:

I swapped to FTTC last week and every time I try uploading large files to soundcloud or youtube the connection will drop randomly and then resync. Im using the router plusnet sent me (hub one i believe).

---

I'm not familiar with that router but does it providing any logging? If so see if there are any indicators what it might be. It sounds like it could be the PPP session failing under load, quite why I don't know but the logs may help if there are signs of the session being intentionally terminated (and renegotiated).

[#9]

---

@bobminors wrote:

The problem may be with the software you are using to upload to the cloud if it is using UDP datagrams rather than TCP protocol.

Most, if not all, file uploaders would use TCP as UDP would not give the reliability require for error-free transmission. For live video streaming UDP is a likely choice but it doesn't sound like that is what the OP is doing.

When you connect over ethernet, it is going to try to shovel data up the line at 1000Mbs without checking if the data is getting through to the other end. But the router can only pass on 2Mbps of that. What is supposed to happen to the other 998Mbps? The router will try to buffer it but there's a limit to how much RAM it has inside it. Soon it will be full but it can't tell the uploading software to wait, because it isn't listening. So all the router can do is reset itself.

That's not how it works (thankfully!). If/when the buffer fills up then any new packets received will simply be dropped and the router will carry on emptying the buffer on a first-in first-out basis. The sender will, in the case of TCP, detect the lack of acknowledgements from the receiver and resend any lost packets (adjusting the congestion window to reduce the chance of recurrence) whilst with UDP the lost packets will typically be left lost and not retransmitted if near-realtime delivery is more important than session integrity/completeness. In either case the router should absolutely not be resetting itself.

[#10]

Just logged into router. Started a download(over ethernet). Here are the logs-

06:26:06, 09 Oct.	(392127.940000) CWMP: session completed successfully
06:26:06, 09 Oct.	(392127.760000) CWMP: HTTP authentication success from https://dbtpnhdm.bt.mo
06:26:00, 09 Oct.	(392121.750000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
06:26:00, 09 Oct.	(392121.740000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
06:25:58, 09 Oct.	(392119.950000) WAN operating mode is VDSL
06:25:58, 09 Oct.	(392119.950000) Last WAN operating mode was VDSL
06:25:57, 09 Oct.	(392118.650000) PPP IPCP Receive Configuration ACK
06:25:57, 09 Oct.	(392118.640000) PPP IPCP Send Configuration Request
06:25:57, 09 Oct.	(392118.640000) PPP IPCP Receive Configuration NAK
06:25:57, 09 Oct.	(392118.620000) PPP IPCP Send Configuration ACK
06:25:57, 09 Oct.	(392118.620000) PPP IPCP Receive Configuration Request
06:25:57, 09 Oct.	(392118.620000) PPP IPCP Send Configuration Request
06:25:55, 09 Oct.	(392117.480000) PPPoE is up -​ Down Rate=27610Kbps, Up Rate=2001Kbps; SNR Margin Down=6.0dB, Up=24.3dB
06:25:55, 09 Oct.	(392117.470000) CHAP authentication successful
06:25:55, 09 Oct.	(392117.410000) CHAP Receive Challenge
06:25:55, 09 Oct.	(392117.410000) Starting CHAP authentication with peer
06:25:55, 09 Oct.	(392117.410000) PPP LCP Receive Configuration ACK
06:25:55, 09 Oct.	(392117.400000) PPP LCP Send Configuration Request
06:25:55, 09 Oct.	(392117.390000) PPP LCP Receive Configuration Reject
06:25:55, 09 Oct.	(392117.380000) PPP LCP Send Configuration ACK
06:25:55, 09 Oct.	(392117.380000) PPP LCP Receive Configuration Request
06:25:55, 09 Oct.	(392117.380000) PPP LCP Send Configuration Request
06:25:53, 09 Oct.	(392114.590000) CWMP: session closed due to error: Could not resolve host
06:25:53, 09 Oct.	(392114.580000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
06:25:53, 09 Oct.	(392114.570000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
06:25:22, 09 Oct.	(392084.310000) CWMP: session closed due to error: Could not resolve host
06:25:22, 09 Oct.	(392084.290000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
06:25:22, 09 Oct.	(392084.280000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
06:25:22, 09 Oct.	(392084.030000) CWMP: Initializing transaction for event code 4 VALUE CHANGE
06:25:21, 09 Oct.	(392083.050000) PPPoE is down after 2199 minutes uptime [Disconnected]
06:25:19, 09 Oct.	(392080.880000) PPP LCP Send Termination Request [PPPoE PADT received]
06:19:36, 09 Oct.	ath00: STA 00:4d:4a:29:f5:1a IEEE 802.11: WiFi registration failed
06:19:09, 09 Oct.	IN: BLOCK [16] Remote administration (UDP [184.105.139.67]:38438-​>[146.198.12.43]:161 on ppp3)
06:17:01, 09 Oct.	(391583.540000) Admin login successful by 192.168.1.65 on HTTP
06:16:58, 09 Oct.	(391580.350000) New GUI session from IP 192.168.1.65

[#11]

I defo think its a problem with the router PN sent me.

Ive raised a ticket and they say a bt engineer will be sent. TBH i think thats a waste of time as I think line is fine, only router got a bug or fault.

Wish I had another router to try.....

[#12]

Could try plugging a phone into the test post on the master socket. (Take faceplate off to see) to see if there is noise on the line.

sessions can drop out if there are lots of errors on the line, although would have thought it would have been the same for wifi and that doesnt cause the dropout. 

Hopefully plusnet can see errors hence sending an engineer out,..

[#13]

The log entries are normal, apart from this:

06:25:19, 09 Oct.

(392080.880000) PPP LCP Send Termination Request [PPPoE PADT received]

The router is not dropping the connection spontaneously, it is restarting the connection because the server is detecting something wrong and sending it a command to do so. We can't tell from the logs why the server is doing that, but excessive packet loss is one possibility.

[#14]

By Ethernet, is that an Ethernet cable directly between computer and router, or is this another one of those cases where Ethernet actually turns out to be powerline networking adapters?

[#15]

Ethernet cable directly to router. Tried 2 pcs 2 different leads.

Can stream and download and its never dropped. Soon as I upload (well maybe few mins into UL) it will drop.