Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

["Pasi Kärkkäinen" <pasik@iki.fi>]

On Mon, Mar 17, 2014 at 12:31:53PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen <pasik@iki.fi> writes:
> 
> > http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
> >
> > (I did move the dongle to a different usb bus nr 3 to make it the only device on that bus before capturing..) 
> 
> Thanks.  That helps.
> 
> > So what I did:
> >
> > - Start wireshark capture on USB bus nr 3.
> > - Plug in the Huawei E3276 dongle.
> > - Wait for usb_modeswitch to happen.
> > - Use minicom to talk to /dev/cdc-wdm0 and send AT commands to connect to Internet:
> > 	- ATQ0 V1 E1 S0=0
> > 	- AT^NDISDUP=1,1,"internet"
> >
> > - After the dongle has connected query for DHCP status:
> > 	- AT^DHCP?
> >
> > - Launch dhcp client (dhclient) on wwp0s20u1i1 interface.
> > - Wait for a while and see RX error counters increasing on ifconfig output.
> > - Cancel (ctrl+c) the dhclient.
> > - Stop wireshark capture. 
> >
> >
> > Does that capture file show anything interesting to you? 
> 
> I see two devices (excluding the root hub), both with a single
> configuration: 
>  12d1:14fe (addr: 4)
>  12d1:1506 (addr: 5)
> 
> The 12d1:14fe device is before mode switching, so I'll just ignore that
> and concentrate on the two modem interfaces of the 12d1:1506 device:
> 0 (serial, AT command) and 1 (NCM combined).
> 

Correct. 


> Possibly unrelated, but a bit unexpected:  I see a request for string
> descriptor 0xee, which is the "magic Microsoft descriptor".  I don't
> know of any Linux software requesting this by default.  Anyone else?
> The request results in a stall, so it's obviously unsupported by this
> devices and cannot possibly matter.  But I still wonder who sends it...
> 

Hmm.. no idea about that :) This is a pretty standard Fedora 20 box,
with no thirdparty software.. 


> 
> Anyway, I believe I can see the problem. Or some part of it.  I'm still
> not quite sure what the cause is.
> 
> If you look at the data sent by the driver to endpoint 0x02 (which is
> the endpoint used for NCM data from host to device), you'll see
> something like this:
> 
> 0040  4e 43 4d 48 0c 00 01 00 00 80 0c 00 4e 43 4d 30   NCMH........NCM0
> 0050  10 00 00 00 b8 00 56 01 00 00 00 00 00 00 00 00   ......V.........
> 0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00f0  00 00 00 00 00 00 00 00 ff ff ff ff ff ff 0c 5b   ...............[
> 0100  8f 27 9a 64 08 00 45 10 01 48 00 00 00 00 80 11   .'.d..E..H......
> 0110  39 96 00 00 00 00 ff ff ff ff 00 44 00 43 01 34   9..........D.C.4
> 0120  3a dd 01 01 06 00 ef 52 11 28 00 00 00 00 00 00   :......R.(......
> 0130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 5b   ...............[
> 0140  8f 27 9a 64 00 00 00 00 00 00 00 00 00 00 00 00   .'.d............
> 0150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0170  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0180  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0190  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01f0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0200  00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82   ..............c.
> 0210  53 63 35 01 01 37 0d 01 1c 02 79 0f 06 0c 28 29   Sc5..7....y...()
> 0220  2a 1a 77 03 3d 07 01 0c 5b 8f 27 9a 64 ff 00 00   *.w.=...[.'.d...
> 0230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0250  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 
> followed by lots of zero bytes because we pad to the max size.
> 
> Looking at the data receided from the device on endpoint 0x83 (which is
> used for data from device to host):
> 
> 0040  6e 63 6d 68 10 00 00 00 6e 00 00 00 10 00 00 00   ncmh....n.......
> 0050  6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00   ncm0 ...........
> 0060  32 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00   2...<...........
> 0070  00 00 ff ff ff ff ff ff 4c 54 99 45 e5 d5 08 06   ........LT.E....
> 0080  00 01 08 00 06 04 00 01 4c 54 99 45 e5 d5 0a 3d   ........LT.E...=
> 0090  8a 41 00 00 00 00 00 00 0a 3d 8a 48 00 00 00 00   .A.......=.H....
> 00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00         ..............
> 
> 
> The padding differences making the latter much more compact can be
> ignored.  But do notice the 'ncmh' != 'NCMH' and 'ncm0' != 'NCM0'.
> These are all standard NCM header and datagram signatures, but the lower
> and upper case versions have different meanings.  The lower case version
> means that the device use 32 bit length and index fields, while the
> driver use the variants with 16 bit fields.
> 
> This explains why the driver drops received frames.  It only supports
> the 16 bit variants.  They are mandatory according to the spec and the
> driver will never accept buffer sizes big enough for the 32 bit variants
> make a difference.  So adding support for the 32 bit versions has so far
> seemed pointless.
> 
> But here we have a device which does not comform to spec (that's OK,
> Huawei doesn't claim it does - this is a vendor specific function after
> all), and which seems to be locked to 32 bit mode?  Either it requires
> the 32 bit variant, or we are doing something "wrong" during setup to
> make the device go into this mode.
> 

Makes sense.. this seems like a good progress getting the "mystery" of this dongle solved.


> Adding 32 bit NCM support should be fairly easy after the changes we
> made to support MBIM.  But we need to know when to enable it, or whether
> we do something wrong during setup.  So it would be useful to see if the
> cdc_ncm_setup function logs any interesting debug messages.
> 
> Since you have dynamic debugging, could you do:
> 
>   mount -t debugfs none /sys/kernel/debug
>   echo "file cdc_ncm.c +fp" >/sys/kernel/debug/dynamic_debug/control
> 
> and then reconnect the device while capturing debug output?
> 

I just did:

# mount -t debugfs none /sys/kernel/debug
(well it was already mounted by fedora)

# cat /proc/sys/kernel/printk
4       4       1       7

# echo 8 > /proc/sys/kernel/printk
# cat /proc/sys/kernel/printk
8       4       1       7

# echo "file cdc_ncm.c +fp" >/sys/kernel/debug/dynamic_debug/control


And then I connected the dongle.. nothing in dmesg. I also tried changing the filename 
to huawei_cdc_ncm.c but that didn't produce any output either. 

I wonder if i'm missing some commands to get debug output to dmesg.. 

> 
> 
> Bjørn

Thanks,

-- Pasi