Huawei me906s-158

Bjørn Mork bjorn at mork.no
Wed Apr 6 11:00:13 UTC 2016


Andreas Fett <andreas.fett at secunet.com> writes:
> On 04/04/16 16:38, Bjørn Mork wrote:
>> This makes sense even if the USB captures don't show any other
>> differences.  The firmware might assume that the configuration always
>> switches from 0 to either 1, 2 or 3 and then stays there.  That's what
>> would happen on a Windows system.  There are most likely a number of
>> internal firmware settings associated with such configuration switches.
>> Failure to reset them could very well mess up things beyond rescue.
>
> Attached there is a usb capture of the following:
>
> System (cold) boots with /sys/bus/usb/devices/1-2/bConfigurationValue of
> "2".
>
> echo 0 > /sys/bus/usb/devices/1-2/bConfigurationValue
> echo 3 > /sys/bus/usb/devices/1-2/bConfigurationValue
>
> cdc_mbim is loaded via udev and attaches.
>
> echo Y > /sys/class/net/wwan0/cdc_mcn/ndp_to_end
>
> start ModemManager
>
> Unlock pin via mmcli
> Simple connect via mmcli

Thanks.  Will take a look to see if there is something bloddy obvious I
am missing.  But I don't really expect to find anything.  It is not an
unreasonable assumption that the firmware supports transitions from cfg
0 to 1,2, or 3, but no other transition.  Except maybe back to 0,
although that might add other constraints.  Like:

> I'm still experimenting with doing the configuration value switch via
> udev but there also seem to be some timing issues involved...

Yes.  The firmware will probably change a number of settings, start and
stop applications, and maybe even reboot one or more of the CPUs it
manages whenever you change configurations.  It is very likely that the
firmware needs some time to settle between each transition, without
having any way to signal that to the host.

So your best option at the moment is probably to run a script from udev
using delays tuned to whatever seems to work.

I'm thinking about ways this could be solved in the kernel.  We really
should not do the initial switch from cfg #0 there.  But that code has
been there forever.  Changing it is bound to break stuff for someone.
Even a quirk for this specific device will probably be an unexpected
change for anyone using the modem in the "Linux default" configuration.

Will try to figure something out and ask the Linux USB experts.


Bjørn


More information about the ModemManager-devel mailing list