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.