Differences and handling of Huawei MU609 old and new versions

[Dan Williams]

On Wed, 2016-03-02 at 14:28 +0100, Yegor Yefremov wrote:
> Hi Bjørn,
> 
> On Wed, Mar 2, 2016 at 1:27 PM, Bjørn Mork <bjorn at mork.no> wrote:
> > 
> > Yegor Yefremov <yegorslists at googlemail.com> writes:
> > 
> > > 
> > > One of our customers came upon a Huawei MU609 card with IDs
> > > 12d1:1506.
> > > Below is lsusb -t output for this card:
> > > 
> > > # lsusb -t
> > > /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p,
> > > 480M
> > >     |__ Port 1: Dev 2, If 0, Class=, Driver=usb-storage, 480M
> > > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p,
> > > 480M
> > >     |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
> > >         |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 12M
> > >         |__ Port 2: Dev 4, If 0, Class=, Driver=usb-storage, 480M
> > >         |__ Port 3: Dev 8, If 0, Class=, Driver=option, 480M
> > >         |__ Port 3: Dev 8, If 1, Class=, Driver=option, 480M
> > >         |__ Port 3: Dev 8, If 2, Class=, Driver=option, 480M
> > >         |__ Port 3: Dev 8, If 3, Class=, Driver=option, 480M
> > >         |__ Port 3: Dev 8, If 4, Class=, Driver=option, 480M
> > 
> > This is missing the interface class info, so it is impossible to
> > say if
> > that driver attachment is correct or no.
> > 
> > > 
> > > So far mmcli couldn't detect this card as a modem. In this
> > > document
> > > [1] is stated, that this is an old version of MU609. What is the
> > > difference between them? Does the old MU609 provide  cdc_ether
> > > interface?
> > There is no direct relationship between device name, device ID and
> > functions for Huawei devices. But they appear to maintain a strict
> > class/subclass/protocol to function mapping.
> > 
> > I cannot answer the questions based on the available information.
> I don't have the card at hand, so will try to get "lsusb -v" info.
> 
> > 
> > > 
> > > Btw. I have encountered problems  [2] with the latest
> > > usb_modeswitch_data version and bot MU609 new and ME909. Could
> > > you
> > > also take a look at it?
> > I'm not sure I understand what the problem is.  There isn't much
> > information here.
> Do you have one of these cards, so that you could try them with the
> latest usb_modeswitch_data package
> (http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-data-201601
> 12.tar.bz2)?
> 
> This package has following file since 20151101:
> 
> usb_modeswitch.d/12d1:1573
> 
> with following content:
> 
> # Huawei ME909u-521
> Configuration=1
> 
> Below - corresponding entry in the ChageLog file:
> 
> 20151101:
>     Added devices: Huawei ME909u-521 [12d1:1573], Huawei E327s-150
> (Variant)
>     [12d1:1597], Huawei E3531s-2, E3131 (Variant) [12d1:15ce], Huawei
> E3131
>     (Variant) [12d1:15d0], Huawei E3531 (Variant) [12d1:15d2],
> Novatel U620L
>     [1410:9020], Novatel U620L [1410:9022], ZTE MF820s, MF832s
> [19d2:0198],
>     ZTE MF195E [19d2:1580]; some new target IDs added to existing
> device
>     configs; small correction of Makefile to fix Debian bug #803603
> 
> Downgrading this package to the version before 20151101 solves the
> problem, i.e. usb_modeswitch doesn't interfere with the modem and I
> get all needed interfaces inclusive cdc_ether one and ModemManager is
> also happy.

FWIW, both my Huawei E398 and E392 (which are supposed to be QMI-based
devices) now only bind to 'option' and I get no QMI :(

This is with a fairly recent usb_modeswitch.  It seems that
usb_modeswitch's driver force binding is buggy again.  ISTR it waits a
few seconds for the kernel driver to bind, and if that doesn't happen
within the timeout it will force-bind 'option' to all ports.

I replaced the string "option" and "option1" in
/usr/sbin/usb_modeswitch_dispatcher with garbage and replugged my E398,
and guess what?  Everything works now!

I am using 20151101 modeswitch data and usb_modeswitch 2.2.5, but even
2.3.0 doesn't fix this problem.

Dan