Help on an invalid modem case

[Lars Melin]

On 7/6/2020 18:10, Aleksander Morgado wrote:
> 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.
> 

Hi,
the protocol value from the interfaces tells their intended usage so 
from the submitted verbose lsusb listing we get:

MI_00 qmi ctrl
MI_01 qmi data
MI_02 diag
MI_03 pcui
MI_04 modem

cheers
Lars