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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 30 Nov 2014 19:10:13 +0100 (CET)
From:	Enrico Mioso <mrkiko.rs@...il.com>
To:	Bjørn Mork <bjorn@...k.no>
cc:	Alex Strizhevsky <alexxst@...il.com>,
	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?

this is a capture equivalent to the m1 capture in the previous message; the 
E3251 modem is communicating us the arp traffic of the gateway asking who will 
have our IP in case of DHCP.
So you have some comparison.
See preivous mail in case.

Note: at^dialmode returns 3,2 in our case, which should be fine.
In the windows sniff it returned 1,2; however we are not allowed to change 
this.

On Fri, 28 Nov 2014, Bjørn Mork wrote:

==Date: Fri, 28 Nov 2014 10:29:09
==From: Bjørn Mork <bjorn@...k.no>
==To: Enrico Mioso <mrkiko.rs@...il.com>
==Cc: Alex Strizhevsky <alexxst@...il.com>, 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?
==
==Enrico Mioso <mrkiko.rs@...il.com> writes:
==
==> 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?
==
==yes, that bug was fixed by
==
==commit ff0992e9036e9810e7cd45234fa32ca1e79750e2
==Author: Bjørn Mork <bjorn@...k.no>
==Date:   Mon Mar 17 16:25:18 2014 +0100
==
==    net: cdc_ncm: fix control message ordering
==    
==    This is a context modified revert of commit 6a9612e2cb22
==    ("net: cdc_ncm: remove ncm_parm field") which introduced
==    a NCM specification violation, causing setup errors for
==    some devices. These errors resulted in the device and
==    host disagreeing about shared settings, with complete
==    failure to communicate as the end result.
==    
==    The NCM specification require that many of the NCM specific
==    control reuests are sent only while the NCM Data Interface
==    is in alternate setting 0. Reverting the commit ensures that
==    we follow this requirement.
==    
==    Fixes: 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
==    Reported-and-tested-by: Pasi Kärkkäinen <pasik@....fi>
==    Reported-by: Thomas Schäfer <tschaefer@...nline.de>
==    Signed-off-by: Bjørn Mork <bjorn@...k.no>
==    Signed-off-by: David S. Miller <davem@...emloft.net>
==
==
==
==Bjørn
==
View attachment "m3" of type "TEXT/PLAIN" (78350 bytes)