TP-LINK TD-W8968 PPPoE disconnects d/ling large files FIXED

I am posting this is case other people see similar issues so maybe it can help.

I have had the TP-LINK ADSL2+ modem/router, and when on ADSL it worked great. Nice interface, lots of features including port forwarding -> DMZ, and a great range on the wireless signal (I only need to run it at 50% power!). All for a cheap price.


Recently I got FTTC, and the device has 3 'operating' modes, namely adsl modem/router, 3g modem router, and wireless router mode which allows config of WAN interface for PPPoE connection to a VDSL modem.


Now, everything works great, but on initial speed tests downloading a large file (512MB) I noticed once I got a PPPoE disconnect/reconnect ~ but didn't think no more about it.

Today, I needed to download latest Slackware 14.1 DVD.iso (2.4GB). But every time between 10%~30% of download, router dropped PPPoE connection and reconnected (I maybe tried 6 times, and each time disconnect happened).

Anyway, I got the file in the end by bypassing router, and plugging my laptop straight into the VDSL modem via eth0 uisng PPPoE protocol... downloaded perfectly. So that proves it was the TP-LINK disconnecting, not my line dropping out.

OK, after work today I tried various options, and finally found one that fixes this issue.

In network settings->advanced I set 'echo request interval' from 30 seconds to 5 seconds.

It now doesn't drop the connection on large file downloads

I have downloaded 1GB test file 3 times now with no issues whatsoever.

Before adjustment:

=============
Connecting to ipv4.download.thinkbroadband.com (ipv4.download.thinkbroadband.com)|80.249.99.148|:81... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/zip]
Saving to: ‘1GB.zip’

20% [=======> ] 224,753,012 --.-K/s eta 10m 22s

--2013-11-09 18:39:08-- http://ipv4.download.thinkbroadband.com:81/1GB.zip
Resolving ipv4.download.thinkbroadband.com (ipv4.download.thinkbroadband.com)... 80.249.99.148
Connecting to ipv4.download.thinkbroadband.com (ipv4.download.thinkbroadband.com)|80.249.99.148|:81... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 1073741824 (1.0G), 848988812 (810M) remaining [application/zip]
Saving to: ‘1GB.zip’

58% [++++++++=============> ] 632,180,438 --.-K/s eta 1m 51s
=================

After adjustment

================
Connecting to ipv4.download.thinkbroadband.com (ipv4.download.thinkbroadband.com)|80.249.99.148|:81... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/zip]
Saving to: ‘1GB.zip’

100%[====================================>] 1,073,741,824 34.3Mb/s in 4m 7s

2013-11-09 18:53:10 (34.8 Mb/s) - ‘1GB.zip’ saved [1073741824/1073741824]
=============


Nick

Edited by deleted (Sat 09-Nov-13 23:07:01)

Actually further investigation and testing on this issue with this router.

I noticed that when downloading a large file the web interface to the router 'freezes' for a few seconds when changing to another menu. Firefox (after a few minutes) throws up the 'a script is taking too long to finish' type warning.

OK, so reading between the lines I think the 'echo response time' is a type of watchdog that the router uses to poll connection and expects to receive replies in an orderly fashion - if it doesn't it presumes dsl connection is down and enables a disonnect/reconnect request.

Of course, what is happening is that CPU load/memory constraints make the echo request delay somewhat ~ the watchdog doesn't get any repllies during this period and thus issues a PPPoE down/up request thinking the line is down.

So I have now turned OFF echo request (i.e. set it to 0) so router doesn't watch the line - and I have already seen a real improvement in response time to all test.

Nick

Edited by deleted (Sat 09-Nov-13 22:52:57)