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