comgt-ncm: modem detection is confused by boot-time URCs, leaving the interface permanently down #25285

Describe the bug

Summary

ncm.sh identifies the modem with AT+CGMI / AT+CGMM and takes the first line of the reply that is not the command echo. A modem that is still booting emits unsolicited result codes on the same port, so that line is often a URC rather than the vendor or model. The interface is then marked unsupported and, because proto_set_available 0 is called, netifd never retries it. Only a manual ifup brings it back.

Affected

• comgt-ncm 0.32-r37, /lib/netifd/proto/ncm.sh, all NCM modems
• Tested on OpenWrt main 7b2d2aa, Cudy LT700 Outdoor v1 (ramips/mt7621), Quectel EG060W (2c7c:6004)

How to reproduce

With wwan up, power-cycle the modem (on this board via its power-enable GPIO). /etc/hotplug.d/tty/30-3g calls proto_set_available 1 as soon as /dev/ttyUSB2 is recreated, so netifd starts ncm.sh immediately - while the modem is still emitting URCs. Note an ifdown first prevents the reproduction: the interface has to be up for hotplug to trigger setup.

Result

Interface 'wwan' is setting up now
wwan (4950): Unsupported modem
wwan (4997): Stopping network wwan
Interface 'wwan' is now down

Still "up": false 60s later, with no further attempt.

Evidence

/dev/ttyUSB2 appears 15s after the modem is powered, and the first replies through it are unusable. Probing once a second with nothing else on the port:

[+15s] CGMI[]  CGMM[ OK AT*APPOWERIND=0;*POWERIND=0 +CESQ: 99,99,255,255,255,255
       *CESQ: ... ^MODE:0,0 +CIREPI: 0 *BANDIND: OK AT+CGMI Quectel OK AT+CGMM EG060W-EAAA OK ]
[+18s] CGMI[AT+CGMI Quectel OK  RDY ]   CGMM[AT+CGMM EG060W-EAAA OK ]
[+20s] CGMI[AT+CGMI Quectel OK ]        CGMM[AT+CGMM EG060W-EAAA OK ]   <- clean from here

Three failures follow:

1. Empty reply (CGMI[] at +15s) -> GETINFO_FAILED. The retry loop only runs when the delay option is set, and config_generate never writes it, so by default the modem gets one attempt.
2. URC taken as the vendor. At +18s RDY arrives inside the AT+CGMI capture; had the read window opened slightly later it would have been the first line and become the manufacturer -> no profile -> Unsupported modem -> proto_set_available 0 -> permanently down. This is the reproduced failure.
3. URC taken as the model. The +15s CGMM capture starts with a stray OK, so model becomes ok; ncm_select_modemmissesquectel-okand silently falls back to the plainquectelprofile, which sendsAT+QICSGP=1` - a command the EG060W rejects. The model is never retried at all, unlike the
   manufacturer.

Root cause

• The parser has no notion of URCs, bare status lines (OK, RDY, ERROR) or echoes of commands other than the one it sent.
• Retrying is opt-in via delay and covers only the manufacturer.
• A failed identification is treated as permanent.

Suggested fix

• Skip command echoes, URCs and status lines; anchor the answer on the echo of the command sent, with a fallback for modems with echo off.
• Retry while the modem is still booting, one deadline shared by both queries.
• Report what was actually read when giving up.

Out of scope: the carrier settle wait (linksettle), which happens after connect and addresses a different failure.

(I used some LLM to summarize the findings ... )

OpenWrt version

SNAPSHOT

OpenWrt release

SNAPSHOT

OpenWrt target/subtarget

ramips/mt7621

Device

Cudy LT700 Outdoor v1 (cudy,lt700-outdoor-v1)

Image kind

Self-built image

Steps to reproduce

No response

Actual behaviour

No response

Expected behaviour

No response

Additional info

No response

Diffconfig

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.