Help on an invalid modem case

[Aleksander Morgado]

Hey Lars,

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

Yes, that is what I also expected:
      USB if#2 ---> ttyUSB0 ---> ff/1/3
      USB if#3 ---> ttyUSB1 ---> ff/1/2  --> Primary
      USB if#4 ---> ttyUSB2 ---> ff/1/1  --> PPP

But GETPORTMODE returns the following, looks like the interface
numbers are off by one, which is why ttyUSB1 also gets flagged as PPP:
      ^getportmode:type:WCDMA:Qualcomm,NDIS:0,DIAG:1,PCUI:2,MDM:3,SD:4<CR><LF><CR><LF>OK<CR><LF>

At this point, both methods are applying their own logic to tag ports,
so we end up with ttyUSB1 as primary+ppp and ttyUSB2 as ppp.

-- 
Aleksander
https://aleksander.es