Router resetting during file transfer

[#1]

The files are being transferred vis VPN from a file server at work to my local drive.

I only noticed things weren't working as expected around the beginning of February.

I tried a transfer on new router before the firware was updated, which also failed.

[#2]

OK, thanks - that rules out the firmware then.

I'll take a more detailed look at your router when I get a second to see if there's anything in the detailed logs that provides any pointers.

If you go into your Windows VPN settings, are you able to share the detail under 'Advanced Settings'? (feel free to private message me if you're not comfortable sharing here)

[#3]

Hi Bob

Not sure what information you're after, but I very much doubt Windows 11 Advanced Options will tell you anything useful.

[#4]

It tells me that it differs to the native VPN conection on my own laptop that is using EAP authentication rather than the username and password you seem to be using.

Any proxy configuration?

[#5]

Hi Bob

No, there's no proxy.

I've tried a couple of times this morning to transfer some data, unsurprisingly without success.

If I'm parsing the logs correctly, it appears the router spontaneously disconnected:

First attempt

07:12:05, 17 Mar. (217184.620000) PPPoE is down after 285 minutes uptime [Disconnected]
07:12:02, 17 Mar. (217182.290000) PPP LCP Send Termination Request [PPPoE PADT received]

Second attempt

07:18:25, 17 Mar. (217565.260000) PPPoE is down after 5 minutes uptime [Disconnected]
07:18:23, 17 Mar. (217562.680000) PPP LCP Send Termination Request [PPPoE PADT received]

And the "PPPoE PADT received"  leads me to 

https://community.plus.net/t5/Fibre-Broadband/PPP-LCP-Send-Termination-Request-User-request/td-p/141...

And I'm guessing the fix that you were applying on a case-by-case basis is now baked into current firmware. 

On Tuesday evening I tried to get my venerable DrayTek Vigor 2820n working, but it wouldn't connect, despite appearing to have the correct settings.

[#6]

Yes, that was baked into the firmware and was related to upstream link saturation (which I asume this isn't if you are copying from VPN > local machine as the stress should be on the download). Perhaps worth checking the performance tab of the Windows Task Manager during a transfer to see what the upload/download rates look like?

I can see both of those disconections in the logs.

I can also confirm that the hub is not rebooting. The last boot event was on the 14th by the looks of things and the crash event log is also empty:-

Plusnet Hub One> crash timestamps
No recorded crash logs exist

I can also see that the disconnections are not accompanied with a physical resync/retrain, so the VDSL connection is staying up when these drops occur (last retrain was during early hours of this morning, around 2.30am).

I notice that your network devices are being assigned IP's in the 172.16.16.0/24 range. Is there a reason for this, and do you know what IP ranges your VPN network uses? Is there any reason you're unable to use the default 192.168.1.0/16 range. Would be interesting to see if this issue occurs with the router dishing out IPs from the default range.

Edit: I don't think that Draytek router has an integrated VDSL modem.

[#7]

Moderators Note

This topic has been moved from ADSL Broadband to My Router

[#8]

Hi Bob

My previous attempt at replying got sabotaged by having the post moved to a different forum while I was typing. Very helpful.

I disconnected everything from router and tried transferring yet, and it appears to behave itself.

Network traffic during transfer well within expected capabilites of a dveice with fourt gigabit ports.

Yes, it does look like the router no longer reboots after dropping connection which is, I suppose, some form of progress.

I was obliged to change default IP range so as not to conflict with work's.

I wasn't aware I was using a VDSL line, as there's no fibre here. But if that's what the modem needs to connect that would explain why it doesn't work. Guess I will need to invest in a new modem.

[#9]

---

@HsdItUp3m6qbgRJ wrote:

I disconnected everything from router and tried transferring yet, and it appears to behave itself.

Interesting. I wonder if the problem is easily replicated again with everything reconnected?

Network traffic during transfer well within expected capabilites of a dveice with fourt gigabit ports.

Yep, nowhere close to hitting the upstream limit. 

I was obliged to change default IP range so as not to conflict with work's.

Not my place to say really, but using a VPN IP subnet that overlaps with the majority of home users' local envionrments is pretty poor practice 😉

I wasn't aware I was using a VDSL line, as there's no fibre here. But if that's what the modem needs to connect that would explain why it doesn't work. Guess I will need to invest in a new modem.

Definitely looks to me like you're on FTTC/VDSL. Your downstream is around the 50mbps mark which is more than twice what's possible on an ADSL/full copper line.

Edit: One of these would do the trick if you want to obtain an external VDSL modem that will work with the Draytek.

[#10]

I've given it a whirl with everything connected and, miraculously, it transferred over 5GB before I stopped it.

Yes, having 192.168.x.x for a business network is an interesting choice.

I have ordered a DrayTek ADSL/VDSL modem, which should also be of use once FTTP arrives round here. Previous encounters with BT kit and their support are why I own third party routers.

[#11]

Tried again this morning.

07:15:34, 18 Mar. (303791.820000) PPPoE is down after 266 minutes uptime [Disconnected]
07:15:32, 18 Mar. (303789.500000) PPP LCP Send Termination Request [PPPoE PADT received]

So disconnecting everything and then reconnecting everything did not fix.

Third party modem should be arriving today, so will assess over the weekend.

[#12 · Accepted solution]

The DrayTek Vigor 130 that I purchased has performed flawlessy these past few weeks.

Today I had occasion to transfer 24GB from the office and it went without a hitch.

Therefore I conclude that not using the One Hub has resolved my issue.

[#13]

Thanks for sharing.

I can only theorise that something is taxing the Hub One sufficiently enough for it not to be able to handle LCP keepalives in a timely manner. It only takes a few response failures and a PADT would be issued by the remote server to tear the PPP session down.

What might be leading to this isn't easy to say though. Like the previous issue that was patched, I'd expect upload saturation to be a prime contender, but that doesn't seem the case this time round.

If there were an easy way for me to replicate the issue then I'd look into it in more detail. I don't think there is though 😕