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  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 <>
To:	Bjørn Mork <>
cc:	Alex Strizhevsky <>,,,,,,
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 

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

==Date: Fri, 28 Nov 2014 10:29:09
==From: Bjørn Mork <>
==To: Enrico Mioso <>
==Cc: Alex Strizhevsky <>,,
==Subject: Re: Is this 32-bit NCM?
==Enrico Mioso <> 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 <>
==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 <>
==    Reported-by: Thomas Schäfer <>
==    Signed-off-by: Bjørn Mork <>
==    Signed-off-by: David S. Miller <>
View attachment "m3" of type "TEXT/PLAIN" (78350 bytes)

Powered by blists - more mailing lists