Help on an invalid modem case

[Louis-Alexis Eyraud]

Hi Aleksander,

sorry for the delay, I was on holiday the past weeks.
I've retrieved the "faulty" 3G modem device from my office. For information, the exact model is Huawei e352u-21 (other e352 variants I tested do not seem to provoke the issue).

I did a more standard setup at home to reproduce it: a RPI3 with Raspbian, ModemManager compiled from sources and various system configuration tweaks to force broadband management.
The setup also allowed me to verify that in CDC mode, it does not appear.

If you need to do some debug or test a fix for any of the two bugs you opened, feel free to contact me privately to give you access to this setup.

Regards,
________________________________
From: Aleksander Morgado <aleksander at aleksander.es>
Sent: 07 July 2020 08:44
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 Louis-Alexis,

>
> logs for the E3372h device.
>

in this case, we see two interfaces, and both flagged wrongly as PPP:

USB if#0 ---> ttyUSB0 ---> ff/2/18 ---> PPP
USB if#1 ---> ttyUSB1 ---> ff/2/1 ---> PPP

The reason for ttyUSB1 flagged as PPP is legit, that is ok, because
ff/2/1 implies being a data port. This flag is taken from udev rules.
The reason for ttyUSB0 flagged as PPP is not right, in this case the
flag is added due to this code:
        /* If GETPORTMODE unsupported and no other port type hints, we assume
         * usbif 0 is the modem port */
        if (usbif == 0) {
            at_port_flags = MM_PORT_SERIAL_AT_FLAG_PPP;
            goto next;
        }
We're wrongly assuming that there are no other port type hints,
because the hints are coming from udev ports in the generic plugin
code, not from huawei-specific port type hint logic. This is
definitely something to fix.

But anyway, I still believe we should be relying on GETPORTMODE for
all cases; i.e. I don't think we should flag GETPORTMODE as not being
supported for this vid:pid, we should probably improve the logic to
detect whether the NCM interface in GETPORTMODE is listed *before* the
TTYs, and if so, "count" the NCM interface as 2 interfaces, instead of
just one.

I've opened issues in gitlab for these:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmobile-broadband%2FModemManager%2F-%2Fissues%2F238&data=02%7C01%7Clouis-alexis.eyraud%40sigfox.com%7Ca8bf8c6cedec47ab0f6908d8224132b9%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637297010698419127&sdata=wbZCffn3SjZbx%2BU2MUwbWP67GMTgG2MvC1Y2O3W4QXE%3D&reserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmobile-broadband%2FModemManager%2F-%2Fissues%2F239&data=02%7C01%7Clouis-alexis.eyraud%40sigfox.com%7Ca8bf8c6cedec47ab0f6908d8224132b9%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637297010698419127&sdata=j6JOeMjB0aOwpLrf5FGjT86Jn6CSHvRDpKeaALmvE5U%3D&reserved=0

--
Aleksander
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faleksander.es%2F&data=02%7C01%7Clouis-alexis.eyraud%40sigfox.com%7Ca8bf8c6cedec47ab0f6908d8224132b9%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637297010698429118&sdata=VxiMDT3tsgAmZ8mP8WaQ3mBUH15IEv8icgD4D1mJaVU%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20200728/6a9de1f6/attachment.htm>