"sudo pon" will fail during the AT commands but sending them directly with minicom won't fail

End-of-Life Product Cellular IoT HAT
1

Hi, I installed the Sixfab Cellular IoT HAT in my RPI4 and I’m trying to make it work with a data SIM.

I followed all the install instructions, running the ppp_install_standalone.sh script, picking option 4 and setting my carrier. Now, when I execute “sudo pom” to start the connection I see this:

pi@raspberrypi:~ $ sudo pon
pppd options in effect:
debug           # (from /etc/ppp/peers/provider)
updetach                # (from /etc/ppp/peers/provider)
persist         # (from /etc/ppp/peers/provider)
dump            # (from /etc/ppp/peers/provider)
noauth          # (from /etc/ppp/peers/provider)
remotename 3gppp                # (from /etc/ppp/peers/provider)
/dev/ttyUSB3            # (from /etc/ppp/peers/provider)
115200          # (from /etc/ppp/peers/provider)
lock            # (from /etc/ppp/peers/provider)
connect chat -s -v -f /etc/chatscripts/chat-connect -T internet.ideasclaro              # (from /etc/ppp/peers/provider)
disconnect chat -s -v -f /etc/chatscripts/chat-disconnect               # (from /etc/ppp/peers/provider)
nocrtscts               # (from /etc/ppp/peers/provider)
modem           # (from /etc/ppp/peers/provider)
asyncmap 0              # (from /etc/ppp/options)
lcp-echo-failure 4              # (from /etc/ppp/options)
lcp-echo-interval 30            # (from /etc/ppp/options)
hide-password           # (from /etc/ppp/peers/provider)
novj            # (from /etc/ppp/peers/provider)
novjccomp               # (from /etc/ppp/peers/provider)
ipcp-accept-local               # (from /etc/ppp/peers/provider)
ipcp-accept-remote              # (from /etc/ppp/peers/provider)
ipparam 3gppp           # (from /etc/ppp/peers/provider)
noipdefault             # (from /etc/ppp/peers/provider)
ipcp-max-failure 30             # (from /etc/ppp/peers/provider)
defaultroute            # (from /etc/ppp/peers/provider)
usepeerdns              # (from /etc/ppp/peers/provider)
noccp           # (from /etc/ppp/peers/provider)
noipx           # (from /etc/ppp/options)
abort on (BUSY)
abort on (NO CARRIER)
abort on (NO DIALTONE)
abort on (ERROR)
abort on (NO ANSWER)
timeout set to 30 seconds
send (AT^M)
expect (OK)
^M
alarm
Failed
Script chat -s -v -f /etc/chatscripts/chat-connect -T internet.ideasclaro finished (pid 2017), status = 0x3

As you can see the response never come… What is weird is randomly the AT command will receive the “OK” but then the very next command will do the same. Now, If I run all the commands that are preset in the /etc/chatscripts/chat-connect script using minicom, the answer for those commands are instant:

pi@raspberrypi:~ $ sudo minicom -D /dev/ttyUSB3 -b 115200

Welcome to minicom 2.8

OPTIONS: I18n
Port /dev/ttyUSB3, 16:08:09

Press CTRL-A Z for help on special keys

AT

OK
ATE0

OK
AT+CPIN?

+CPIN: READY

OK
AT+CSQ

+CSQ: 16,99

OK
AT+CREG?

+CREG: 0,5

OK
AT+CGREG?

+CGREG: 0,5

OK
AT+COPS?

+COPS: 0,0,"CLARO HN Claro",0

OK
AT+CGDCONT=1,"IP","internet.ideasclaro",,0,0

OK
ATD*99#

CONNECT 150000000

There are no delays, no waits. The OK are received instantly. Not sure what is happening. I still don’t see the ppp0 connection with ifconfig tho.

2

An update… I modified the chat-connect script that uses the chat command to ignore all the answers and this make “sudo pon” to connect without any issue. Not sure why ‘chat’ is not receiving the answers but this issue is driving me crazy

# /etc/chatscripts/chat-connect
ABORT "BUSY"
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
TIMEOUT 120
'' AT
'' ATE0
'' AT+CPIN?
'' AT+CSQ
'' AT+CREG?
'' AT+CGREG?
'' AT+COPS?
'' AT+CGDCONT=1,"IP","\T",,0,0
'' ATD*99#
''
3

Hi,

Sometimes other processes (like ModemManager) might be interfering with the ppp connection. Ensure that no other process is trying to manage the modem while your script is running.

Before running sudo pon , manually initialize the modem with the following commands in Minicom or a similar tool:

AT+CFUN=1
AT+CGDCONT=1,"IP","YOUR_APN>",,0,0

After ensuring these commands work, try running sudo pon again.

Use dmesg or journalctl -xe to check for any additional clues in the system logs that might indicate what’s going wrong during the ppp connection attempt.