| 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
| ||
|
Date: Fri, 28 Nov 2014 09:24:25 +0100 (CET) From: Enrico Mioso <mrkiko.rs@...il.com> To: Kevin Zhu <Mingying.Zhu@...iocodes.com> cc: Alex Strizhevsky <alexxst@...il.com>, Bjørn Mork <bjorn@...k.no>, Midge Shaojun Tan <ShaojunMidge.Tan@...iocodes.com>, "youtux@...il.com" <youtux@...il.com>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Eli Britstein <Eli.Britstein@...iocodes.com> Subject: Re: Is this 32-bit NCM? The driver effectively uses the wNdpOutDivisor indirectly - see standard cdc_ncm deriver as in kernel git tree, line 490. On Fri, 28 Nov 2014, Kevin Zhu wrote: ==Date: Fri, 28 Nov 2014 07:24:49 ==From: Kevin Zhu <Mingying.Zhu@...iocodes.com> ==To: Alex Strizhevsky <alexxst@...il.com>, Bjørn Mork <bjorn@...k.no>, == Midge Shaojun Tan <ShaojunMidge.Tan@...iocodes.com> ==Cc: Enrico Mioso <mrkiko.rs@...il.com>, "youtux@...il.com" <youtux@...il.com>, == "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, == "netdev@...r.kernel.org" <netdev@...r.kernel.org>, == Eli Britstein <Eli.Britstein@...iocodes.com> ==Subject: Re: Is this 32-bit NCM? == ==Hi all, == ==I'm able to get the following prints with the original huawei_cdc_ncm driver ==from Ubuntu 12.04.3. It keeps on printing. I'm also able to get an IP, but ==no Internet access. == ==^HCSQ:"WCDMA",64,59,55 == ==^DSFLOWRPT:0000000E,00000000,00000000,0000000000000000,0000000000000000,000 ==00000,00000000 == ==OK == ==^NDISSTAT:1,,,"IPV4" == ==^STIN: 1, 0, 0 == ==^DSFLOWRPT:00000010,00000000,00000000,0000000000000000,0000000000000000,000 ==00000,00000000 == ==^DSFLOWRPT:00000012,00000000,00000000,0000000000000000,0000000000000000,000 ==00000,00000000 == ==^DSFLOWRPT:00000014,00000000,00000000,0000000000000000,0000000000000000,000 ==00000,00000000 == ==^STIN: 1, 0, 0 == == ==... ==^STIN: 1, 0, 0 == ==^DSFLOWRPT:0000008C,00000000,00000000,0000000000000B36,0000000000000000,000 ==00000,00000000 == ==^DSFLOWRPT:0000008E,00000000,00000000,0000000000000B36,0000000000000000,000 ==00000,00000000 == ==Regarding the alignment, I think we have some difference between Windows and ==Linux. The spec says it should satisfy the following constraint. == ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams) == ==It seems the Huawei device take the NDP offset (Ethernet Header Offset) as ==the parameter 'Offset' in the above constraint. And in the Linux capture, it ==does not comply with it. == == ==dwNtbInMaxSize=131072 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=2 ==wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f == ==Windows: == ==0000 6e 63 6d 68 10 00 b6 00 7c 00 00 00 5c 00 00 00 ncmh....|...\... ==0010 00 00 00 00 00 00 00 00 00 1e 10 1f 00 00 08 00 ................ ==0020 45 00 00 3c 00 9b 00 00 80 01 a0 fe 0a 71 a3 0e E..<.........q.. ==0030 ca 6c 21 3c 08 00 4b 4b 00 01 02 10 61 62 63 64 .l!<..KK....abcd ==0040 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst ==0050 75 76 77 61 62 63 64 65 66 67 68 69 6e 63 6d 30 uvwabcdefghincm0 ==0060 20 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 ............... ==0070 4a 00 00 00 00 00 00 00 00 00 00 00 J........... == ==Linux: (thought it's a 16bit format capture, but it's the same as 32bit, ==regarding the alignment) == ==0000 4e 43 4d 48 0c 00 40 00 e2 00 0c 00 4e 43 4d 30 NCMH..@.....NCM0 ==0010 10 00 00 00 b8 00 2a 00 00 00 00 00 00 00 00 00 ......*......... ==0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ==0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ==0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ==0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ==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 ff ff ff ff ff ff 00 1e ................ ==00c0 10 1f 00 00 08 06 00 01 08 00 06 04 00 01 00 1e ................ ==00d0 10 1f 00 00 0a 71 cc a6 00 00 00 00 00 00 70 50 .....q........pP ==00e0 f8 49 .I == == ==Regards, ==Kevin ==On 11/27/2014 08:36 PM, Alex Strizhevsky wrote: == Adding my colleagues - Eli, Kevin & Midge. == ==Any ideas are welcome ;) == == ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn@...k.no> wrote: == Enrico Mioso <mrkiko.rs@...il.com> writes: == == > Ok - we can arrive to some ocnclusions regarding the == E3272. == > First of all - the modem seems buggy enough to not be == able to handle requests == > for different formats. You need to unplug and re-plug == it, but this is onlyan == > impression and is reasonable. == > == > Then - the modem will accept to ndisdup the connection == with == > at^ndisdup=1,1,"internet" == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow == handling messages and == > the modem stops here. == > If we use the cdc_ncm 32-bit driver (modified) we get == lotfs of == > ^dsflorpt == > that's how it should be. == > So I think we can say that something is changing. == > Then there's the alignment problem you mentioned in your == previous reply. And == > this is hard to solve. == > could you try to help me understand where the problem == is? == > I feel like we are very close to the solution but == something isn't working. == > Or might be just try to change the 16 bit driver? == ==If you use a recent version of the driver as a basis, then you ==get the ==CDC NCM NTB parameters in sysfs (if not, then you need to enable ==debugging and look in the log for these values). For example: == ==bjorn@...i:~$ grep . /sys/class/net/wwan0/cdc_ncm/* ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001 ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360 ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360 ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824 ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360 ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360 ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400 ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4 ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1 ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0 ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32 == == ==The possible problem I am thinking of is proper handling of the ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet ==Frame ==Alignment" in the spec. Which is confusing as hell, but if I ==understand ==it correctly then we are supposed to align the start of the IP ==packets ==(the "payload", _not_ the ethernet frame) to a whole ==wNdp*Divisor number ==as long as the wNdp*PayloadRemainder is 0. == == ==Bjørn == == == ==This email and any files transmitted with it are confidential material. They ==are intended solely for the use of the designated individual or entity to ==whom they are addressed. If the reader of this message is not the intended ==recipient, you are hereby notified that any dissemination, use, distribution ==or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the ==sender and delete or destroy any copy of this message ==
Powered by blists - more mailing lists