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]

Date:	Tue, 2 Dec 2014 14:11:47 +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?

... but out of curiosity: are NCM specs allowing to change order of things in 
the package or not?
This is not to start philosofical falames or something, but to understand 
better how things work. And, if they do: how much arbitrarily?

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
==