| 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: <87k3btm57a.fsf@nemi.mork.no> Date: Mon, 17 Mar 2014 12:31:53 +0100 From: Bjørn Mork <bjorn@...k.no> To: Pasi Kärkkäinen <pasik@....fi> 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 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). 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... 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. 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? Bjørn -- 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