| 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: <20140317115919.GK3200@reaktio.net> Date: Mon, 17 Mar 2014 13:59:19 +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 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.. > > > Bjørn Thanks, -- 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