Huawei me906s-158

[Bjørn Mork]

Andreas Fett <andreas.fett at secunet.com> writes:
> On 10/03/16 18:39, Bjørn Mork wrote:
>> Andreas Fett <andreas.fett at secunet.com> writes:
>>> I still have to load the mbim_module manually and sometimes I'm able to
>>> "talk" to it. I have no clue which factors lead to success or failure here.
>> 
>> Huh?  Why do you need to load cdc_mbim manually?  Doesn't it autoload
>> when the modem is switched to the MBIM configuration? Or is the probe
>> failing at this time?
> The autoload works just fine. It's just that the xhci module is loaded
> in the initramfs where the cdc_mbim module is not available and I
> disabled the "udevadm trigger" later on to prevent interference of other
> modules.
>
>> Well, a couple of more things to try out if you are able to connect
>> again:
>> 
>> 1) move the NDP
>> 
>> With a v4.5 kernel you will have a "ndp_to_end" sysfs attribute.  Try
>> toggling it on and see if that makes any difference:
>> 
>>  echo Y >/sys/class/net/wwan0/cdc_ncm/ndp_to_end
>> 
>> You can do this after connecting if you want to.  The driver will enable
>> it immediately for the rest of the session.
> I had one boot now where the modem responded and this actually made it
> fully functional, that is I could get a ping across it after connecting
> and assigning the ip address.

Great! Thanks for verifying that.  We'll add a quirk for it then, so
this setting becomes the default. I guess it's time to reconsider
applying that quirk to all Huawei modems.


>> 2) DHCP
>> 
>> You should also try using a DHCP client instead of manual IP
>> configuration.  Some firmwares can be a bit difficult about this,
>> although I don't think we have seen that with MBIM yet.  Mostly worth
>> trying because it is easy to test. Not really believing it will work :)
> When the modem responds I can do dhcp on it. I then get the same
> address information ModemManager reports. I'm not sure if this is
> required though.
>
> To sum up, when the modem comes to a state where it will respond
> to mbimcli --query-device-caps it seems to be operational (after setting
> the cdc_ncm sysctl). If I can't talk to it using mbimcli it's just
> totally silent and it seems to me that only a cold reset (as opposed to
> a reboot) will get it out of that state.
>
> However up to now its only about one in ten boots (using the same image)
> where this works.

So this appears as if the modem firmware has suspended its USB
connection.  I have a feeling there is some USB low power mode or
suspend feature I am missing here.  I don't really have any experience
with xhci or USB3, and there are a few new power knobs there.  This
should of course just work and not really depend on specific USB devices
or device drivers, but who knows?  Not me at least.  I don't think it's
something we can fix in the cdc_mbim driver in any case.

You said earlier that it made a difference when you disabled or enabled
autosuspend?  The modem needed autosuspend to work?  That's strange.

I went back to your lsusb output to see if I could see anything strange
wrt the LPM settings, but the whole dump was strange..  Did you use a
very old lsusb version?  The device says

 bcdUSB               2.10

so it must have a BOS descriptor.  And AFAICS, BOS descriptor dump for
USB 2.1 was added in usbutils v006.  The MBIM functional descriptors
weren't decoded either, but that wasn't added before v007.

If the device really doesn't have a BOS descriptor then I guess all the
fancy-schmancy USB3 LPM stuff is disabled anyway.  But it would be good
to know.

Do you see any *lpm* attributes in the USB device power sysfs group?
What's the output of

 grep . /sys/bus/usb/devices/1-3/power/*


Is there any noticable differences between the working and non-working
states?



Bjørn