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
| ||
|
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 ==
Powered by blists - more mailing lists