RC7620 PPPos UART 1 - ppp termination causes odd modem behaviour requiring !RESET or POR

ati9
Manufacturer: Sierra Wireless, Incorporated
Model: RC7620
QTI baseline: MPSS.JO.2.0.2.c1.1-00073-9607_GENNS_PACK-1.416077.1.419248.1
Revision: SWI9X07H_00.08.19.00 725c0e jenkins 2021/09/08 14:36:45
IMEI: 353634110110227
IMEI SV: 18
FSN: 7Q0273850613B0

We can successful start and maintain a PPPos (pppd) session via the RC7620 physical UART1. Following PPP termination of the session the RC7620 is also unable to make a further PPPos connections via UART1 and also fails to respond to the following commands,.

at+cfun?
ERROR
AT+CFUN=1,1
ERROR
at+cfun=1
ERROR

We do not see this issue if the USB AT command serial port is used

AT!RESET works ok and restores the modem to normal operation. POR also restores normal operation.

Example pppd connect

Example connection

sudo pppd 115200 /dev/ttyAMA0 record pptestee_08_19uart.txt call pppRC7620
pi@raspberrypi:~ $ pppd options in effect:
debug           # (from /etc/ppp/peers/pppRC7620)
nodetach                # (from /etc/ppp/peers/pppRC7620)
unit 1          # (from /etc/ppp/peers/pppRC7620)
dump            # (from /etc/ppp/peers/pppRC7620)
noauth          # (from /etc/ppp/peers/pppRC7620)
/dev/ttyAMA0            # (from command line)
115200          # (from command line)
nolock          # (from /etc/ppp/peers/pppRC7620)
connect /usr/sbin/chat -v -f /etc/chatscripts/chatUp            # (from /etc/ppp/peers/pppRC7620)
disconnect /usr/sbin/chat -v -f /etc/chatscripts/chatDown               # (from /etc/ppp/peers/pppRC7620)
record pptestee_08_19uart.txt           # (from command line)
nocrtscts               # (from /etc/ppp/peers/pppRC7620)
modem           # (from /etc/ppp/options)
noaccomp                # (from /etc/ppp/peers/pppRC7620)
asyncmap 0              # (from /etc/ppp/options)
nomagic         # (from /etc/ppp/peers/pppRC7620)
nopcomp         # (from /etc/ppp/peers/pppRC7620)
lcp-echo-failure 4              # (from /etc/ppp/options)
lcp-echo-interval 30            # (from /etc/ppp/options)
show-password           # (from /etc/ppp/peers/pppRC7620)
novj            # (from /etc/ppp/peers/pppRC7620)
ipcp-accept-local               # (from /etc/ppp/peers/pppRC7620)
ipcp-accept-remote              # (from /etc/ppp/peers/pppRC7620)
noipdefault             # (from /etc/ppp/peers/pppRC7620)
defaultroute            # (from /etc/ppp/peers/pppRC7620)
replacedefaultroute             # (from /etc/ppp/peers/pppRC7620)
usepeerdns              # (from /etc/ppp/peers/pppRC7620)
:               # (from /etc/ppp/peers/pppRC7620)
noipv6          # (from /etc/ppp/peers/pppRC7620)
noccp           # (from /etc/ppp/peers/pppRC7620)
noipx           # (from /etc/ppp/options)
Script /usr/sbin/chat -v -f /etc/chatscripts/chatUp finished (pid 3213), status = 0x0
Serial connection established.
using channel 3
Using interface ppp1
Connect: ppp1 <--> /dev/pts/2
sent [LCP ConfReq id=0x1 <asyncmap 0x0>]
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth pap> <magic 0x5cd8970f> <pcomp> <accomp>]
sent [LCP ConfRej id=0x0 <magic 0x5cd8970f> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap>]
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap>]
sent [LCP EchoReq id=0x0 magic=0x0]
sent [PAP AuthReq id=0x1 user="raspberrypi" password=""]
rcvd [LCP DiscReq id=0x2 magic=0x5cd8970f]
rcvd [LCP EchoRep id=0x0 magic=0x5cd8970f 00 00 00 00]
rcvd [PAP AuthAck id=0x1 ""]
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfReq id=0x0]
sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 100.65.78.43> <ms-dns1 109.249.185.228> <ms-dns2 109.249.185.229>]
sent [IPCP ConfReq id=0x2 <addr 100.65.78.43> <ms-dns1 109.249.185.228> <ms-dns2 109.249.185.229>]
rcvd [IPCP ConfReq id=0x1]
sent [IPCP ConfAck id=0x1]
rcvd [IPCP ConfAck id=0x2 <addr 100.65.78.43> <ms-dns1 109.249.185.228> <ms-dns2 109.249.185.229>]
Could not determine remote IP address: defaulting to 10.64.64.65
Script /etc/ppp/ip-pre-up started (pid 3219)
Script /etc/ppp/ip-pre-up finished (pid 3219), status = 0x0
replacing old default route to eth0 [10.10.10.1]
del old default route ioctl(SIOCDELRT): No such process(3)
local  IP address 100.65.78.43
remote IP address 10.64.64.65
primary   DNS address 109.249.185.228
secondary DNS address 109.249.185.229
Script /etc/ppp/ip-up started (pid 3222)
Script /etc/ppp/ip-up finished (pid 3222), status = 0x0

Example disconnect

Terminating on signal 15
Connect time 1.7 minutes.
Sent 0 bytes, received 0 bytes.
Script /etc/ppp/ip-down started (pid 3306)
sent [LCP TermReq id=0x2 "User request"]
Child process pppd (charshunt) (pid 3212) terminated with signal 15
Modem hangup
Connection terminated.
Script /etc/ppp/ip-down finished (pid 3306), status = 0x0

Hi johnofleek,

The module can be stuck in data mode. You can try toggling the DTR pin ON/OFF or typing +++ to exit data mode.

Hi Donald
Thanks for your response
Yes I have observed the sticking data mode. That is not the issue I reported here. For this post I had manually exited (using +++) data mode - the modem was in command mode .
Note that when my reported issue occurs the modem is responding with ERROR to some commands (as above) - not all commands for example AT+CSQ is functional as is AT!RESET

Changing the module firmware to a later version fixed the odd modem behaviour after a UART1 PPP session.

Manufacturer: Sierra Wireless, Incorporated
Model: RC7620-1
QTI baseline: MPSS.JO.2.0.2.c1.1-00073-9607_GENNS_PACK-1.416077.1.419248.1
Revision: SWI9X07H_00.08.24.00 cb6ed3 jenkins 2022/01/07 03:05:21
IMEI: 353635110154131
IMEI SV: 19
FSN: 7T1017851610B0

With this version I am able to

  1. terminate a PPPos UART1 session
  2. Manually hangup +++ and the ATH
  3. restart a PPPos UART1 session

I do however have the hangup issue that Donald reported. This doesn’t happen when using USB so maybe USB is using DTR.

A possible (Debian) hang up workaround is to modify the connect chat scripts by adding the following:

''  AT

# disconnect previous session if there was one 
# Expect OK, if it is NOT received (because the modem is not in command mode) then send +++ and expect OK. 
# then send ATH0 (the modem hang up string)
OK-+++\c-OK   ATH0

Some further rough notes that may be of interest