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

Message-ID: <alpine.LNX.2.03.1411301139290.1972@gmail.com>
Date:	Sun, 30 Nov 2014 11:39:53 +0100 (CET)
From:	Enrico Mioso <mrkiko.rs@...il.com>
To:	Alex Strizhevsky <alexxst@...il.com>
cc:	Eli Britstein <Eli.Britstein@...iocodes.com>,
	linux-usb@...r.kernel.org, "youtux@...il.com" <youtux@...il.com>,
	Midge Shaojun Tan <ShaojunMidge.Tan@...iocodes.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Kevin Zhu <Mingying.Zhu@...iocodes.com>,
	Bjørn Mork <bjorn@...k.no>
Subject: Re: Is this 32-bit NCM?

My impression guys is that this is not cdc_ncm protocol.
Look how many short packets you can see in there.
Without any ncm signature.
right?

On Sun, 30 Nov 2014, Alex Strizhevsky wrote:

==Date: Sun, 30 Nov 2014 05:22:20
==From: Alex Strizhevsky <alexxst@...il.com>
==To: Mrkiko Rs <mrkiko.rs@...il.com>
==Cc: Eli Britstein <Eli.Britstein@...iocodes.com>, linux-usb@...r.kernel.org,
==    "youtux@...il.com" <youtux@...il.com>,
==    Midge Shaojun Tan <ShaojunMidge.Tan@...iocodes.com>,
==    "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
==    Kevin Zhu <Mingying.Zhu@...iocodes.com>, Bjørn Mork <bjorn@...k.no>
==Subject: Re: Is this 32-bit NCM?
==
==
==Hi Enrico,
==
==Actually I have two dongles with different firmwares (23.128.00.00.00 &
==21.286.03.01.209).
==Probably have sent to you the USB  capture with the first one.
==
==In fact we have to make work the second one, this dongle has relevant SW.
==
==On Nov 30, 2014 3:13 AM, "Enrico Mioso" <mrkiko.rs@...il.com> wrote:
==      Hi guys.
==      Sorry for the late our but ... I was trying to figure out
==      something new about
==      this dongle.
==      I also searched for it in my city shops without finding it
==      actually.
==      But then I came back and ... tried to look at some things.
==
==      Alex, Kevin: in the Windows USB captures you sent me (and that I
==      sent on the
==      List), I can notiche something very strange.
==      with a shell on a computer connected to a test device I can see
==      the following:
==      at+gmr
==      21.286.03.01.209
==      OK
==      and so why in the Windows sniff the dongle answers to the same
==      question
==      something like
==      23.128.00.00.00
==      ?
==      Alex - was it the same dongle?
==      Kevin or anyone: can you use putty to interact with the dongle
==      under Windows
==      and type some commands, like:
==      at+gmr
==      and other similar commands?
==      If the dongle reports different firmware versions under Linux
==      and Windows, then
==      guys... we need to figure out the Windows switch message.
==      Overmore - in the device installation sh*t, you can see there is
==      a firmware
==      updater... Why?
==
==      Alex: I used the
==      at^reset
==      command to get the modem back to normal state once; and so it
==      restored the
==      nvram to default or something.
==      If you reconnect it to windows ... i hope it gets re-setup as
==      before.
==      But - nothing harmful to the device, only to it's settings,
==      sorry.
==      I restored the relevant settings and it connects again, but no
==      dhcp. But - be
==      peaceful: other modems out there seems to not get dhcp anyway.
==      this is the state the modem arrives when you buy it, so windows
==      should know
==      Wwhat To Say To The Modem (TM).
==      Another thing - note that:
==      [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed
==
==      Any ideas, comments, suggestions are highly appreciated guys.
==      Of any type.
==
==      Bjorn - unfortunately it seems this problem is related to E3727
==      and E3276
==      sticks; they can get IP from DHCP but not go ahead.
==
==
==