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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 2 Dec 2014 07:12:36 +0100 (CET)
From:	Enrico Mioso <mrkiko.rs@...il.com>
To:	Eli Britstein <Eli.Britstein@...iocodes.com>
cc:	Kevin Zhu <Mingying.Zhu@...iocodes.com>,
	Bjørn Mork <bjorn@...k.no>,
	Alex Strizhevsky <alexxst@...il.com>,
	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>
Subject: Re: Is this 32-bit NCM?

And - let's be precise: Eli is right, in some cases (with some dongles / 
firmwares, including the one I was / am testing remotely), sometimes DHCP is 
answered.
On forums, people experience intermittent results.
The only thing I am thinking now is thet the firmware cares about the content 
of the padding area. Crazy, stupid but... I don't know what to think about it 
now.
I looked at the .inf file values: and I would suggest to all of you who can run 
the installation of the product under Windows, to look at the registry key that 
are set and that the drivers are caring about.
In my opinion here should be something interesting.
Looking at the inf files of the *ecm* drivers and tracking down registry values 
might be effectively useful.
Enrico.


On Mon, 1 Dec 2014, Eli Britstein wrote:

==Date: Mon, 1 Dec 2014 23:02:16
==From: Eli Britstein <Eli.Britstein@...iocodes.com>
==To: Enrico Mioso <mrkiko.rs@...il.com>
==Cc: Kevin Zhu <Mingying.Zhu@...iocodes.com>, Bjørn Mork <bjorn@...k.no>,
==    Alex Strizhevsky <alexxst@...il.com>,
==    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>
==Subject: Re: Is this 32-bit NCM?
==
==Hi Enrico and all,
==
==Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
==Maybe we can trace to compare them?
==
==Sent from my iPhone
==
==> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@...il.com> wrote:
==>
==> So ... I have two ideas left for now.
==> We know for sure the problem is in the way we TX frames, not the way we RX them
==> (the way we send, generate them, not the way we receive them).
==> Si I have two ideas, and I ask for help from the Linux-usb mailing list for
==> this first one.
==>
==> 1 - Does a wayexist to "replay" traffic crom a usb capture?
==> We might try to take the usb frames generated by Windows, and send them to the
==> device to see if there is any reaction. It should not be science fiction, I saw
==> them do that in the eciadsl old project.
==> 2 - The huawei ndis driver: does it work with these devices?
==> It should be a little bit out-dated now (at least in terms of dates, it might
==> work as well): the code is A LOT but, just in case, to see if there is any
==> chances it'll work. It remains to be seen in which kernels it can actually
==> compile again.
==>
==> If this works we might analyse what's happening and try to debug this out.
==> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
==> Thank you.
==
==________________________________
==
==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

Powered by Openwall GNU/*/Linux Powered by OpenVZ