netdev - Re: Is this 32-bit NCM?

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.03.1411271932510.1548@gmail.com>
Date:	Thu, 27 Nov 2014 19:34:46 +0100 (CET)
From:	Enrico Mioso <mrkiko.rs@...il.com>
To:	Alex Strizhevsky <alexxst@...il.com>
cc:	Bjørn Mork <bjorn@...k.no>,
	ShaojunMidge.Tan@...iocodes.com, Mingying.Zhu@...iocodes.com,
	youtux@...il.com, linux-usb@...r.kernel.org,
	netdev@...r.kernel.org, Eli.Britstein@...iocodes.com
Subject: Re: Is this 32-bit NCM?

What I suspect, is that all this mess started when Huawei introduce new 
firmware releases that changed something in the IPV6 support.
Bjorn - do you remember when a guy called Thomas reported us a problem about an 
LTE huawei modem that wasn't working with huawei_cdc_ncm?
And you then discovered the problem was originated from some changes in the 
ordering of cdc_ncm actions; what happened then?
Did Thomas get his modem back to working state?
Sorry Thomas - you wilol read this message but I don't remember your surname, 
and might get confused with other people called Thomas.

On Thu, 27 Nov 2014, Alex Strizhevsky wrote:

==Date: Thu, 27 Nov 2014 13:36:37
==From: Alex Strizhevsky <alexxst@...il.com>
==To: Bjørn Mork <bjorn@...k.no>, ShaojunMidge.Tan@...iocodes.com,
==    Mingying.Zhu@...iocodes.com
==Cc: Enrico Mioso <mrkiko.rs@...il.com>, youtux@...il.com,
==    linux-usb@...r.kernel.org, netdev@...r.kernel.org,
==    Eli.Britstein@...iocodes.com
==Subject: Re: Is this 32-bit NCM?
==
==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
==
==
==
==