| 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: <alpine.LNX.2.03.1411280944200.4040@gmail.com> Date: Fri, 28 Nov 2014 09:45:10 +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? To test our 32-bit driver, you need at least Ubuntu 14.04 and install the 3.16 kernel; or install a kernel >= 3.16 anyway, as our modification is based on the cdc_ncm.c file from the git tree for logical reason. On Fri, 28 Nov 2014, Kevin Zhu wrote: ==Date: Fri, 28 Nov 2014 09:37:30 ==From: Kevin Zhu <Mingying.Zhu@...iocodes.com> ==To: Enrico Mioso <mrkiko.rs@...il.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? == ==As the remainder (wNdpOutPayloadRemainder) is overwritten by the ==following lines, whose finally value is 0, I modified the code not to ==change it. Let it remain 2. And now the capture shows the Ethernet ==header offset is the same as windows, however, it's not working yet. == == /* adjust TX-remainder according to NCM specification. */ == ctx->tx_remainder = ((ctx->tx_remainder - eth_hlen) & == (ctx->tx_modulus - 1)); == == ==Regards, ==Kevin == ==On 11/28/2014 04:24 PM, Enrico Mioso wrote: ==> 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 ==> == ==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