SIM in illegal state, uqmi/qmi broken? [was Re: Setting up a Quectel RM520GL-N on a Banana Pi R4-Pro]

Philip Prindeville philipp_subx at redfish-solutions.com
Mon Mar 23 13:23:35 PDT 2026



> On Mar 22, 2026, at 3:32 PM, Luca Olivetti <luca at ventoso.org> wrote:
> 
> El 15/3/26 a les 23:50, Philip Prindeville via openwrt-devel ha escrit:
> 
> 
>> Sun Mar 15 16:46:33 2026 daemon.notice netifd: Interface 'qmi' is setting up now
>> Sun Mar 15 16:46:33 2026 daemon.notice netifd: qmi (6753): Waiting for SIM initialization
>> Sun Mar 15 16:46:33 2026 daemon.notice netifd: qmi (6753): SIM in illegal state - Power-cycling SIM
> 
> 
> mmh, not the same modem, not the same system and (probably) not the same problem, but lately I'm getting a bunch of these "SIM in illegal state" messages, never happened with openwrt 24.x.
> 
> I think there's something wrong with either the qmi driver or uqmi (it could also be the modem firmware but, as I said, it didn't happen with openwrt 24.x).
> 
> The "SIM in illegal state" comes from /lib/netifd/proto/qmi.sh
> 
> 
>        # Check if UIM application is stuck in illegal state
>        local uim_state_timeout=0
>        while true; do
>                json_load "$(uqmi -s -d "$device" -t 2000 --uim-get-sim-state)"
>                json_get_var card_application_state card_application_state
> 
>                # SIM card is either completely absent or state is labeled as illegal
>                # Try to power-cycle the SIM card to recover from this state
>                if [ -z "$card_application_state" -o "$card_application_state" = "illegal" ]; then
>                        echo "SIM in illegal state - Power-cycling SIM"
> 
> 
> and my hunch is that somewhat uqmi locks up, the command times out so it triggers the -z "$card_application_state" part of the condition, and power cycling the sim does nothing (in fact if uqmi is stuck it will never actually power cicle the sim, besides, most probably the sim isn't the problem).
> 
> My workaround is to reset the modem when I lose connectivity: I already had a cron job to test for it (it happened that the interface had an address but it stopped working) that simply restarted the interface, now it also resets the modem.
> Note the commented out "uqmi ... --set-device-operating-mode reset" which didn't work (it never returned and I saw several instances runnnig by so many cron invocations,hence my hypothesis that it also fails in /lib/netifd/proto/qmi.sh):
> 
> #!/bin/sh
> #logger "checkwan"
> 
> # wait 10 minutes after boot
> [ $(awk -F "." '{print $1}' /proc/uptime) -lt "600" ] && exit 0
> # wait 5 minutes after last attempt
> find /tmp -name ltedown  -mmin +5 -exec rm \{\} \;
> if [ -f /tmp/ltedown ] ; then
>  logger "less than 5 minutes since last attempt"
>  exit 0
> fi
> ping -q -c 1 8.8.8.8 > /dev/null && exit 0
> ping -q -c 1 1.1.1.1 > /dev/null && exit 0
> uqres=$(uqmi -d /dev/cdc-wdm0 -t 20000 --get-data-status)
> logger "ping test failed, down/up wwan, uqmi says $uqres"
> ifdown wwan
> # Power cycle / Reset
> echo "AT+CFUN=1,1" > /dev/ttyUSB2
> sleep 20
> #uqmi -s -d /dev/cdc-wdm0 --set-device-operating-mode reset
> ifup wwan
> touch /tmp/ltedown
> 
> Bye
> --
> Luca


I'm running the 24.10 SNAPSHOT that Banana Pi burned on the board.

Not sure why I don't get a /dev/ttyUSB0 ...





More information about the openwrt-devel mailing list