Issue connecting with Quectel EM20-G modem on openwrt

Aleksander Morgado aleksander at aleksander.es
Sat May 23 02:49:04 UTC 2020


Hey Alex

> I have been trying to add support for the Quectel EM20-G LTE modem on
> openwrt, using a similar method to how the support for the RM500Q modem
> was implemented. I made changes to the qmi_wwan driver using the
> attached patch (which also has backported changes for the RM500Q).
>

Not sure I've seen that RM500Q patch before, but the
QMI_QUIRK_QUECTEL_DYNCFG() looks equivalent to the
QMI_MATCH_FF_FF_FF() in linux git master, right? That is being
correctly used I believe, it shouldn't be an issue for the thing
you're seeing.

> I am currently using modemmanager master commit
> 1eeec40ee85552cee957f35db9cc85aae6116e48 on linux 4.14. I am running on
> openwrt 18.06.2.
>
> The modem is detected successfully by the kernel and libqmi.
> Modemmanager seems to detect the modem and sim fine, but the modem is
> always listed as "enabled", not "connected" and does not have a bearer.
>

If it's enabled, it means netifd enabled it. At this point, it is up
to the modem to get automatically registered to the network. What it
looks like is that it may not find any, the "serving system" info
reports "not-registered-searching" all the time when in LTE:

Fri May 22 16:31:06 2020 daemon.debug [2158]: [/dev/cdc-wdm0] received
generic response (translated)... <<<<<< QMUX: <<<<<<   length  = 66
<<<<<<   flags   = 0x80 <<<<<<   service = "nas" <<<<<<   client  = 3
<<<<<< QMI: <<<<<<   flags       = "response" <<<<<<   transaction = 9
<<<<<<   tlv_length  = 54 <<<<<<   message     = "Get Serving System"
(0x0024) <<<<<< TLV: <<<<<<   type       = "Result" (0x02) <<<<<<
length     = 4 <<<<<<   value      = 00:00:00:00 <<<<<<   translated =
SUCCESS <<<<<< TLV: <<<<<<   type       = "Serving System" (0x01)
<<<<<<   length     = 6 <<<<<<   value      = 02:02:02:02:01:08 <<<<<<
  translated = [ registration_state = 'not-registered-searching'
cs_attach_state = 'detached' ps_attach_state = 'detached'
selected_network = '3gpp' radio_interfaces = '{ [0] = 'lte '}' ]
<<<<<< TLV: <<<<<<   type       = "Roaming Indicator" (0x10) <<<<<<
length     = 1 <<<<<<   value      = 01 <<<<<<   translated = off
<<<<<< TLV: <<<<<<   type       = "Data Service

And it cannot fallback to 3G because it's getting a registration denied:

Fri May 22 16:31:42 2020 daemon.debug [2158]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<<   length  = 48
<<<<<<   flags   = 0x80 <<<<<<   service = "nas" <<<<<<   client  = 3
<<<<<< QMI: <<<<<<   flags       = "indication" <<<<<<   transaction =
10 <<<<<<   tlv_length  = 36 <<<<<<   message     = "Serving System"
(0x0024) <<<<<< TLV: <<<<<<   type       = "Serving System" (0x01)
<<<<<<   length     = 6 <<<<<<   value      = 03:02:02:02:01:05 <<<<<<
  translated = [ registration_state = 'registration-denied'
cs_attach_state = 'detached' ps_attach_state = 'detached'
selected_network = '3gpp' radio_interfaces = '{ [0] = 'umts '}' ]
<<<<<< TLV: <<<<<<   type       = "Roaming Indicator" (0x10) <<<<<<
length     = 1 <<<<<<   value      = 01 <<<<<<   translated = off
<<<<<< TLV: <<<<<<   type       = "Data Service Capability" (0x11)
<<<<<<   length     = 1 <<<<<<   value      = 00 <<<<<<   translated =
{} <<<<<< TLV: <<<<<<   type       = "Roaming Indic

> I attached the output from modemmanager using the --debug and
> --log-level=DEBUG flags, plus the patch I used to get qmi_wwan working.
>
> This might also be because of poor signal. I do not have physical
> access to the machine with the modem, and it may be having difficulty
> reaching the towers.
>

It does look like something like that could be happening. Is it just
far away from any network? Or antenna disconnected?

-- 
Aleksander
https://aleksander.es


More information about the ModemManager-devel mailing list