problems with huawei E3372 alias Telekom Speedstick V

[Bjørn Mork]

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

> Am Montag, 1. September 2014, 10:59:55 schrieben Sie:
>
>
> Thanks a lot so far...!!!!
>
>>  grep . /sys/class/net/wwan0/cdc_ncm/*
>> 
> hpmini:/sys/class/net/wwan0/cdc_ncm # grep . *
> bmNtbFormatsSupported:0x0003
> dwNtbInMaxSize:131072
> dwNtbOutMaxSize:16384
> min_tx_pkt:14848
> rx_max:16384
> tx_max:16384
> tx_timer_usecs:400
> wNdpInAlignment:4
> wNdpInDivisor:4
> wNdpInPayloadRemainder:2
> wNdpOutAlignment:4
> wNdpOutDivisor:4
> wNdpOutPayloadRemainder:2
> wNtbOutMaxDatagrams:0
> hpmini:/sys/class/net/wwan0/cdc_ncm # 

Yes, that looks good.  The 0x0003 shows us and the driver that this
device supports both 16bit and 32bit headers, and the driver will
explicitly configure it for 16bit.  Should be fine.

Hmm, as expected this device have an insanely huge dwNtbInMaxSize, which
we reduce to a more appropriate 16k rx_max.  This should not cause
problems, and it seems to work fine for other Huawei devices, but you
never know...

Can't remember seeing non-zero PayloadRemainders before, but that's
probably just because I haven't seen them from many devices at all.
This debug facility is after all brand new :-) And 2 does sort of make
sense for NCM since it uses ethernet frames.  Except that we do modify
it, taking ETH_HLEN into account, so we end up using 0 here as
well. Maybe that causes problems? Or maybe not.  It's kind of a long
shot and I don't see why this device should be any different than other
Huawei devices.


>> 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?
>
> The plug/unplugged version is attached. But here I don't find the dhcp-
> request. Maybe you find the urb you missed.
>
> The attachment contains two linux-traces,  for windows it was to late tonight.

No need for the Windows one I believe.  It will be different because
Windows use 32bit headers.  I just wanted to verify that we do
everything correct here, and it seems we do.

There's the USB_CDC_GET_NTB_PARAMETERS request (returning the struct
decoded above):

URB setup
    bmRequestType: 0xa1
        1... .... = Direction: Device-to-host
        .01. .... = Type: Class (0x01)
        ...0 0001 = Recipient: Interface (0x01)
    bRequest: 128
    wValue: 0x0000
    wIndex: 2
    wLength: 28

USB_CDC_SET_CRC_MODE (off):

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


USB_CDC_SET_NTB_FORMAT (16bit):

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


And then we do SET INTERFACE etc.  Looks all good to me.  So why doesn't
it work? Any suggestions are appreciated...  We could start making the
framing look more like what the Windows driver does, but it will be a
lot of work and I don't know if there are any reasons to expect it to
matter. 


Bjørn