On Fri, 30 Jul 2021 at 12:42, Loic Poulain <loic.poul...@linaro.org> wrote:
>
> On Fri, 30 Jul 2021 at 12:18, Aleksander Morgado
> <aleksan...@aleksander.es> wrote:
> >
> > Hey,
> >
> > > The change I made is for cinterion plugin only:
> > > diff --git a/plugins/cinterion/mm-plugin-cinterion.c
> > > b/plugins/cinterion/mm-plugin-cinterion.c
> > > index 48fbb1ac..fe97f900 100644
> > > --- a/plugins/cinterion/mm-plugin-cinterion.c
> > > +++ b/plugins/cinterion/mm-plugin-cinterion.c
> > > @@ -181,9 +181,9 @@ grab_port (MMPlugin *self,
> > > G_MODULE_EXPORT MMPlugin *
> > > mm_plugin_create (void)
> > > {
> > > - static const gchar *subsystems[] = { "tty", "net", "usbmisc", NULL };
> > > + static const gchar *subsystems[] = { "tty", "net", "usbmisc",
> > > "wwan", NULL };
> > > static const gchar *vendor_strings[] = { "cinterion", "siemens",
> > > NULL };
> > > - static const guint16 vendor_ids[] = { 0x1e2d, 0x0681, 0 };
> > > + static const guint16 vendor_ids[] = { 0x1e2d, 0x0681, 0x1269, 0 };
> > > static const MMAsyncMethod custom_init = {
> > > .async = G_CALLBACK (cinterion_custom_init),
> > > .finish = G_CALLBACK (cinterion_custom_init_finish),
> > >
> > > The quectel plugins does not whitelist the 0x1269:
> > > [...]
> > > [5328]: <debug> [plugin-manager] loaded plugin 'quectel' from
> > > '/usr/lib/ModemManager/libmm-plugin-quect el.so'
> > > [5328]: <debug> [filter] registered plugin whitelist vendor id: 2c7c
> > > [5328]: <debug> [filter] registered plugin whitelist vendor id: 1eac
> > > [5328]: <debug> [plugin-manager] loaded plugin 'pantech' from
> > > '/usr/lib/ModemManager/libmm-plugin-pante ch.so'
> > > [...]
> > > [5328]: <debug> [plugin-manager] task 10,wwan0mbim0: found '3' plugins to
> > > try
> > > [5328]: <debug> [plugin-manager] task 10,wwan0mbim0: will try with plugin
> > > 'quectel'
> > > [5328]: <debug> [plugin-manager] task 10,wwan0mbim0: will try with plugin
> > > 'cinterion'
> > > [5328]: <debug> [plugin-manager] task 10,wwan0mbim0: will try with plugin
> > > 'generic'
> > > [...]
> > > So it's weird it matches the MV31-W modem
> >
> > Yes, this is very very weird, and something we'll need to fix at some
> > point. I'll try to see if I can find a reason for that.
> >
> > >
> > > I also tried using the mbimcli directly but it does not work as well:
> > > root@OpenWrt:~# mbimcli --query-device-caps -d /dev/wwan0mbim0 -v
> > > [30 Jul 2021, 06:19:33] [Debug] opening device...
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Couldn't query maximum
> > > message size: IOCTL_WDM_MAX_COMMAND failed: Not a tty
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Couldn't find
> > > descriptors file, possibly not using cdc_mbim
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Fallback to default max
> > > control message size: 4096
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Sent message...
> > > <<<<<< RAW:
> > > <<<<<< length = 16
> > > <<<<<< data = 01:00:00:00:10:00:00:00:01:00:00:00:00:10:00:00
> > >
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Sent message
> > > (translated)...
> > > <<<<<< Header:
> > > <<<<<< length = 16
> > > <<<<<< type = open (0x00000001)
> > > <<<<<< transaction = 1
> > > <<<<<< Contents:
> > > <<<<<< max control transfer = 4096
> > > [...]
> > > [30 Jul 2021, 06:19:59] [Debug] [/dev/wwan0mbim0] Sent message...
> > > <<<<<< RAW:
> > > <<<<<< length = 16
> > > <<<<<< data = 01:00:00:00:10:00:00:00:06:00:00:00:00:10:00:00
> > >
> > > [30 Jul 2021, 06:19:59] [Debug] [/dev/wwan0mbim0] Sent message
> > > (translated)...
> > > <<<<<< Header:
> > > <<<<<< length = 16
> > > <<<<<< type = open (0x00000001)
> > > <<<<<< transaction = 6
> > > <<<<<< Contents:
> > > <<<<<< max control transfer = 4096
> > >
> > > [30 Jul 2021, 06:20:04] [Debug] open operation timed out: closed
> > > error: couldn't open the MbimDevice: Operation timed out: device is close
> >
> > Maybe @Loic Poulain can spot something?
>
> Timeout usually happens when the mbim proxy is already running. So you
> should use -p option here, or stop the mbim proxy.
> Point is that if wwan port is opened by two different processes,
> you're not sure which one will read mbim reply, and you can end with
> timeout.
BTW, serial device tools usually rely on lock file to acquire a tty
dev (in /var/lock/), maybe we should do the same for mbim, and have
e.g. /var/lock/LCK..wwan0mbim0. I think issue is common to any mbim
(and qmi) implementation (WWAN, USB...).
>
> Regards,
> Loic
