Quectel EG91-E: Dormant Traffic Channel

[Aleksander Morgado]

Hey,

> We're observing an interesting behavior with the Quectel EG91-E modem
> (using QMI comms). Every now and then, we lose connectivity. When
> looking at the debug-level logs, we can see that the modem sends and
> indication with "Dormancy Status" set to "traffic-channel-dormant". This
> does not seem to happen when we artificially create more and continuous
> traffic on the cellular network interface. Following that indication,
> the modem appears to reset but does not re-enumerate on the USB. This
> makes all subsequent QMI transaction fail. How can this be explained? Is
> the modem misbehaving or should ModemManager/libqmi handle this somehow?
>
> We're using mmcli 1.14.2 / qmicli 1.26.0. The modem's firmware is
> EG91EFBR06A04M4G. This is the relevant log excerpt:
>
> 15:34:14: [modem0] signal strength (lte): -80 dBm
> 15:34:14: [modem0] signal strength: -80 dBm --> 54%
> 15:34:14: [modem0] signal quality updated (54)
> 15:34:14: [modem0] periodic signal quality and access technology checks
> scheduled
> 15:34:21: [/dev/cdc-wdm0] received message...
>            <<<<<< RAW:
>            <<<<<<   length = 17
>            <<<<<<   data   =
> 01:10:00:80:01:14:04:E4:0B:01:00:04:00:18:01:00:01
> 15:34:21: [/dev/cdc-wdm0] received generic indication (translated)...
>            <<<<<< QMUX:
>            <<<<<<   length  = 16
>            <<<<<<   flags   = 0x80
>            <<<<<<   service = "wds"
>            <<<<<<   client  = 20
>            <<<<<< QMI:
>            <<<<<<   flags       = "indication"
>            <<<<<<   transaction = 3044
>            <<<<<<   tlv_length  = 4
>            <<<<<<   message     = "Event Report" (0x0001)
>            <<<<<< TLV:
>            <<<<<<   type       = "Dormancy Status" (0x18)
>            <<<<<<   length     = 1
>            <<<<<<   value      = 01
>            <<<<<<   translated = traffic-channel-dormant
> 15:34:21: [modem0/bearer0] got QMI WDS event report

The traffic dormant messages are usually expected when there is no
data traffic going through the modem, they should not have any major
impact anywhere.

> 15:34:24: [modem0/ttyUSB0/qcdm] <-- 60 0a 00 9e 01 00 00 00 00 00 00 00
> 00 ef ad 7e
> 15:34:24: [modem0/ttyUSB3/at] <-- '<CR><LF>RDY<CR><LF>'
> 15:34:24: [modem0/ttyUSB2/at] <-- '<CR><LF>RDY<CR><LF>'
> 15:34:24: [modem0/ttyUSB2/at] <-- '<CR><LF>+CFUN: 1<CR><LF>'
> 15:34:25: [modem0/ttyUSB2/at] <-- '<CR><LF>+CPIN: READY<CR><LF>'
> 15:34:25: [modem0/ttyUSB2/at] <-- '<CR><LF>+QUSIM: 1<CR><LF>'

This totally looks like a modem internal self-reset, something to
report to Quectel. The device doesn´t go away from USB, but internally
the whole radio stack was likely fully reseted.
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/285


-- 
Aleksander