Differences and handling of Huawei MU609 old and new versions

Wed Mar 2 14:27:38 UTC 2016

Yegor Yefremov <yegorslists at googlemail.com> writes:
> 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-20160112.tar.bz2)?

Nope.  The only Huawei modems I have are E367, E392 and ME936.  I don't
think any of them are similar to the MU609 or ME909.  But it's really
not relevant in any case.  These things differ between firmware
versions, market regions, moon phase etc.  Which is precisely the
problem, I believe. The problematic usb_modeswitch version makes generic
assumptions based on a single specific sample.

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

Then I assume cdc_ether is in a configuration != 1 in your firmware.

I don't know the background of that particular change.  But it does
indeed look bogus.  We should not make assumtions about particular
configuration numbers on any Huawei device.  Those numbers are allocated
dynamically by the firmware, and I don't think there are any rules for
which functions will be available in any specific configuration.  The
rule is:  It depends.

So, like previously discussed in the context of MBIM support in some
non-default config, what you want usb_modeswitch to do is to select the
configuration with a particular function (or set of functions).
Unfortunately I don't think you can express that to usb_modeswitch at
the moment.  But I believe most of the necessary functionality is
already there, so it is probably a reasonably cheap feature to add.  I
suggest adding it to the feature wishlist.

As for MM:  Yes, I guess it should still recognize this modem even if it
is configured for serial functions only. But you don't really want to
use it like that, so it's actually better to have this end up as a
failure ;)

Your best bet is probably to add a temporary configuration override in
/etc/usb_modeswitch.d/12d1:1573 until the bug is fixed upstream.  But
you'll have to provide more info there before anyone will understand the
problem. The "lsusb -vd 12d1:1573" output should explain it.  Or even
better, since it is more compact: The 12d1:1573 section of
/sys/kernel/debug/usb/devices (if you have debugfs enabled and mounted)

Maybe someone(tm) should review the current usb_modeswitch database for
similar bogus assumptions?  I don't think there are many devices, if
any, where you can say things like "Configuration=x" and be correct.  In
the common database, that is.  Being able to specify "Configuration=x"
in a local usb_modeswitch config file for your specific modem is
sometimes useful.

Bjørn