| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20140317124555.GL3200@reaktio.net> Date: Mon, 17 Mar 2014 14:45:55 +0200 From: Pasi Kärkkäinen <pasik@....fi> To: Bjørn Mork <bjorn@...k.no> Cc: Dan Williams <dcbw@...hat.com>, netdev@...r.kernel.org, linux-usb@...r.kernel.org, Enrico Mioso <mrkiko.rs@...il.com>, Oliver Neukum <oliver@...kum.org> Subject: Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem 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@....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.. > 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 netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists