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

Message-ID: <alpine.LNX.2.03.1412021238280.29454@gmail.com>
Date:	Tue, 2 Dec 2014 12:39:38 +0100 (CET)
From:	Enrico Mioso <mrkiko.rs@...il.com>
To:	Bjørn Mork <bjorn@...k.no>
cc:	Kevin Zhu <Mingying.Zhu@...iocodes.com>,
	Eli Britstein <Eli.Britstein@...iocodes.com>,
	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?

To be clear - I also rebooted the remote system to power cycle the modem, 
wanting to avoid
at^reset

But this modification of the driver unfortunately seems to lead to no changes. 
Thank you so much Bjorn.

Interetingly - a misbehaviour of the firmware was observed - I wasn't able to
at^ndisdup=1,0
... the firmware seemed to ignore it.
But this might not be related to the patch.
Thank you again.
Enrico

On Tue, 2 Dec 2014, Bjørn Mork wrote:

==Date: Tue, 2 Dec 2014 12:21:18
==From: Bjørn Mork <bjorn@...k.no>
==To: Enrico Mioso <mrkiko.rs@...il.com>
==Cc: Kevin Zhu <Mingying.Zhu@...iocodes.com>,
==    Eli Britstein <Eli.Britstein@...iocodes.com>,
==    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?
==
==Enrico Mioso <mrkiko.rs@...il.com> writes:
==
==> Kevin - it works! the key seems to be in the tx_fixup function; there is a 
==> special handling for frames effectively.
==> Please ... help me backport those changes to the standard Linux driver - it 
==> will be a gain for us all, and in general you'll have a more probable 
==> maintenance than you would with the driver from huawei.
==
==Very interesting.  The NCM code in the huawei driver has a different
==origin, so it is quite different and not too easy to merge into the
==existing Linux cdc_ncm driver.
==
==But this does pinpoint differences we should explore.  One is the
==placement of the NDP: The Huawei driver puts it at the end.  Another,
==which is much easier to test out quickly, is the sequence numbering: The
==Huawei driver doesn't use it.
==
==So I wonder if this makes any difference:
==
==diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
==index 80a844e0ae03..37f11770acb6 100644
==--- a/drivers/net/usb/cdc_ncm.c
==+++ b/drivers/net/usb/cdc_ncm.c
==@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign)
== 		nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16));
== 		nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN);
== 		nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16));
==-		nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==+//		nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
== 
== 		/* count total number of frames in this NTB */
== 		ctx->tx_curr_frame_num = 0;
==
==
==
==Bjørn
==