Help on an invalid modem case

[Louis-Alexis Eyraud]

Hey again Aleksander,

I tried the udev rules you suggest and the serial timeouts occurrences disappear for the device.
Even if the attached log don't show it, the device got connected to the network after multiple attempts. The connection is stable and functional now (over half an hour when I'm writing this).

I also tried with another 3G modem (Huawei 3372h-156) that has the same pid/vid after usbmode switch actions but it now shows serial timeouts too. It was not the case before.

For a remote access to a setup, I ask my company to retrieve this device next time I go to the office.
So I would probably able to have a less custom and specific setup for test purposes in the coming days.

Regards,
Louis-Alexis

________________________________
From: Aleksander Morgado <aleksander at aleksander.es>
Sent: 06 July 2020 14:51
To: Louis-Alexis Eyraud <louis-alexis.eyraud at sigfox.com>
Cc: ModemManager (development) <modemmanager-devel at lists.freedesktop.org>
Subject: Re: Help on an invalid modem case

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faleksander.es%2F&data=02%7C01%7Clouis-alexis.eyraud%40sigfox.com%7Ca55481ce117f4032fa3408d821ab46b3%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637296366795739379&sdata=KZivrxLU0nBPb9HznG3sB%2BHUBtKlx1hOZl8PQ6ygll8%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20200706/6aff527b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ley_mmdebug_3.log
Type: text/x-log
Size: 257228 bytes
Desc: ley_mmdebug_3.log
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20200706/6aff527b/attachment-0001.bin>