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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 28 Nov 2014 08:37:30 +0000
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