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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Fri, 28 Nov 2014 07:40:11 +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?

Ok.

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
==
This is a clear indication of success from your side - in the sense that you 
where able to ask the modem to connect, and get it connected.
Any time you see messages regarding the flow, then it's ok.
Thank you for your great job guys.
Now - can you try to patch the cdc_ncm.c 16 bit driver to respect this 
alignment and see what's wrong with it?
I will also take a look at it, but I am not so sure to succeed in doing so. But 
I'll re-read all when arrived in university.
Enrico

==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