problems with huawei E3372 alias Telekom Speedstick V

[Bjørn Mork]

Thomas Schäfer <tschaefer at t-online.de> writes:

> Am Freitag, 29. August 2014, 11:16:01 schrieben Sie:
>> Not knowing much about the Windows USB stack I find these UsbSnoop
>> traces a bit difficult to decipher.  I recommend using USBPcap on
>> Windows - open source and much easier to analyze.
>
> Sorry for using not the right tool. Here is the trace from USBPcap.

Thanks. It's not that there is anything wrong with the other tools but
it's just a lot more convenient to have everything automatically
dissected when the protocol stack is as deep as it is here.

> The AT-commands are nice decoded. But the network-part is only for 
> professionals  with built  automagic hex-translation in the eyes :-)

Well, the thing I note with MBIM dissection enabled (which also does NCM
quite nicely) is that Windows use 32bit NCM headers while we use 16bit.
The 'ncmh' vs 'NCMH' signature difference you know from the last time I
messed up the NCM driver :-)

So what I am looking for, but am unable to find, is the command where we
are supposed to configure the device for 16bit headers.  This is the
command we sent out-of-order in v3.12. It is the USB_CDC_SET_NTB_FORMAT
control request which should look something like

URB setup
    bmRequestType: 0x21
        0... .... = Direction: Host-to-device
        .01. .... = Type: Class (0x01)
        ...0 0001 = Recipient: Interface (0x01)
    bRequest: 132
    wValue: 0x0000
    wIndex: 2
    wLength: 0


I wonder if we have a variant of the 3.12 NCM problem here.  The code
sending this depends on the USB_CDC_NCM_NTB32_SUPPORTED flag being set
in the NCM parameters.  If it's not, then we skip the format
configuration because we assume it's redundant.  Which should be safe
for any NCM spec conforming device.

But that's of course only valid for devices claiming to be NCM.  It has
so far worked for the Huawei vendor specific devices too, but maybe this
one is different?  There is something else odd going on here.  I cannot
see any USB_CDC_GET_NTB_PARAMETERS request either.  I wonder why?  Since
you are using a brand new kernel you can easily inspect the the NCM
parameters doing:

 grep . /sys/class/net/wwan0/cdc_ncm/*

This should print a line with "bmNtbFormatsSupported:0x0003" or similar
among other interesting data.

But we have to find out why these requests are missing from the snoops.
Is it just me not being able to see them?  Could you do a snoop of just
a driver unbind/bind?  Or maybe unplug/replug if that's simpler?



Bjørn