Huawei me906s-158

[Bjørn Mork]

Andreas Fett <andreas.fett at secunet.com> writes:

> Hi,
>
> On 03/03/16 16:06, Bjørn Mork wrote:
>> Looks like there is some credential problem accessing the mbim-proxy. No
>> MBIM commands are ever sent to the modem, so we don't know if that works
>> or not.
>> 
>
> Sorry, maybe I'm mistaken, but I don't really think that this is an
> issue with the proxy. The proxy just doesn't respond as long as the
> modem cannot be contacted.

You're right.  It's just me not understanding how the proxy works.

> I did a test without a running ModemManger and without the proxy, just
> using mbimcli with option --query-device-caps and giving it the device
> node. I double checked that no other process accessed the same device node.
>
> strace showed that the device node (/dev/cdc-wdm0) is opened
> successfully and the command that appears in the debug output
> is written to the device. There is just no answer (ie poll() returns
> timeouts for the fd) and after a couple retries it gives up.
>
> Using usbmon (see attached log) I could see that those commands are
> actually submitted to the USB bus. The modem seems to respond by sending
> back an URB but that doesn't seem to be the expected answer. However
> apart from understanding the addressing on the bus I can't really make
> much of it.

It's considerably easier to use capture with libpcap and use wireshark
to analyze the captures, since it will dissect most of it for you.

Do something like 'tshark -w /tmp/foo.pcap -i usbmon1' to capture on USB
bus 1 (for example).

There aren't any responses at all in that capture.  There is one
interrupt URB being submitted, returning an initial EINPROGRESS (normal)
before it fails with ENOENT, which just means that it was killed
(probably because the application gave up):

> ffff88041bb8e3c0 3044646844 S Ii:1:003:2 -115:16 16 <
> ffff88041bb8e3c0 3074687255 C Ii:1:003:2 -2:16 0

The rest of the dump are all control out MBIM OPENs.

So you are completely correct:  The MBIM control channels seems dead.

Don't know what we can do about that.  If you have Windows, and it uses
MBIM, then it would be very useful to get a dump of that (use the open
source http://desowin.org/usbpcap/ tool).  Otherwise we might be able to
guess something from a USB capture showing the setup phase when the
driver probes and initializes the MBIM function,



Bjørn