In reply to a post by David_W:

The failed echo-requests that are triggering the redial are LCP Echo Requests, which is the equivalent of a ping but at the PPP layer. LCP Echo Requests are the correct way to monitor for PPPoE failure, especially as the IP address of the gateway at the Zen end of an FTTC connection is dynamic.


pppd sends a LCP Echo Request every lcp-echo-interval. If lcp-echo-failure in a row of these requests fail, the connection is assumed to have died, the PPP layer is torn down and the connection is re-established.

The defaults listed in your dump make little sense for FTTC PPPoE - there's no reason to wait two minutes before giving up with the PPP connection and starting over. The defaults are for dial-up PPP, where re-establishing the connection takes tens of seconds and likely has a financial cost attached. With FTTC PPPoE, the connection can be re-established in less than a second if the VDSL2 connection has stayed synchronised, and there's no cost attached, so it is in your interests to detect and act on any PPP failure quickly rather than waiting and hoping things will start working.

I'd make lcp-echo-interval 4 and lcp-echo-failure 4 in /etc/ppp/options , which means an LCP Echo Request is sent every 4 seconds and a failure is detected after 4 failed attempts (i.e. 16 seconds). An LCP Echo Request once every 4 seconds imposes minimal overhead, but allows for rapid detection of connection failure. One or two consecutive failures will happen from time to time with such a short interval, but 4 in a row almost guarantees the connection has failed.

You can tweak the detection interval even lower than 16 seconds if you like, but I wouldn't want to send an LCP Echo Request more often than every 4 seconds. Ultimately, it's a trade-off between speed of detection and detecting false failures.


You should configure your equipment not to close sockets or drop firewall states on a PPPoE failure, as the static IP on Zen means any traffic should resume once the PPPoE connection is re-established. My lack of familiarity with Linux precludes me from knowing where these settings are if they are not the defaults: I use FreeBSD with mpd5 rather than Linux with pppd. If you find sockets and/or firewall states are being torn down on PPP failure, I'd take a close look at the /etc/ppp/ip-up and /etc/ppp/ip-down scripts (especially the ip-down one).


So far as why these PPP drop-outs are occurring, you'd need to address that question to Zen support, who can take a look at the logs for your connection.

Everything you say makes sense but I think the most pertinent point is the last paragraph. Why would my FTTC connection be dropping out as often as a dialup modem on a crackly phoneline? Is this just something that happens with FTTC connections? Before this I had years of virtually trouble-free ADSL2+ from Be.

In reply to a post by jez9999:

... I'm trying to figure out where the problem lies.
... I'm guessing either my ethernet connection to the modem is faulty or the modem itself is dropping the DSL connection. I suspect the latter but how can I be sure?

If you have an unlocked Huawei HG612 with logging enabled (debug), line resync events may be captured in the log. Be aware that Openreach are currently updating the firmware in these modems - you may lose access to the logs.

In reply to a post by jez9999:

lcp-echo-failure 4 # (from /etc/ppp/options)
lcp-echo-interval 30 # (from /etc/ppp/options)

Your current PPP session timeout detection window is 90-120 seconds. With such a large window, it's possible that you may be missing PPP session events that are less than 90-120 seconds in duration. I suggest that you lower the LCP-echo interval in order to detect PPP timeouts in the 10-20 second range.
For example, I have my LCP-echo interval set at 5 seconds (x4 LCP-echo failures). My firewall detects PPP session timeouts in the 15-20 second range. The suggestion given by David_W will detect PPP session timeouts in the 12-16 second range.

BT SIN 498 gives the reason for keeping the PPP session timeout detection value to less than your current settings;

2.1.6 Downstream shaping
The CP is expected to shape the downstream traffic to match the actual VDSL2 line rate in order to avoid excessive traffic loss.
CPs should be aware that the mechanism for reporting the downstream and upstream line rates relies on a line re-train causing the CP, or the CPE, to initiate a new PPP session or a new DHCP request. The success of this method of line rate reporting is down to the CP's choice of timers used around PPP/DHCP handling.
If the PPP/DHCP survives a re-train, then the CP will be unaware of any change in the line rate and will not be able to shape appropriately.
The line re-train time for VDSL2 can be anywhere between 10 and 60 seconds, with typical values in the 20-30 second range.

N.B. Your ISP should also set a PPP session timeout value. Hopefully, it'll be within the guidelines suggested above.

In reply to a post by jez9999:

rcvd [LCP TermReq id=0xc8]
LCP terminated by peer
Connect time 694.9 minutes.

The PPPoE session was ended (in a controlled and graceful manner) by your ISP or the party between you and your ISP.

In reply to a post by jez9999:

No response to 4 echo-requests
Serial link appears to be disconnected.

Anything between you and your ISP could be the culprit.
Does the problem occur at specific times of day (you haven't provided any timestamps)?

Was this solved? I am having a random ppp disconection problem when downloading a 1gb file. Gets to about 800-900mb downloaded then PPP drops. My setup was a Zyxel VMG-1312-B10A modem connected to an Asus RT-AC68U. I have swapped the modem to a HG612 and adjusted Echo interval to 4 and max failures to 4 on my 55mbit VDSL line and monitoring.

In reply to a post by Banger:

Was this solved? I am having a random ppp disconection problem when downloading a 1gb file. Gets to about 800-900mb downloaded then PPP drops. My setup was a Zyxel VMG-1312-B10A modem connected to an Asus RT-AC68U. I have swapped the modem to a HG612 and adjusted Echo interval to 4 and max failures to 4 on my 55mbit VDSL line and monitoring.

Lol, seven years ago? Would they even remember that far back?

I didn't notice the date found using google.