PPP: Lcp-echo function not working

The device is a Gl-MIFI unit with a Quectel EC25-E modem.

In dialup mode (attached to ttyUSB3), it does not matter how I set up the lcp-echo-interval and lcp-echo-failure parameters, only a single lcp-echo-request and reply message can be seen in the log during session creation. I enabled debug loggingm this is the output:

Thu Apr 30 18:04:50 2020 daemon.notice pppd[13948]: pppd 2.4.8 started by root, uid 0
Thu Apr 30 18:04:51 2020 daemon.debug pppd[13948]: Script USE_APN=internet DIALNUMBER=*99***1# /usr/sbin/chat -t5 -v -E -f /etc/chatscripts/3g.chat finished (pid 13950), status = 0x0
Thu Apr 30 18:04:51 2020 daemon.info pppd[13948]: Serial connection established.
Thu Apr 30 18:04:51 2020 daemon.debug pppd[13948]: using channel 108
Thu Apr 30 18:04:51 2020 kern.info kernel: [  700.641565] 3g-modem: renamed from ppp0
Thu Apr 30 18:04:51 2020 daemon.info pppd[13948]: Renamed interface ppp0 to 3g-modem
Thu Apr 30 18:04:51 2020 daemon.info pppd[13948]: Using interface 3g-modem
Thu Apr 30 18:04:51 2020 daemon.notice pppd[13948]: Connect: 3g-modem <--> /dev/ttyUSB3
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: sent [LCP ConfReq id=0x1 <mru 1300> <asyncmap 0x0> <magic 0x5589f932>]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: rcvd [LCP ConfReq id=0x3e <asyncmap 0x0> <auth chap MD5> <magic 0xc0925df> <pcomp> <accomp>]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: No auth is possible
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: sent [LCP ConfRej id=0x3e <auth chap MD5> <pcomp> <accomp>]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: rcvd [LCP ConfAck id=0x1 <mru 1300> <asyncmap 0x0> <magic 0x5589f932>]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: rcvd [LCP ConfReq id=0x3f <asyncmap 0x0> <magic 0xc0925df>]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: sent [LCP ConfAck id=0x3f <asyncmap 0x0> <magic 0xc0925df>]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: sent [LCP EchoReq id=0x0 magic=0x5589f932]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: rcvd [LCP DiscReq id=0x40 magic=0xc0925df]
Thu Apr 30 18:04:52 2020 daemon.debug pppd[13948]: rcvd [LCP EchoRep id=0x0 magic=0xc0925df 55 89 f9 32]
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: rcvd [IPCP ConfReq id=0x0]
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: rcvd [IPCP ConfNak id=0x1 <addr 100.120.12.113> <ms-dns1 185.29.83.64> <ms-dns2 185.62.131.64>]
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: sent [IPCP ConfReq id=0x2 <addr 100.120.12.113> <ms-dns1 185.29.83.64> <ms-dns2 185.62.131.64>]
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: rcvd [IPCP ConfReq id=0x1]
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: sent [IPCP ConfAck id=0x1]
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: rcvd [IPCP ConfAck id=0x2 <addr 100.120.12.113> <ms-dns1 185.29.83.64> <ms-dns2 185.62.131.64>]
Thu Apr 30 18:04:53 2020 daemon.warn pppd[13948]: Could not determine remote IP address: defaulting to 10.64.64.64
Thu Apr 30 18:04:53 2020 daemon.notice pppd[13948]: local  IP address 100.120.12.113
Thu Apr 30 18:04:53 2020 daemon.notice pppd[13948]: remote IP address 10.64.64.64
Thu Apr 30 18:04:53 2020 daemon.notice pppd[13948]: primary   DNS address 185.29.83.64
Thu Apr 30 18:04:53 2020 daemon.notice pppd[13948]: secondary DNS address 185.62.131.64
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: Script /lib/netifd/ppp-up started (pid 13984)
Thu Apr 30 18:04:53 2020 daemon.debug pppd[13948]: Script /lib/netifd/ppp-up finished (pid 13984), status = 0x1

and based on the default settings in /etc/ppp/options, the PPP client should send an echo-request every second:

lcp-echo-failure 5
lcp-echo-interval 1

The practical issue is the link detect: if the modem goes out of coverage, the PPP interface stays up, and the control LED also indicates a connection, while it should not.

Same issue is with QMI by the way, but in that case I guess there is no similar mechanism in place like LCP on PPP to notify the interface to go down.

Maybe I am doing something wrong, so if anyone has an idea, please let me know.

Don't use /etc/ppp/options to set the LCP echo params since they'll get overridden by the commandline.

Furthermore OpenWrt uses adaptive LCP by default, means LCP echos are only sent when the connection is idle, otherwise received data frames count as successful echo.

To control the LCP echo parameters, use option keepalive "X Y" in config interface wan of /etc/config/network - X controls the failure threshold (lcp-echo-failure) and Y the interval (lcp-echo-interval).

Example: option keepalive '5 1' results in lcp-echo-failure 5 lcp-echo-interval 1

To disable the adaptive LCP, use option keepalive_adaptive 0

1 Like

Thanks @jow I did the modification as you described, but the debug log is still not indicating a single LCP EchoReq - LCP EchoRep except for the one during the session setup. And still, if the modem looses coverage, the PPP interface stays up indefinitely. And the modem is in idle, literally 0 packet is passing through.

Do you have any idea what to try? Or maybe I need to enable some more logging besides debug in the options file?

@jow sorry to spam you, but it seems you are the only one who can help. If you have any idea what to try, or you need more logs, please let me know.