Help on an invalid modem case

[Aleksander Morgado]

Hey again,

> > 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.
>

It looks like the GETPORTMODE reply is the one that may be wrong.

Could you edit the /lib/udev/rules.d/77-mm-huawei-net-port-types.rules
file and add a line like this one after the
"LABEL="mm_huawei_port_types"" line?

ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506",
ENV{ID_MM_HUAWEI_DISABLE_GETPORTMODE}="1"

Once the line is added, run:
$ sudo udevadm control --reload
$ sudo udevadm trigger

And restart ModemManager in debug mode (and retry the
connection/disconnection sequence)

-- 
Aleksander
https://aleksander.es