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

["Pasi Kärkkäinen" <pasik-X3B1VOXEql0@public.gmane.org>]

On Mon, Mar 17, 2014 at 01:59:19PM +0200, Pasi Kärkkäinen wrote:
> On Mon, Mar 17, 2014 at 12:31:53PM +0100, Bjørn Mork wrote:
> > Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> 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.. 
> 

After playing with it for a while I got this:

[ 1082.972880] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: dwNtbInMaxSize=262144 dwNtbOutMaxSize=32768 wNdpOutPayloadRemainder=2 wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
[ 1082.972893] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: Using default maximum receive length=32768
[ 1082.973281] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: Setting NTB format to 16-bit failed

.. which looks to be related..


-- Pasi

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html