Help on an invalid modem case

Aleksander Morgado aleksander at aleksander.es
Mon Jul 6 11:10:08 UTC 2020


Hey!

>
> here are the logs you ask:
>   - mmcli and lsusb output logs
>   - the matching Modem Manager debug logs
>
> Hope it helps.
>

It does help yes. I can see how we're using the wrong ttyUSB for data,
and I believe I know why this happens; we're mixing up the
huawei-specific GETPORTMODE logic with the additional generic udev
rules for huawei modules:

(/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1)
tty/ttyUSB1 at (primary)
(/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1)
tty/ttyUSB1 data (primary)
(/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1)
tty/ttyUSB2 data (secondary)
(/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1) tty/ttyUSB0 qcdm

Here ttyUSB1 shouldn't have been flagged as "data".

I wish we had unit tests for all this setup, I may work on adding
those sometime in the future.

But meanwhile, would it be too much to ask a remote ssh access to a
system with this device plugged in? I'd like to manually test the
huawei plugin changes with the real device. If possible, email me
privately.

Also, are you using this device in your own custom system? This device
has a NET port and should be NDISDUP capable, so you should definitely
use that for a better connection support. If you are building your own
custom system, make sure you enable the "huawei cdc ncm" kernel driver
in the build. Once that is available, and the kernel exports a
cdc-wdm+net pair, ModemManager will use them right away.

-- 
Aleksander
https://aleksander.es


More information about the ModemManager-devel mailing list