[PATCH net-next v6 0/3] The huawei_cdc_ncm driver

[PATCH net-next v6 0/3] The huawei_cdc_ncm driver

[Bjørn Mork]

Enrico has been kind enough to let me repost his driver with the changes
requested by Oliver Neukum during the last review of this series.

The changes I have made from Enricos original v5 series to this version
are:

v6:
 - fix to avoid corrupting drvstate->pmcount
 - fix error return value from huawei_cdc_ncm_suspend()
 - drop redundant testing for subdriver->suspend during resume
 - broke a few lines to keep within the 80 columns recommendation
 - rebased on top of current net-next

Enrico's orginal introduction to the v5 series follows below.  It explains
the background much better than I can.

Bjørn


[quote Enrico Mioso]

So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which 
supports devices resembling the NCM standard, but using it also as a mean 
to encapsulate other protocols, as is the case for the Huawei E3131 and
E3251 modem devices.
Some precisations are needed however - and I encourage discussion on this: and 
that's why I'm sending this message with a broader CC.
Merging those patches might change:
- the way Modem Manager interacts with those devices
- some regressions might be possible if there are some unknown firmware 
  variants around (Franko?)

First of all: I observed the behaviours of two devices.
Huawei E3131: this device doesn't accept NDIS setup requests unless they're 
sent via the embedded AT channel exposed by this driver.
So actually we gain funcionality in this case!

The second case, is the Huawei E3251: which works with standard NCM driver, 
still exposing an AT embedded channel. Whith this patch set applied, you gain 
some funcionality, loosing the ability to catch standard NCM events for now.
The device will work in both ways with no problems, but this has to be 
acknowledged and discussed. Might be we can develop this driver further to 
change this, when more devices are tested.

We where thinking Huawei changed their interfaces on new devices - but probably 
this driver only works around a nice firmware bug present in E3131, which 
prevented the modem from being used in NDIS mode.

I think committing this is definitely wortth-while, since it will allow for 
more Huawei devices to be used without serial connection. Some devices like the 
E3251 also, reports some status information only via the embedded AT channel, 
at least in my case.
Note: I'm not subscribed to any list except the Modem Manager's one, so please 
CC me, thanks!!

[/quote]

Enrico Mioso (3):
  net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
  net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
  net: cdc_ncm: remove non-standard NCM device IDs

 drivers/net/usb/Kconfig          |   15 +++
 drivers/net/usb/Makefile         |    1 +
 drivers/net/usb/cdc_ncm.c        |   17 +--
 drivers/net/usb/huawei_cdc_ncm.c |  230 ++++++++++++++++++++++++++++++++++++++
 include/linux/usb/cdc_ncm.h      |    3 +
 5 files changed, 253 insertions(+), 13 deletions(-)
 create mode 100644 drivers/net/usb/huawei_cdc_ncm.c

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next v6 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use

[Bjørn Mork]

From: Enrico Mioso <mrkiko.rs@gmail.com>

Some drivers implementing NCM-like protocols, may re-use those functions, as is
the case in the huawei_cdc_ncm driver.
Export them via EXPORT_SYMBOL_GPL, in accordance with how other functions have
been exported.

Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 drivers/net/usb/cdc_ncm.c   |    6 ++++--
 include/linux/usb/cdc_ncm.h |    3 +++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 11c7033..1763195 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -830,7 +830,7 @@ static void cdc_ncm_txpath_bh(unsigned long param)
 	}
 }
 
-static struct sk_buff *
+struct sk_buff *
 cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
 {
 	struct sk_buff *skb_out;
@@ -857,6 +857,7 @@ error:
 
 	return NULL;
 }
+EXPORT_SYMBOL_GPL(cdc_ncm_tx_fixup);
 
 /* verify NTB header and return offset of first NDP, or negative error */
 int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in)
@@ -943,7 +944,7 @@ error:
 }
 EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_ndp16);
 
-static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
+int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
 {
 	struct sk_buff *skb;
 	struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
@@ -1019,6 +1020,7 @@ err_ndp:
 error:
 	return 0;
 }
+EXPORT_SYMBOL_GPL(cdc_ncm_rx_fixup);
 
 static void
 cdc_ncm_speed_change(struct usbnet *dev,
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index 2300f74..c3fa807 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -125,5 +125,8 @@ void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf);
 struct sk_buff *cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign);
 int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in);
 int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset);
+struct sk_buff *
+cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags);
+int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in);
 
 #endif /* __LINUX_USB_CDC_NCM_H */
-- 
1.7.10.4

[PATCH net-next v6 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver

[Bjørn Mork]

From: Enrico Mioso <mrkiko.rs@gmail.com>

This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This drivers approach was
heavily inspired by the qmi_wwan/cdc_mbim approach & code model.

Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 drivers/net/usb/Kconfig          |   15 +++
 drivers/net/usb/Makefile         |    1 +
 drivers/net/usb/huawei_cdc_ncm.c |  230 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 246 insertions(+)
 create mode 100644 drivers/net/usb/huawei_cdc_ncm.c

diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 40db312..85e4a01 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -242,6 +242,21 @@ config USB_NET_CDC_NCM
 	    * ST-Ericsson M343 HSPA Mobile Broadband Modem (reference design)
 	    * Ericsson F5521gw Mobile Broadband Module
 
+config USB_NET_HUAWEI_CDC_NCM
+	tristate "Huawei NCM embedded AT channel support"
+	depends on USB_USBNET
+	select USB_WDM
+	select USB_NET_CDC_NCM
+	help
+		This driver supports huawei-style NCM devices, that use NCM as a
+		transport for other protocols, usually an embedded AT channel.
+		Good examples are:
+		* Huawei E3131
+		* Huawei E3251
+
+		To compile this driver as a module, choose M here: the module will be
+		called huawei_cdc_ncm.ko.
+
 config USB_NET_CDC_MBIM
 	tristate "CDC MBIM support"
 	depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 8b342cf..b17b5e8 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_IPHETH)	+= ipheth.o
 obj-$(CONFIG_USB_SIERRA_NET)	+= sierra_net.o
 obj-$(CONFIG_USB_NET_CX82310_ETH)	+= cx82310_eth.o
 obj-$(CONFIG_USB_NET_CDC_NCM)	+= cdc_ncm.o
+obj-$(CONFIG_USB_NET_HUAWEI_CDC_NCM)	+= huawei_cdc_ncm.o
 obj-$(CONFIG_USB_VL600)		+= lg-vl600.o
 obj-$(CONFIG_USB_NET_QMI_WWAN)	+= qmi_wwan.o
 obj-$(CONFIG_USB_NET_CDC_MBIM)	+= cdc_mbim.o
diff --git a/drivers/net/usb/huawei_cdc_ncm.c b/drivers/net/usb/huawei_cdc_ncm.c
new file mode 100644
index 0000000..312178d
--- /dev/null
+++ b/drivers/net/usb/huawei_cdc_ncm.c
@@ -0,0 +1,230 @@
+/* huawei_cdc_ncm.c - handles Huawei devices using the CDC NCM protocol as
+ * transport layer.
+ * Copyright (C) 2013	 Enrico Mioso <mrkiko.rs@gmail.com>
+ *
+ *
+ * ABSTRACT:
+ * This driver handles devices resembling the CDC NCM standard, but
+ * encapsulating another protocol inside it. An example are some Huawei 3G
+ * devices, exposing an embedded AT channel where you can set up the NCM
+ * connection.
+ * This code has been heavily inspired by the cdc_mbim.c driver, which is
+ * Copyright (c) 2012  Smith Micro Software, Inc.
+ * Copyright (c) 2012  Bjørn Mork <bjorn@mork.no>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/ethtool.h>
+#include <linux/if_vlan.h>
+#include <linux/ip.h>
+#include <linux/mii.h>
+#include <linux/usb.h>
+#include <linux/usb/cdc.h>
+#include <linux/usb/usbnet.h>
+#include <linux/usb/cdc-wdm.h>
+#include <linux/usb/cdc_ncm.h>
+
+/* Driver data */
+struct huawei_cdc_ncm_state {
+	struct cdc_ncm_ctx *ctx;
+	atomic_t pmcount;
+	struct usb_driver *subdriver;
+	struct usb_interface *control;
+	struct usb_interface *data;
+};
+
+static int huawei_cdc_ncm_manage_power(struct usbnet *usbnet_dev, int on)
+{
+	struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
+	int rv;
+
+	if ((on && atomic_add_return(1, &drvstate->pmcount) == 1) ||
+			(!on && atomic_dec_and_test(&drvstate->pmcount))) {
+		rv = usb_autopm_get_interface(usbnet_dev->intf);
+		usbnet_dev->intf->needs_remote_wakeup = on;
+		if (!rv)
+			usb_autopm_put_interface(usbnet_dev->intf);
+	}
+	return 0;
+}
+
+static int huawei_cdc_ncm_wdm_manage_power(struct usb_interface *intf,
+					   int status)
+{
+	struct usbnet *usbnet_dev = usb_get_intfdata(intf);
+
+	/* can be called while disconnecting */
+	if (!usbnet_dev)
+		return 0;
+
+	return huawei_cdc_ncm_manage_power(usbnet_dev, status);
+}
+
+
+static int huawei_cdc_ncm_bind(struct usbnet *usbnet_dev,
+			       struct usb_interface *intf)
+{
+	struct cdc_ncm_ctx *ctx;
+	struct usb_driver *subdriver = ERR_PTR(-ENODEV);
+	int ret = -ENODEV;
+	struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
+
+	/* altsetting should always be 1 for NCM devices - so we hard-coded
+	 * it here
+	 */
+	ret = cdc_ncm_bind_common(usbnet_dev, intf, 1);
+	if (ret)
+		goto err;
+
+	ctx = drvstate->ctx;
+
+	if (usbnet_dev->status)
+		/* CDC-WMC r1.1 requires wMaxCommand to be "at least 256
+		 * decimal (0x100)"
+		 */
+		subdriver = usb_cdc_wdm_register(ctx->control,
+						 &usbnet_dev->status->desc,
+						 256, /* wMaxCommand */
+						 huawei_cdc_ncm_wdm_manage_power);
+	if (IS_ERR(subdriver)) {
+		ret = PTR_ERR(subdriver);
+		cdc_ncm_unbind(usbnet_dev, intf);
+		goto err;
+	}
+
+	/* Prevent usbnet from using the status descriptor */
+	usbnet_dev->status = NULL;
+
+	drvstate->subdriver = subdriver;
+
+err:
+	return ret;
+}
+
+static void huawei_cdc_ncm_unbind(struct usbnet *usbnet_dev,
+				  struct usb_interface *intf)
+{
+	struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
+	struct cdc_ncm_ctx *ctx = drvstate->ctx;
+
+	if (drvstate->subdriver && drvstate->subdriver->disconnect)
+		drvstate->subdriver->disconnect(ctx->control);
+	drvstate->subdriver = NULL;
+
+	cdc_ncm_unbind(usbnet_dev, intf);
+}
+
+static int huawei_cdc_ncm_suspend(struct usb_interface *intf,
+				  pm_message_t message)
+{
+	int ret = 0;
+	struct usbnet *usbnet_dev = usb_get_intfdata(intf);
+	struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
+	struct cdc_ncm_ctx *ctx = drvstate->ctx;
+
+	if (ctx == NULL) {
+		ret = -ENODEV;
+		goto error;
+	}
+
+	ret = usbnet_suspend(intf, message);
+	if (ret < 0)
+		goto error;
+
+	if (intf == ctx->control &&
+		drvstate->subdriver &&
+		drvstate->subdriver->suspend)
+		ret = drvstate->subdriver->suspend(intf, message);
+	if (ret < 0)
+		usbnet_resume(intf);
+
+error:
+	return ret;
+}
+
+static int huawei_cdc_ncm_resume(struct usb_interface *intf)
+{
+	int ret = 0;
+	struct usbnet *usbnet_dev = usb_get_intfdata(intf);
+	struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
+	bool callsub;
+	struct cdc_ncm_ctx *ctx = drvstate->ctx;
+
+	/* should we call subdriver's resume function? */
+	callsub =
+		(intf == ctx->control &&
+		drvstate->subdriver &&
+		drvstate->subdriver->resume);
+
+	if (callsub)
+		ret = drvstate->subdriver->resume(intf);
+	if (ret < 0)
+		goto err;
+	ret = usbnet_resume(intf);
+	if (ret < 0 && callsub)
+		drvstate->subdriver->suspend(intf, PMSG_SUSPEND);
+err:
+	return ret;
+}
+
+static int huawei_cdc_ncm_check_connect(struct usbnet *usbnet_dev)
+{
+	struct cdc_ncm_ctx *ctx;
+
+	ctx = (struct cdc_ncm_ctx *)usbnet_dev->data[0];
+
+	if (ctx == NULL)
+		return 1; /* disconnected */
+
+	return !ctx->connected;
+}
+
+static const struct driver_info huawei_cdc_ncm_info = {
+	.description = "Huawei CDC NCM device",
+	.flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN,
+	.bind = huawei_cdc_ncm_bind,
+	.unbind = huawei_cdc_ncm_unbind,
+	.check_connect = huawei_cdc_ncm_check_connect,
+	.manage_power = huawei_cdc_ncm_manage_power,
+	.rx_fixup = cdc_ncm_rx_fixup,
+	.tx_fixup = cdc_ncm_tx_fixup,
+};
+
+static const struct usb_device_id huawei_cdc_ncm_devs[] = {
+	/* Huawei NCM devices disguised as vendor specific */
+	{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16),
+	  .driver_info = (unsigned long)&huawei_cdc_ncm_info,
+	},
+	{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x46),
+	  .driver_info = (unsigned long)&huawei_cdc_ncm_info,
+	},
+	{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x76),
+	  .driver_info = (unsigned long)&huawei_cdc_ncm_info,
+	},
+
+	/* Terminating entry */
+	{
+	},
+};
+MODULE_DEVICE_TABLE(usb, huawei_cdc_ncm_devs);
+
+static struct usb_driver huawei_cdc_ncm_driver = {
+	.name = "huawei_cdc_ncm",
+	.id_table = huawei_cdc_ncm_devs,
+	.probe = usbnet_probe,
+	.disconnect = usbnet_disconnect,
+	.suspend = huawei_cdc_ncm_suspend,
+	.resume = huawei_cdc_ncm_resume,
+	.reset_resume = huawei_cdc_ncm_resume,
+	.supports_autosuspend = 1,
+	.disable_hub_initiated_lpm = 1,
+};
+module_usb_driver(huawei_cdc_ncm_driver);
+MODULE_AUTHOR("Enrico Mioso <mrkiko.rs@gmail.com>");
+MODULE_DESCRIPTION("USB CDC NCM host driver with encapsulated protocol support");
+MODULE_LICENSE("GPL");
-- 
1.7.10.4

[PATCH net-next v6 3/3] net: cdc_ncm: remove non-standard NCM device IDs

[Bjørn Mork]

From: Enrico Mioso <mrkiko.rs@gmail.com>

Remove device IDs of NCM-like (but not NCM-conformant) devices, that are
handled by the huawwei_cdc_ncm driver now.

Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 drivers/net/usb/cdc_ncm.c |   11 -----------
 1 file changed, 11 deletions(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 1763195..f74786a 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1186,17 +1186,6 @@ static const struct usb_device_id cdc_devs[] = {
 	  .driver_info = (unsigned long)&wwan_info,
 	},
 
-	/* Huawei NCM devices disguised as vendor specific */
-	{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16),
-	  .driver_info = (unsigned long)&wwan_info,
-	},
-	{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x46),
-	  .driver_info = (unsigned long)&wwan_info,
-	},
-	{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x76),
-	  .driver_info = (unsigned long)&wwan_info,
-	},
-
 	/* Infineon(now Intel) HSPA Modem platform */
 	{ USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
 		USB_CLASS_COMM,
-- 
1.7.10.4

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver

[David Miller]

From: Bjørn Mork <bjorn@mork.no>
Date: Mon,  4 Nov 2013 09:50:46 +0100

> Enrico has been kind enough to let me repost his driver with the changes
> requested by Oliver Neukum during the last review of this series.
> 
> The changes I have made from Enricos original v5 series to this version
> are:
> 
> v6:
>  - fix to avoid corrupting drvstate->pmcount
>  - fix error return value from huawei_cdc_ncm_suspend()
>  - drop redundant testing for subdriver->suspend during resume
>  - broke a few lines to keep within the 80 columns recommendation
>  - rebased on top of current net-next
> 
> Enrico's orginal introduction to the v5 series follows below.  It explains
> the background much better than I can.

Looks good, series applied, thanks!

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
> 
> [quote Enrico Mioso]
> 
> So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which 
> supports devices resembling the NCM standard, but using it also as a mean 
> to encapsulate other protocols, as is the case for the Huawei E3131 and
> E3251 modem devices.
>

Hello,

I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
and thus i'm using the new huawei_cdc_ncm driver.

I'm using the /dev/cdc-wdm0 device to send AT commands to it, and that seems to work,
so the dongle seems like it's connected (also the LED on the dongle suggests it's connected).

.. the problem is the wwan0 interface (well, udev renames it to wwp0s26u1u5i1) doesn't work.
Launching a dhcp client on the wwp0s26u1u5i1 doesn't get any IP address.

Any tips how to troubleshoot this? 

I'm seeing "RX errors" listed for the interface in "ifconfig -a" output.. is that normal? 

The device in question is (ATI command output):

Manufacturer: huawei
Model: E3276
Revision: 21.263.03.00.07
IMEI: 863XYZXYZXYZXYZ
+GCAP: +CGSM,+DS,+ES

Thanks!

-- Pasi


> Some precisations are needed however - and I encourage discussion on this: and 
> that's why I'm sending this message with a broader CC.
> Merging those patches might change:
> - the way Modem Manager interacts with those devices
> - some regressions might be possible if there are some unknown firmware 
>   variants around (Franko?)
> 
> First of all: I observed the behaviours of two devices.
> Huawei E3131: this device doesn't accept NDIS setup requests unless they're 
> sent via the embedded AT channel exposed by this driver.
> So actually we gain funcionality in this case!
> 
> The second case, is the Huawei E3251: which works with standard NCM driver, 
> still exposing an AT embedded channel. Whith this patch set applied, you gain 
> some funcionality, loosing the ability to catch standard NCM events for now.
> The device will work in both ways with no problems, but this has to be 
> acknowledged and discussed. Might be we can develop this driver further to 
> change this, when more devices are tested.
> 
> We where thinking Huawei changed their interfaces on new devices - but probably 
> this driver only works around a nice firmware bug present in E3131, which 
> prevented the modem from being used in NDIS mode.
> 
> I think committing this is definitely wortth-while, since it will allow for 
> more Huawei devices to be used without serial connection. Some devices like the 
> E3251 also, reports some status information only via the embedded AT channel, 
> at least in my case.
> Note: I'm not subscribed to any list except the Modem Manager's one, so please 
> CC me, thanks!!
> 
> [/quote]
> 
> Enrico Mioso (3):
>   net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
>   net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
>   net: cdc_ncm: remove non-standard NCM device IDs
> 
>  drivers/net/usb/Kconfig          |   15 +++
>  drivers/net/usb/Makefile         |    1 +
>  drivers/net/usb/cdc_ncm.c        |   17 +--
>  drivers/net/usb/huawei_cdc_ncm.c |  230 ++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/cdc_ncm.h      |    3 +
>  5 files changed, 253 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
> 
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Dan Williams]

On Thu, 2014-03-13 at 22:25 +0200, Pasi Kärkkäinen wrote:
> On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
> > 
> > [quote Enrico Mioso]
> > 
> > So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which 
> > supports devices resembling the NCM standard, but using it also as a mean 
> > to encapsulate other protocols, as is the case for the Huawei E3131 and
> > E3251 modem devices.
> >
> 
> Hello,
> 
> I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
> and thus i'm using the new huawei_cdc_ncm driver.
> 
> I'm using the /dev/cdc-wdm0 device to send AT commands to it, and that seems to work,
> so the dongle seems like it's connected (also the LED on the dongle suggests it's connected).
> 
> .. the problem is the wwan0 interface (well, udev renames it to wwp0s26u1u5i1) doesn't work.
> Launching a dhcp client on the wwp0s26u1u5i1 doesn't get any IP address.
> 
> Any tips how to troubleshoot this? 

Which AT commands are you using to start the data connection?

I believe Huawei says that DHCP on the network port is only supported if
network port's USB interface has Class 0x2 + SubClass [0x6 | 0xd] +
Protocol 0x0.

Lastly, I think the E3276 has a couple of different "modes" that it can
switch into with usb_modeswitch too, and only some modes expose the
right network interface.  What modeswitch command is getting sent to the
device?

Dan

> I'm seeing "RX errors" listed for the interface in "ifconfig -a" output.. is that normal? 
> 
> The device in question is (ATI command output):
> 
> Manufacturer: huawei
> Model: E3276
> Revision: 21.263.03.00.07
> IMEI: 863XYZXYZXYZXYZ
> +GCAP: +CGSM,+DS,+ES
> 
> Thanks!
> 
> -- Pasi
> 
> 
> > Some precisations are needed however - and I encourage discussion on this: and 
> > that's why I'm sending this message with a broader CC.
> > Merging those patches might change:
> > - the way Modem Manager interacts with those devices
> > - some regressions might be possible if there are some unknown firmware 
> >   variants around (Franko?)
> > 
> > First of all: I observed the behaviours of two devices.
> > Huawei E3131: this device doesn't accept NDIS setup requests unless they're 
> > sent via the embedded AT channel exposed by this driver.
> > So actually we gain funcionality in this case!
> > 
> > The second case, is the Huawei E3251: which works with standard NCM driver, 
> > still exposing an AT embedded channel. Whith this patch set applied, you gain 
> > some funcionality, loosing the ability to catch standard NCM events for now.
> > The device will work in both ways with no problems, but this has to be 
> > acknowledged and discussed. Might be we can develop this driver further to 
> > change this, when more devices are tested.
> > 
> > We where thinking Huawei changed their interfaces on new devices - but probably 
> > this driver only works around a nice firmware bug present in E3131, which 
> > prevented the modem from being used in NDIS mode.
> > 
> > I think committing this is definitely wortth-while, since it will allow for 
> > more Huawei devices to be used without serial connection. Some devices like the 
> > E3251 also, reports some status information only via the embedded AT channel, 
> > at least in my case.
> > Note: I'm not subscribed to any list except the Modem Manager's one, so please 
> > CC me, thanks!!
> > 
> > [/quote]
> > 
> > Enrico Mioso (3):
> >   net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
> >   net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
> >   net: cdc_ncm: remove non-standard NCM device IDs
> > 
> >  drivers/net/usb/Kconfig          |   15 +++
> >  drivers/net/usb/Makefile         |    1 +
> >  drivers/net/usb/cdc_ncm.c        |   17 +--
> >  drivers/net/usb/huawei_cdc_ncm.c |  230 ++++++++++++++++++++++++++++++++++++++
> >  include/linux/usb/cdc_ncm.h      |    3 +
> >  5 files changed, 253 insertions(+), 13 deletions(-)
> >  create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
> > 
> > -- 
> > 1.7.10.4
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Thu, Mar 13, 2014 at 04:41:47PM -0500, Dan Williams wrote:
> On Thu, 2014-03-13 at 22:25 +0200, Pasi Kärkkäinen wrote:
> > On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
> > > 
> > > [quote Enrico Mioso]
> > > 
> > > So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which 
> > > supports devices resembling the NCM standard, but using it also as a mean 
> > > to encapsulate other protocols, as is the case for the Huawei E3131 and
> > > E3251 modem devices.
> > >
> > 
> > Hello,
> > 
> > I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
> > and thus i'm using the new huawei_cdc_ncm driver.
> > 
> > I'm using the /dev/cdc-wdm0 device to send AT commands to it, and that seems to work,
> > so the dongle seems like it's connected (also the LED on the dongle suggests it's connected).
> > 
> > .. the problem is the wwan0 interface (well, udev renames it to wwp0s26u1u5i1) doesn't work.
> > Launching a dhcp client on the wwp0s26u1u5i1 doesn't get any IP address.
> > 
> > Any tips how to troubleshoot this? 
> 

Hi,

> Which AT commands are you using to start the data connection?
> 

I've been using:

ATQ0 V1 E1 S0=0
AT^NDISDUP=1,1,"internet"
AT^DHCP?


> I believe Huawei says that DHCP on the network port is only supported if
> network port's USB interface has Class 0x2 + SubClass [0x6 | 0xd] +
> Protocol 0x0.
> 

# lsusb | grep -i huawei
Bus 001 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard

# lsusb -t
..
        |__ Port 5: Dev 10, If 0, Class=Vendor Specific Class, Driver=option, 480M
        |__ Port 5: Dev 10, If 1, Class=Vendor Specific Class, Driver=huawei_cdc_ncm, 480M
        |__ Port 5: Dev 10, If 2, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 5: Dev 10, If 3, Class=Mass Storage, Driver=usb-storage, 480M

Bus 001 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x12d1 Huawei Technologies Co., Ltd.
  idProduct          0x1506 Modem/Networkcard
  bcdDevice            1.02
  iManufacturer           2 HUAWEI Technology
  iProduct                1 HUAWEI Mobile
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          173
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          3 Huawei Configuration
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2
      bInterfaceProtocol     18
      iInterface              0
      ** UNRECOGNIZED:  05 24 00 10 01
      ** UNRECOGNIZED:  04 24 02 02
      ** UNRECOGNIZED:  05 24 01 00 00
      ** UNRECOGNIZED:  06 24 06 00 00 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2
      bInterfaceProtocol     22
      iInterface              0
      ** UNRECOGNIZED:  05 24 00 10 01
      ** UNRECOGNIZED:  06 24 1a 00 01 1f
      ** UNRECOGNIZED:  0d 24 0f 04 0f 00 00 00 ea 05 03 00 01
      ** UNRECOGNIZED:  05 24 06 01 01
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2
      bInterfaceProtocol     22
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)


> Lastly, I think the E3276 has a couple of different "modes" that it can
> switch into with usb_modeswitch too, and only some modes expose the
> right network interface.  What modeswitch command is getting sent to the
> device?
> 

This is on Fedora 20. 

Mar 13 23:56:36 localhost logger: usb_modeswitch: using overriding config file /etc/usb_modeswitch.d/12d1:14fe; make sure this is intended
Mar 13 23:56:36 localhost logger: usb_modeswitch: please report any new or corrected settings; otherwise, check for outdated files
Mar 13 23:56:36 localhost usb_modeswitch: switching device 12d1:14fe on 001/009
Mar 13 23:56:37 localhost logger: usb_modeswitch: switched to 12d1:1506 on 001/010

# cat /etc/usb_modeswitch.d/12d1:14fe

# T-Mobile NL (Huawei E352)

TargetVendor=  0x12d1
TargetProductList="1506,150f,151d"

MessageContent="55534243123456780000000000000011062000000100000000000000000000"


# grep -i e3276 /etc/usb_modeswitch.d/*
/etc/usb_modeswitch.d/12d1:156a:# Huawei E3276s-151 and E3251


# cat /etc/usb_modeswitch.d/12d1:156a

# Huawei E3276s-151 and E3251

TargetVendor=  0x12d1
TargetProductList="156b,156c"

MessageContent="55534243123456780000000000000011062000000100000000000000000000"



Hopefully that was enough information.. 

Thanks!

-- Pasi


> Dan
> 
> > I'm seeing "RX errors" listed for the interface in "ifconfig -a" output.. is that normal? 
> > 
> > The device in question is (ATI command output):
> > 
> > Manufacturer: huawei
> > Model: E3276
> > Revision: 21.263.03.00.07
> > IMEI: 863XYZXYZXYZXYZ
> > +GCAP: +CGSM,+DS,+ES
> > 
> > Thanks!
> > 
> > -- Pasi
> > 
> > 
> > > Some precisations are needed however - and I encourage discussion on this: and 
> > > that's why I'm sending this message with a broader CC.
> > > Merging those patches might change:
> > > - the way Modem Manager interacts with those devices
> > > - some regressions might be possible if there are some unknown firmware 
> > >   variants around (Franko?)
> > > 
> > > First of all: I observed the behaviours of two devices.
> > > Huawei E3131: this device doesn't accept NDIS setup requests unless they're 
> > > sent via the embedded AT channel exposed by this driver.
> > > So actually we gain funcionality in this case!
> > > 
> > > The second case, is the Huawei E3251: which works with standard NCM driver, 
> > > still exposing an AT embedded channel. Whith this patch set applied, you gain 
> > > some funcionality, loosing the ability to catch standard NCM events for now.
> > > The device will work in both ways with no problems, but this has to be 
> > > acknowledged and discussed. Might be we can develop this driver further to 
> > > change this, when more devices are tested.
> > > 
> > > We where thinking Huawei changed their interfaces on new devices - but probably 
> > > this driver only works around a nice firmware bug present in E3131, which 
> > > prevented the modem from being used in NDIS mode.
> > > 
> > > I think committing this is definitely wortth-while, since it will allow for 
> > > more Huawei devices to be used without serial connection. Some devices like the 
> > > E3251 also, reports some status information only via the embedded AT channel, 
> > > at least in my case.
> > > Note: I'm not subscribed to any list except the Modem Manager's one, so please 
> > > CC me, thanks!!
> > > 
> > > [/quote]
> > > 
> > > Enrico Mioso (3):
> > >   net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
> > >   net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
> > >   net: cdc_ncm: remove non-standard NCM device IDs
> > > 
> > >  drivers/net/usb/Kconfig          |   15 +++
> > >  drivers/net/usb/Makefile         |    1 +
> > >  drivers/net/usb/cdc_ncm.c        |   17 +--
> > >  drivers/net/usb/huawei_cdc_ncm.c |  230 ++++++++++++++++++++++++++++++++++++++
> > >  include/linux/usb/cdc_ncm.h      |    3 +
> > >  5 files changed, 253 insertions(+), 13 deletions(-)
> > >  create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
> > > 
> > > -- 
> > > 1.7.10.4
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Fri, Mar 14, 2014 at 12:08:12AM +0200, Pasi Kärkkäinen wrote:
> On Thu, Mar 13, 2014 at 04:41:47PM -0500, Dan Williams wrote:
> > On Thu, 2014-03-13 at 22:25 +0200, Pasi Kärkkäinen wrote:
> > > On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
> > > > 
> > > > [quote Enrico Mioso]
> > > > 
> > > > So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which 
> > > > supports devices resembling the NCM standard, but using it also as a mean 
> > > > to encapsulate other protocols, as is the case for the Huawei E3131 and
> > > > E3251 modem devices.
> > > >
> > > 
> > > Hello,
> > > 
> > > I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
> > > and thus i'm using the new huawei_cdc_ncm driver.
> > > 
> > > I'm using the /dev/cdc-wdm0 device to send AT commands to it, and that seems to work,
> > > so the dongle seems like it's connected (also the LED on the dongle suggests it's connected).
> > > 
> > > .. the problem is the wwan0 interface (well, udev renames it to wwp0s26u1u5i1) doesn't work.
> > > Launching a dhcp client on the wwp0s26u1u5i1 doesn't get any IP address.
> > > 
> > > Any tips how to troubleshoot this? 
> > 
> 
> Hi,
> 
> > Which AT commands are you using to start the data connection?
> > 
> 
> I've been using:
> 
> ATQ0 V1 E1 S0=0
> AT^NDISDUP=1,1,"internet"
> AT^DHCP?
>

Oh, I forgot to mention.. after I send AT^NDISDUP=1,1,"internet" I get this:

^NDISSTAT:1,,,"IPV4"

.. which to my understanding means it's connected (1==connected).
Also sending AT^NDISSTATQRY? results in:

^NDISSTATQRY: 1,,,"IPV4"


But I can't get an IP with dhcp client on the wwan0 interface..


-- Pasi

 
> 
> > I believe Huawei says that DHCP on the network port is only supported if
> > network port's USB interface has Class 0x2 + SubClass [0x6 | 0xd] +
> > Protocol 0x0.
> > 
> 
> # lsusb | grep -i huawei
> Bus 001 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
> 
> # lsusb -t
> ..
>         |__ Port 5: Dev 10, If 0, Class=Vendor Specific Class, Driver=option, 480M
>         |__ Port 5: Dev 10, If 1, Class=Vendor Specific Class, Driver=huawei_cdc_ncm, 480M
>         |__ Port 5: Dev 10, If 2, Class=Mass Storage, Driver=usb-storage, 480M
>         |__ Port 5: Dev 10, If 3, Class=Mass Storage, Driver=usb-storage, 480M
> 
> Bus 001 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0
>   bDeviceProtocol         0
>   bMaxPacketSize0        64
>   idVendor           0x12d1 Huawei Technologies Co., Ltd.
>   idProduct          0x1506 Modem/Networkcard
>   bcdDevice            1.02
>   iManufacturer           2 HUAWEI Technology
>   iProduct                1 HUAWEI Mobile
>   iSerial                 0
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength          173
>     bNumInterfaces          4
>     bConfigurationValue     1
>     iConfiguration          3 Huawei Configuration
>     bmAttributes         0x80
>       (Bus Powered)
>     MaxPower              500mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass       255 Vendor Specific Class
>       bInterfaceSubClass      2
>       bInterfaceProtocol     18
>       iInterface              0
>       ** UNRECOGNIZED:  05 24 00 10 01
>       ** UNRECOGNIZED:  04 24 02 02
>       ** UNRECOGNIZED:  05 24 01 00 00
>       ** UNRECOGNIZED:  06 24 06 00 00 00
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval              32
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x01  EP 1 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval              32
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        1
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass       255 Vendor Specific Class
>       bInterfaceSubClass      2
>       bInterfaceProtocol     22
>       iInterface              0
>       ** UNRECOGNIZED:  05 24 00 10 01
>       ** UNRECOGNIZED:  06 24 1a 00 01 1f
>       ** UNRECOGNIZED:  0d 24 0f 04 0f 00 00 00 ea 05 03 00 01
>       ** UNRECOGNIZED:  05 24 06 01 01
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               5
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        1
>       bAlternateSetting       1
>       bNumEndpoints           3
>       bInterfaceClass       255 Vendor Specific Class
>       bInterfaceSubClass      2
>       bInterfaceProtocol     22
>       iInterface              0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               5
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x83  EP 3 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval              32
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x02  EP 2 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval              32
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        2
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass         8 Mass Storage
>       bInterfaceSubClass      6 SCSI
>       bInterfaceProtocol     80 Bulk-Only
>       iInterface              0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x03  EP 3 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval               0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x84  EP 4 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval               0
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        3
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass         8 Mass Storage
>       bInterfaceSubClass      6 SCSI
>       bInterfaceProtocol     80 Bulk-Only
>       iInterface              0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x04  EP 4 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval               0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x85  EP 5 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0200  1x 512 bytes
>         bInterval               0
> Device Qualifier (for other device speed):
>   bLength                10
>   bDescriptorType         6
>   bcdUSB               2.00
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0
>   bDeviceProtocol         0
>   bMaxPacketSize0        64
>   bNumConfigurations      1
> Device Status:     0x0000
>   (Bus Powered)
> 
> 
> > Lastly, I think the E3276 has a couple of different "modes" that it can
> > switch into with usb_modeswitch too, and only some modes expose the
> > right network interface.  What modeswitch command is getting sent to the
> > device?
> > 
> 
> This is on Fedora 20. 
> 
> Mar 13 23:56:36 localhost logger: usb_modeswitch: using overriding config file /etc/usb_modeswitch.d/12d1:14fe; make sure this is intended
> Mar 13 23:56:36 localhost logger: usb_modeswitch: please report any new or corrected settings; otherwise, check for outdated files
> Mar 13 23:56:36 localhost usb_modeswitch: switching device 12d1:14fe on 001/009
> Mar 13 23:56:37 localhost logger: usb_modeswitch: switched to 12d1:1506 on 001/010
> 
> # cat /etc/usb_modeswitch.d/12d1:14fe
> 
> # T-Mobile NL (Huawei E352)
> 
> TargetVendor=  0x12d1
> TargetProductList="1506,150f,151d"
> 
> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
> 
> 
> # grep -i e3276 /etc/usb_modeswitch.d/*
> /etc/usb_modeswitch.d/12d1:156a:# Huawei E3276s-151 and E3251
> 
> 
> # cat /etc/usb_modeswitch.d/12d1:156a
> 
> # Huawei E3276s-151 and E3251
> 
> TargetVendor=  0x12d1
> TargetProductList="156b,156c"
> 
> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
> 
> 
> 
> Hopefully that was enough information.. 
> 
> Thanks!
> 
> -- Pasi
> 
> 
> > Dan
> > 
> > > I'm seeing "RX errors" listed for the interface in "ifconfig -a" output.. is that normal? 
> > > 
> > > The device in question is (ATI command output):
> > > 
> > > Manufacturer: huawei
> > > Model: E3276
> > > Revision: 21.263.03.00.07
> > > IMEI: 863XYZXYZXYZXYZ
> > > +GCAP: +CGSM,+DS,+ES
> > > 
> > > Thanks!
> > > 
> > > -- Pasi
> > > 
> > > 
> > > > Some precisations are needed however - and I encourage discussion on this: and 
> > > > that's why I'm sending this message with a broader CC.
> > > > Merging those patches might change:
> > > > - the way Modem Manager interacts with those devices
> > > > - some regressions might be possible if there are some unknown firmware 
> > > >   variants around (Franko?)
> > > > 
> > > > First of all: I observed the behaviours of two devices.
> > > > Huawei E3131: this device doesn't accept NDIS setup requests unless they're 
> > > > sent via the embedded AT channel exposed by this driver.
> > > > So actually we gain funcionality in this case!
> > > > 
> > > > The second case, is the Huawei E3251: which works with standard NCM driver, 
> > > > still exposing an AT embedded channel. Whith this patch set applied, you gain 
> > > > some funcionality, loosing the ability to catch standard NCM events for now.
> > > > The device will work in both ways with no problems, but this has to be 
> > > > acknowledged and discussed. Might be we can develop this driver further to 
> > > > change this, when more devices are tested.
> > > > 
> > > > We where thinking Huawei changed their interfaces on new devices - but probably 
> > > > this driver only works around a nice firmware bug present in E3131, which 
> > > > prevented the modem from being used in NDIS mode.
> > > > 
> > > > I think committing this is definitely wortth-while, since it will allow for 
> > > > more Huawei devices to be used without serial connection. Some devices like the 
> > > > E3251 also, reports some status information only via the embedded AT channel, 
> > > > at least in my case.
> > > > Note: I'm not subscribed to any list except the Modem Manager's one, so please 
> > > > CC me, thanks!!
> > > > 
> > > > [/quote]
> > > > 
> > > > Enrico Mioso (3):
> > > >   net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
> > > >   net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
> > > >   net: cdc_ncm: remove non-standard NCM device IDs
> > > > 
> > > >  drivers/net/usb/Kconfig          |   15 +++
> > > >  drivers/net/usb/Makefile         |    1 +
> > > >  drivers/net/usb/cdc_ncm.c        |   17 +--
> > > >  drivers/net/usb/huawei_cdc_ncm.c |  230 ++++++++++++++++++++++++++++++++++++++
> > > >  include/linux/usb/cdc_ncm.h      |    3 +
> > > >  5 files changed, 253 insertions(+), 13 deletions(-)
> > > >  create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
> > > > 
> > > > -- 
> > > > 1.7.10.4
> > > > 
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > 

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:
> On Fri, Mar 14, 2014 at 12:08:12AM +0200, Pasi Kärkkäinen wrote:
>>
>> I've been using:
>> 
>> ATQ0 V1 E1 S0=0
>> AT^NDISDUP=1,1,"internet"
>> AT^DHCP?
>>
>
> Oh, I forgot to mention.. after I send AT^NDISDUP=1,1,"internet" I get this:
>
> ^NDISSTAT:1,,,"IPV4"
>
> .. which to my understanding means it's connected (1==connected).
> Also sending AT^NDISSTATQRY? results in:
>
> ^NDISSTATQRY: 1,,,"IPV4"


What response do you get to the AT^DHCP? request when connected?



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Fri, Mar 14, 2014 at 09:34:39AM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen <pasik@iki.fi> writes:
> > On Fri, Mar 14, 2014 at 12:08:12AM +0200, Pasi Kärkkäinen wrote:
> >>
> >> I've been using:
> >> 
> >> ATQ0 V1 E1 S0=0
> >> AT^NDISDUP=1,1,"internet"
> >> AT^DHCP?
> >>
> >
> > Oh, I forgot to mention.. after I send AT^NDISDUP=1,1,"internet" I get this:
> >
> > ^NDISSTAT:1,,,"IPV4"
> >
> > .. which to my understanding means it's connected (1==connected).
> > Also sending AT^NDISSTATQRY? results in:
> >
> > ^NDISSTATQRY: 1,,,"IPV4"
> 
> 
> What response do you get to the AT^DHCP? request when connected?
> 

^NDISSTAT:1,,,"IPV4"
^RSSI: 21

<I send: AT^DHCP?>
^DHCP: CCDB080A,F8FFFFFF,C9DB080A,C9DB080A,E67B59C0,E77B59C0,85600,85600


> 
> Bjørn


-- Pasi

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Pasi Kärkkäinen <pasik@iki.fi> writes:

> ^NDISSTAT:1,,,"IPV4"
> ^RSSI: 21
>
> <I send: AT^DHCP?>
> ^DHCP: CCDB080A,F8FFFFFF,C9DB080A,C9DB080A,E67B59C0,E77B59C0,85600,85600


The hex numbers are IPv4 addresses in little endian. The decimal numbers
at the end are speed down/up IIRC.

Printed in a more readable form, this is:

 10.8.219.204,255.255.255.248,10.8.219.201,10.8.219.201,192.89.123.230,192.89.123.231,85600,85600

I believe this is to be interpreted as

 yourip, netmask, gw, gw?, dns1, dns2


Do stuff work if you manually configure the interface with the
10.8.219.204 address and set the default route to 10.8.219.201?

This is one way to rewrite the addresses if you need to for a new
connection:

 perl -e 'print join(".", reverse map {hex} unpack("(A2)*", shift)),"\n"' C9DB080A



Bjørn

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Fri, Mar 14, 2014 at 09:58:43AM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen <pasik@iki.fi> writes:
> 
> > ^NDISSTAT:1,,,"IPV4"
> > ^RSSI: 21
> >
> > <I send: AT^DHCP?>
> > ^DHCP: CCDB080A,F8FFFFFF,C9DB080A,C9DB080A,E67B59C0,E77B59C0,85600,85600
> 
> 
> The hex numbers are IPv4 addresses in little endian. The decimal numbers
> at the end are speed down/up IIRC.
> 
> Printed in a more readable form, this is:
> 
>  10.8.219.204,255.255.255.248,10.8.219.201,10.8.219.201,192.89.123.230,192.89.123.231,85600,85600
> 
> I believe this is to be interpreted as
> 
>  yourip, netmask, gw, gw?, dns1, dns2
> 
> 
> Do stuff work if you manually configure the interface with the
> 10.8.219.204 address and set the default route to 10.8.219.201?
> 

Unfortunately no :( 

# ifconfig wwp0s26u1u5i1
wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
        inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
        ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 1493  dropped 0  overruns 0  frame 0

Note the RX errors.. ? 

        TX packets 53  bytes 532885 (520.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.219.201    0.0.0.0         UG    0      0        0 wwp0s26u1u5i1
10.8.219.200    0.0.0.0         255.255.255.248 U     0      0        0 wwp0s26u1u5i1


# ping 10.8.219.201
PING 10.8.219.201 (10.8.219.201) 56(84) bytes of data.
From 10.8.219.204 icmp_seq=1 Destination Host Unreachable
From 10.8.219.204 icmp_seq=2 Destination Host Unreachable
From 10.8.219.204 icmp_seq=3 Destination Host Unreachable
From 10.8.219.204 icmp_seq=4 Destination Host Unreachable


And pinging anywhere else doesn't work either.. (I also tried telnet/ssh/web - doesn't work).

More ideas? 


> This is one way to rewrite the addresses if you need to for a new
> connection:
> 
>  perl -e 'print join(".", reverse map {hex} unpack("(A2)*", shift)),"\n"' C9DB080A
> 

This is handy, thanks!

> 
> 
> Bjørn
> 



-- Pasi

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Enrico Mioso]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3199 bytes --]

I am sorry: no ideas on what to do next. Still, one idea would be to try 
reverting these patches and see if it works with the original cdc_ncm driver, 
and see what happens.
Other than this, I do not have this device at hand, so can't see what happens. 
>From the version number, I expect the firmware being HiSilicon (not Qualcomm).
Try also using dhcpcd if you can / want / like :) .
Thank you.


On Fri, 14 Mar 2014, Pasi Kärkkäinen wrote:

==Date: Fri, 14 Mar 2014 10:05:25
==From: Pasi Kärkkäinen <pasik@iki.fi>
==To: Bjørn Mork <bjorn@mork.no>
==Cc: Dan Williams <dcbw@redhat.com>, netdev@vger.kernel.org,
==    linux-usb@vger.kernel.org, Enrico Mioso <mrkiko.rs@gmail.com>,
==    Oliver Neukum <oliver@neukum.org>
==Subject: Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
==
==On Fri, Mar 14, 2014 at 09:58:43AM +0100, Bjørn Mork wrote:
==> Pasi Kärkkäinen <pasik@iki.fi> writes:
==> 
==> > ^NDISSTAT:1,,,"IPV4"
==> > ^RSSI: 21
==> >
==> > <I send: AT^DHCP?>
==> > ^DHCP: CCDB080A,F8FFFFFF,C9DB080A,C9DB080A,E67B59C0,E77B59C0,85600,85600
==> 
==> 
==> The hex numbers are IPv4 addresses in little endian. The decimal numbers
==> at the end are speed down/up IIRC.
==> 
==> Printed in a more readable form, this is:
==> 
==>  10.8.219.204,255.255.255.248,10.8.219.201,10.8.219.201,192.89.123.230,192.89.123.231,85600,85600
==> 
==> I believe this is to be interpreted as
==> 
==>  yourip, netmask, gw, gw?, dns1, dns2
==> 
==> 
==> Do stuff work if you manually configure the interface with the
==> 10.8.219.204 address and set the default route to 10.8.219.201?
==> 
==
==Unfortunately no :( 
==
==# ifconfig wwp0s26u1u5i1
==wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
==        inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
==        inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
==        ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
==        RX packets 0  bytes 0 (0.0 B)
==        RX errors 1493  dropped 0  overruns 0  frame 0
==
==Note the RX errors.. ? 
==
==        TX packets 53  bytes 532885 (520.3 KiB)
==        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
==
==# route -n
==Kernel IP routing table
==Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
==0.0.0.0         10.8.219.201    0.0.0.0         UG    0      0        0 wwp0s26u1u5i1
==10.8.219.200    0.0.0.0         255.255.255.248 U     0      0        0 wwp0s26u1u5i1
==
==
==# ping 10.8.219.201
==PING 10.8.219.201 (10.8.219.201) 56(84) bytes of data.
==From 10.8.219.204 icmp_seq=1 Destination Host Unreachable
==From 10.8.219.204 icmp_seq=2 Destination Host Unreachable
==From 10.8.219.204 icmp_seq=3 Destination Host Unreachable
==From 10.8.219.204 icmp_seq=4 Destination Host Unreachable
==
==
==And pinging anywhere else doesn't work either.. (I also tried telnet/ssh/web - doesn't work).
==
==More ideas? 
==
==
==> This is one way to rewrite the addresses if you need to for a new
==> connection:
==> 
==>  perl -e 'print join(".", reverse map {hex} unpack("(A2)*", shift)),"\n"' C9DB080A
==> 
==
==This is handy, thanks!
==
==> 
==> 
==> Bjørn
==> 
==
==
==
==-- Pasi
==
==

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Pasi Kärkkäinen <pasik@iki.fi> writes:

> # ifconfig wwp0s26u1u5i1
> wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
>         inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
>         ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
>         RX packets 0  bytes 0 (0.0 B)
>         RX errors 1493  dropped 0  overruns 0  frame 0
>
> Note the RX errors.. ? 


Yes, that is not expected and is quite possibly hiding the explanation.

Could you do a usbmon dump to try to capture the contents of the USB
buffers we drop here?  See
https://www.kernel.org/doc/Documentation/usb/usbmon.txt

Note that the text interface may truncate the buffers too early for the
result to be useful.  wireshark/thsark will for example allow you to
capture the whole buffer (when snooping on the "usbmonX" interface - not
the netdev!)

We also have a few debug messages in the driver for different types of
errors we drop.  Turning on those might explain something (assuming you
have DYNAMIC_DEBUG enabled):

  ethtool -s wwp0s26u1u5i1 msglvl rx_err on

Note that these will be logged at "debug" level, so you need to turn on
logging/showing such messages as well.



Bjørn

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Enrico Mioso]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1998 bytes --]

Yes, this is
the
solution, dfefinitively.


On Fri, 14 Mar 2014, Bjørn Mork wrote:

==Date: Fri, 14 Mar 2014 10:24:51
==From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
==To: Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org>
==Cc: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
==    linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==    Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
==Subject: Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
==
==Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:
==
==> # ifconfig wwp0s26u1u5i1
==> wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
==>         inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
==>         inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
==>         ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
==>         RX packets 0  bytes 0 (0.0 B)
==>         RX errors 1493  dropped 0  overruns 0  frame 0
==>
==> Note the RX errors.. ? 
==
==
==Yes, that is not expected and is quite possibly hiding the explanation.
==
==Could you do a usbmon dump to try to capture the contents of the USB
==buffers we drop here?  See
==https://www.kernel.org/doc/Documentation/usb/usbmon.txt
==
==Note that the text interface may truncate the buffers too early for the
==result to be useful.  wireshark/thsark will for example allow you to
==capture the whole buffer (when snooping on the "usbmonX" interface - not
==the netdev!)
==
==We also have a few debug messages in the driver for different types of
==errors we drop.  Turning on those might explain something (assuming you
==have DYNAMIC_DEBUG enabled):
==
==  ethtool -s wwp0s26u1u5i1 msglvl rx_err on
==
==Note that these will be logged at "debug" level, so you need to turn on
==logging/showing such messages as well.
==
==
==
==Bjørn
==

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:
> 
> > # ifconfig wwp0s26u1u5i1
> > wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >         inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
> >         inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
> >         ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
> >         RX packets 0  bytes 0 (0.0 B)
> >         RX errors 1493  dropped 0  overruns 0  frame 0
> >
> > Note the RX errors.. ? 
> 
> 
> Yes, that is not expected and is quite possibly hiding the explanation.
> 

Ok, good to know.

> Could you do a usbmon dump to try to capture the contents of the USB
> buffers we drop here?  See
> https://www.kernel.org/doc/Documentation/usb/usbmon.txt
> 
> Note that the text interface may truncate the buffers too early for the
> result to be useful.  wireshark/thsark will for example allow you to
> capture the whole buffer (when snooping on the "usbmonX" interface - not
> the netdev!)
> 

I'll try that.. 

> We also have a few debug messages in the driver for different types of
> errors we drop.  Turning on those might explain something (assuming you
> have DYNAMIC_DEBUG enabled):
> 
>   ethtool -s wwp0s26u1u5i1 msglvl rx_err on
> 
> Note that these will be logged at "debug" level, so you need to turn on
> logging/showing such messages as well.
> 

# uname -a
Linux localhost.localdomain 3.13.6-200.fc20.x86_64 #1 SMP Fri Mar 7 17:02:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

# grep -i DYNAMIC_DEBUG /boot/config-3.13.6-200.fc20.x86_64
CONFIG_DYNAMIC_DEBUG=y

# echo 8 > /proc/sys/kernel/printk
# cat /proc/sys/kernel/printk
8       4       1       7

# ethtool -s wwp0s26u1u5i1 msglvl rx_err on

Is that enough? I don't see any errors logged in "dmesg" output,
but the RX errors counters do keep increasing in ifconfig output.. 

> 
> 
> Bjørn

Thanks,


-- Pasi

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Pasi Kärkkäinen <pasik@iki.fi> writes:
> On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
>> Pasi Kärkkäinen <pasik@iki.fi> writes:
>> 
>> > # ifconfig wwp0s26u1u5i1
>> > wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>> >         inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
>> >         inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
>> >         ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
>> >         RX packets 0  bytes 0 (0.0 B)
>> >         RX errors 1493  dropped 0  overruns 0  frame 0
>> >
>> > Note the RX errors.. ? 
>> 
>> 
>> Yes, that is not expected and is quite possibly hiding the explanation.
>> 
>
> Ok, good to know.
>
>> Could you do a usbmon dump to try to capture the contents of the USB
>> buffers we drop here?  See
>> https://www.kernel.org/doc/Documentation/usb/usbmon.txt
>> 
>> Note that the text interface may truncate the buffers too early for the
>> result to be useful.  wireshark/thsark will for example allow you to
>> capture the whole buffer (when snooping on the "usbmonX" interface - not
>> the netdev!)
>> 
>
> I'll try that.. 
>
>> We also have a few debug messages in the driver for different types of
>> errors we drop.  Turning on those might explain something (assuming you
>> have DYNAMIC_DEBUG enabled):
>> 
>>   ethtool -s wwp0s26u1u5i1 msglvl rx_err on
>> 
>> Note that these will be logged at "debug" level, so you need to turn on
>> logging/showing such messages as well.
>> 
>
> # uname -a
> Linux localhost.localdomain 3.13.6-200.fc20.x86_64 #1 SMP Fri Mar 7 17:02:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> # grep -i DYNAMIC_DEBUG /boot/config-3.13.6-200.fc20.x86_64
> CONFIG_DYNAMIC_DEBUG=y
>
> # echo 8 > /proc/sys/kernel/printk
> # cat /proc/sys/kernel/printk
> 8       4       1       7
>
> # ethtool -s wwp0s26u1u5i1 msglvl rx_err on
>
> Is that enough?

I believe so, but I don't feel too steady on all the dynamic-ness here.

> I don't see any errors logged in "dmesg" output,
> but the RX errors counters do keep increasing in ifconfig output.. 

OK, let's see if we can figure it out based on the usbmon data.




Bjørn

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Fri, Mar 14, 2014 at 02:33:36PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen <pasik@iki.fi> writes:
> > On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
> >> Pasi Kärkkäinen <pasik@iki.fi> writes:
> >> 
> >> > # ifconfig wwp0s26u1u5i1
> >> > wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >> >         inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
> >> >         inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
> >> >         ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
> >> >         RX packets 0  bytes 0 (0.0 B)
> >> >         RX errors 1493  dropped 0  overruns 0  frame 0
> >> >
> >> > Note the RX errors.. ? 
> >> 
> >> 
> >> Yes, that is not expected and is quite possibly hiding the explanation.
> >> 
> >
> > Ok, good to know.
> >
> >> Could you do a usbmon dump to try to capture the contents of the USB
> >> buffers we drop here?  See
> >> https://www.kernel.org/doc/Documentation/usb/usbmon.txt
> >> 
> >> Note that the text interface may truncate the buffers too early for the
> >> result to be useful.  wireshark/thsark will for example allow you to
> >> capture the whole buffer (when snooping on the "usbmonX" interface - not
> >> the netdev!)
> >> 
> >
> > I'll try that.. 
> >
> >> We also have a few debug messages in the driver for different types of
> >> errors we drop.  Turning on those might explain something (assuming you
> >> have DYNAMIC_DEBUG enabled):
> >> 
> >>   ethtool -s wwp0s26u1u5i1 msglvl rx_err on
> >> 
> >> Note that these will be logged at "debug" level, so you need to turn on
> >> logging/showing such messages as well.
> >> 
> >
> > # uname -a
> > Linux localhost.localdomain 3.13.6-200.fc20.x86_64 #1 SMP Fri Mar 7 17:02:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> >
> > # grep -i DYNAMIC_DEBUG /boot/config-3.13.6-200.fc20.x86_64
> > CONFIG_DYNAMIC_DEBUG=y
> >
> > # echo 8 > /proc/sys/kernel/printk
> > # cat /proc/sys/kernel/printk
> > 8       4       1       7
> >
> > # ethtool -s wwp0s26u1u5i1 msglvl rx_err on
> >
> > Is that enough?
> 
> I believe so, but I don't feel too steady on all the dynamic-ness here.
> 
> > I don't see any errors logged in "dmesg" output,
> > but the RX errors counters do keep increasing in ifconfig output.. 
> 
> OK, let's see if we can figure it out based on the usbmon data.
> 

http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng

(I did move the dongle to a different usb bus nr 3 to make it the only device on that bus before capturing..) 

So what I did:

- Start wireshark capture on USB bus nr 3.
- Plug in the Huawei E3276 dongle.
- Wait for usb_modeswitch to happen.
- Use minicom to talk to /dev/cdc-wdm0 and send AT commands to connect to Internet:
	- ATQ0 V1 E1 S0=0
	- AT^NDISDUP=1,1,"internet"

- After the dongle has connected query for DHCP status:
	- AT^DHCP?

- Launch dhcp client (dhclient) on wwp0s20u1i1 interface.
- Wait for a while and see RX error counters increasing on ifconfig output.
- Cancel (ctrl+c) the dhclient.
- Stop wireshark capture. 


Does that capture file show anything interesting to you? 

> 
> 
> Bjørn


Thanks,

-- Pasi

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Dan Williams]

On Fri, 2014-03-14 at 16:25 +0200, Pasi Kärkkäinen wrote:
> On Fri, Mar 14, 2014 at 02:33:36PM +0100, Bjørn Mork wrote:
> > Pasi Kärkkäinen <pasik@iki.fi> writes:
> > > On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
> > >> Pasi Kärkkäinen <pasik@iki.fi> writes:
> > >> 
> > >> > # ifconfig wwp0s26u1u5i1
> > >> > wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >> >         inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
> > >> >         inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
> > >> >         ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
> > >> >         RX packets 0  bytes 0 (0.0 B)
> > >> >         RX errors 1493  dropped 0  overruns 0  frame 0
> > >> >
> > >> > Note the RX errors.. ? 
> > >> 
> > >> 
> > >> Yes, that is not expected and is quite possibly hiding the explanation.
> > >> 
> > >
> > > Ok, good to know.
> > >
> > >> Could you do a usbmon dump to try to capture the contents of the USB
> > >> buffers we drop here?  See
> > >> https://www.kernel.org/doc/Documentation/usb/usbmon.txt
> > >> 
> > >> Note that the text interface may truncate the buffers too early for the
> > >> result to be useful.  wireshark/thsark will for example allow you to
> > >> capture the whole buffer (when snooping on the "usbmonX" interface - not
> > >> the netdev!)
> > >> 
> > >
> > > I'll try that.. 
> > >
> > >> We also have a few debug messages in the driver for different types of
> > >> errors we drop.  Turning on those might explain something (assuming you
> > >> have DYNAMIC_DEBUG enabled):
> > >> 
> > >>   ethtool -s wwp0s26u1u5i1 msglvl rx_err on
> > >> 
> > >> Note that these will be logged at "debug" level, so you need to turn on
> > >> logging/showing such messages as well.
> > >> 
> > >
> > > # uname -a
> > > Linux localhost.localdomain 3.13.6-200.fc20.x86_64 #1 SMP Fri Mar 7 17:02:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > # grep -i DYNAMIC_DEBUG /boot/config-3.13.6-200.fc20.x86_64
> > > CONFIG_DYNAMIC_DEBUG=y
> > >
> > > # echo 8 > /proc/sys/kernel/printk
> > > # cat /proc/sys/kernel/printk
> > > 8       4       1       7
> > >
> > > # ethtool -s wwp0s26u1u5i1 msglvl rx_err on
> > >
> > > Is that enough?
> > 
> > I believe so, but I don't feel too steady on all the dynamic-ness here.
> > 
> > > I don't see any errors logged in "dmesg" output,
> > > but the RX errors counters do keep increasing in ifconfig output.. 
> > 
> > OK, let's see if we can figure it out based on the usbmon data.
> > 
> 
> http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
> 
> (I did move the dongle to a different usb bus nr 3 to make it the only device on that bus before capturing..) 
> 
> So what I did:
> 
> - Start wireshark capture on USB bus nr 3.
> - Plug in the Huawei E3276 dongle.
> - Wait for usb_modeswitch to happen.
> - Use minicom to talk to /dev/cdc-wdm0 and send AT commands to connect to Internet:
> 	- ATQ0 V1 E1 S0=0
> 	- AT^NDISDUP=1,1,"internet"

Are you sure the device has actually registered with the network at the
point you do the NDISDUP?  At this point what do you get for "AT+CREG?"
and "AT+CFUN?" ?

Dan

> - After the dongle has connected query for DHCP status:
> 	- AT^DHCP?
> 
> - Launch dhcp client (dhclient) on wwp0s20u1i1 interface.
> - Wait for a while and see RX error counters increasing on ifconfig output.
> - Cancel (ctrl+c) the dhclient.
> - Stop wireshark capture. 
> 
> 
> Does that capture file show anything interesting to you? 
> 
> > 
> > 
> > Bjørn
> 
> 
> Thanks,
> 
> -- Pasi
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Fri, Mar 14, 2014 at 12:16:55PM -0500, Dan Williams wrote:
> On Fri, 2014-03-14 at 16:25 +0200, Pasi Kärkkäinen wrote:
> > On Fri, Mar 14, 2014 at 02:33:36PM +0100, Bjørn Mork wrote:
> > > Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:
> > > > On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
> > > >> Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:
> > > >> 
> > > >> > # ifconfig wwp0s26u1u5i1
> > > >> > wwp0s26u1u5i1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > > >> >         inet 10.8.219.204  netmask 255.255.255.248  broadcast 10.8.219.207
> > > >> >         inet6 fe80::e5b:8fff:fe27:9a64  prefixlen 64  scopeid 0x20<link>
> > > >> >         ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
> > > >> >         RX packets 0  bytes 0 (0.0 B)
> > > >> >         RX errors 1493  dropped 0  overruns 0  frame 0
> > > >> >
> > > >> > Note the RX errors.. ? 
> > > >> 
> > > >> 
> > > >> Yes, that is not expected and is quite possibly hiding the explanation.
> > > >> 
> > > >
> > > > Ok, good to know.
> > > >
> > > >> Could you do a usbmon dump to try to capture the contents of the USB
> > > >> buffers we drop here?  See
> > > >> https://www.kernel.org/doc/Documentation/usb/usbmon.txt
> > > >> 
> > > >> Note that the text interface may truncate the buffers too early for the
> > > >> result to be useful.  wireshark/thsark will for example allow you to
> > > >> capture the whole buffer (when snooping on the "usbmonX" interface - not
> > > >> the netdev!)
> > > >> 
> > > >
> > > > I'll try that.. 
> > > >
> > > >> We also have a few debug messages in the driver for different types of
> > > >> errors we drop.  Turning on those might explain something (assuming you
> > > >> have DYNAMIC_DEBUG enabled):
> > > >> 
> > > >>   ethtool -s wwp0s26u1u5i1 msglvl rx_err on
> > > >> 
> > > >> Note that these will be logged at "debug" level, so you need to turn on
> > > >> logging/showing such messages as well.
> > > >> 
> > > >
> > > > # uname -a
> > > > Linux localhost.localdomain 3.13.6-200.fc20.x86_64 #1 SMP Fri Mar 7 17:02:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> > > >
> > > > # grep -i DYNAMIC_DEBUG /boot/config-3.13.6-200.fc20.x86_64
> > > > CONFIG_DYNAMIC_DEBUG=y
> > > >
> > > > # echo 8 > /proc/sys/kernel/printk
> > > > # cat /proc/sys/kernel/printk
> > > > 8       4       1       7
> > > >
> > > > # ethtool -s wwp0s26u1u5i1 msglvl rx_err on
> > > >
> > > > Is that enough?
> > > 
> > > I believe so, but I don't feel too steady on all the dynamic-ness here.
> > > 
> > > > I don't see any errors logged in "dmesg" output,
> > > > but the RX errors counters do keep increasing in ifconfig output.. 
> > > 
> > > OK, let's see if we can figure it out based on the usbmon data.
> > > 
> > 
> > http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
> > 
> > (I did move the dongle to a different usb bus nr 3 to make it the only device on that bus before capturing..) 
> > 
> > So what I did:
> > 
> > - Start wireshark capture on USB bus nr 3.
> > - Plug in the Huawei E3276 dongle.
> > - Wait for usb_modeswitch to happen.
> > - Use minicom to talk to /dev/cdc-wdm0 and send AT commands to connect to Internet:
> > 	- ATQ0 V1 E1 S0=0
> > 	- AT^NDISDUP=1,1,"internet"
> 
> Are you sure the device has actually registered with the network at the
> point you do the NDISDUP?  At this point what do you get for "AT+CREG?"
> and "AT+CFUN?" ?
> 

When capturing the USB traffic I did get the ^NDISSTAT:1,,,"IPV4" notification and the AT^DHCP? 
command showed the IP address and other info so I *assume* it was properly connected.. 
also the LED on the dongle showed it's connected..

So now a fresh start.. Before running NDISDUP I send AT+CREG? and I get this reply:

+CREG: 0,1

Then I send AT+CFUN? and get this reply:

+CFUN: 1

Then I send AT^NDISDUP=1,1,"internet" and get:

OK
^RSSI: 7
^NDISSTAT:1,,,"IPV4"

Then I send AT^DHCP? and get:

^DHCP: 4A503D0A,FCFFFFFF,49503D0A,49503D0A,E67B59C0,E77B59C0,85600,85600
OK


Does that look OK? 

Thanks,

-- Pasi


> Dan
> 
> > - After the dongle has connected query for DHCP status:
> > 	- AT^DHCP?
> > 
> > - Launch dhcp client (dhclient) on wwp0s20u1i1 interface.
> > - Wait for a while and see RX error counters increasing on ifconfig output.
> > - Cancel (ctrl+c) the dhclient.
> > - Stop wireshark capture. 
> > 
> > 
> > Does that capture file show anything interesting to you? 
> > 
> > > 
> > > 
> > > Bjørn
> > 
> > 
> > Thanks,
> > 
> > -- Pasi
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:

> http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
>
> (I did move the dongle to a different usb bus nr 3 to make it the only device on that bus before capturing..) 

Thanks.  That helps.

> So what I did:
>
> - Start wireshark capture on USB bus nr 3.
> - Plug in the Huawei E3276 dongle.
> - Wait for usb_modeswitch to happen.
> - Use minicom to talk to /dev/cdc-wdm0 and send AT commands to connect to Internet:
> 	- ATQ0 V1 E1 S0=0
> 	- AT^NDISDUP=1,1,"internet"
>
> - After the dongle has connected query for DHCP status:
> 	- AT^DHCP?
>
> - Launch dhcp client (dhclient) on wwp0s20u1i1 interface.
> - Wait for a while and see RX error counters increasing on ifconfig output.
> - Cancel (ctrl+c) the dhclient.
> - Stop wireshark capture. 
>
>
> Does that capture file show anything interesting to you? 

I see two devices (excluding the root hub), both with a single
configuration: 
 12d1:14fe (addr: 4)
 12d1:1506 (addr: 5)

The 12d1:14fe device is before mode switching, so I'll just ignore that
and concentrate on the two modem interfaces of the 12d1:1506 device:
0 (serial, AT command) and 1 (NCM combined).

Possibly unrelated, but a bit unexpected:  I see a request for string
descriptor 0xee, which is the "magic Microsoft descriptor".  I don't
know of any Linux software requesting this by default.  Anyone else?
The request results in a stall, so it's obviously unsupported by this
devices and cannot possibly matter.  But I still wonder who sends it...


Anyway, I believe I can see the problem. Or some part of it.  I'm still
not quite sure what the cause is.

If you look at the data sent by the driver to endpoint 0x02 (which is
the endpoint used for NCM data from host to device), you'll see
something like this:

0040  4e 43 4d 48 0c 00 01 00 00 80 0c 00 4e 43 4d 30   NCMH........NCM0
0050  10 00 00 00 b8 00 56 01 00 00 00 00 00 00 00 00   ......V.........
0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00f0  00 00 00 00 00 00 00 00 ff ff ff ff ff ff 0c 5b   ...............[
0100  8f 27 9a 64 08 00 45 10 01 48 00 00 00 00 80 11   .'.d..E..H......
0110  39 96 00 00 00 00 ff ff ff ff 00 44 00 43 01 34   9..........D.C.4
0120  3a dd 01 01 06 00 ef 52 11 28 00 00 00 00 00 00   :......R.(......
0130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 5b   ...............[
0140  8f 27 9a 64 00 00 00 00 00 00 00 00 00 00 00 00   .'.d............
0150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0170  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0180  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0190  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
01a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
01b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
01c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
01d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
01e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
01f0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0200  00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82   ..............c.
0210  53 63 35 01 01 37 0d 01 1c 02 79 0f 06 0c 28 29   Sc5..7....y...()
0220  2a 1a 77 03 3d 07 01 0c 5b 8f 27 9a 64 ff 00 00   *.w.=...[.'.d...
0230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0250  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

followed by lots of zero bytes because we pad to the max size.

Looking at the data receided from the device on endpoint 0x83 (which is
used for data from device to host):

0040  6e 63 6d 68 10 00 00 00 6e 00 00 00 10 00 00 00   ncmh....n.......
0050  6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00   ncm0 ...........
0060  32 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00   2...<...........
0070  00 00 ff ff ff ff ff ff 4c 54 99 45 e5 d5 08 06   ........LT.E....
0080  00 01 08 00 06 04 00 01 4c 54 99 45 e5 d5 0a 3d   ........LT.E...=
0090  8a 41 00 00 00 00 00 00 0a 3d 8a 48 00 00 00 00   .A.......=.H....
00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00         ..............


The padding differences making the latter much more compact can be
ignored.  But do notice the 'ncmh' != 'NCMH' and 'ncm0' != 'NCM0'.
These are all standard NCM header and datagram signatures, but the lower
and upper case versions have different meanings.  The lower case version
means that the device use 32 bit length and index fields, while the
driver use the variants with 16 bit fields.

This explains why the driver drops received frames.  It only supports
the 16 bit variants.  They are mandatory according to the spec and the
driver will never accept buffer sizes big enough for the 32 bit variants
make a difference.  So adding support for the 32 bit versions has so far
seemed pointless.

But here we have a device which does not comform to spec (that's OK,
Huawei doesn't claim it does - this is a vendor specific function after
all), and which seems to be locked to 32 bit mode?  Either it requires
the 32 bit variant, or we are doing something "wrong" during setup to
make the device go into this mode.

Adding 32 bit NCM support should be fairly easy after the changes we
made to support MBIM.  But we need to know when to enable it, or whether
we do something wrong during setup.  So it would be useful to see if the
cdc_ncm_setup function logs any interesting debug messages.

Since you have dynamic debugging, could you do:

  mount -t debugfs none /sys/kernel/debug
  echo "file cdc_ncm.c +fp" >/sys/kernel/debug/dynamic_debug/control

and then reconnect the device while capturing debug output?



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Mon, Mar 17, 2014 at 12:31:53PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen <pasik@iki.fi> writes:
> 
> > http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
> >
> > (I did move the dongle to a different usb bus nr 3 to make it the only device on that bus before capturing..) 
> 
> Thanks.  That helps.
> 
> > So what I did:
> >
> > - Start wireshark capture on USB bus nr 3.
> > - Plug in the Huawei E3276 dongle.
> > - Wait for usb_modeswitch to happen.
> > - Use minicom to talk to /dev/cdc-wdm0 and send AT commands to connect to Internet:
> > 	- ATQ0 V1 E1 S0=0
> > 	- AT^NDISDUP=1,1,"internet"
> >
> > - After the dongle has connected query for DHCP status:
> > 	- AT^DHCP?
> >
> > - Launch dhcp client (dhclient) on wwp0s20u1i1 interface.
> > - Wait for a while and see RX error counters increasing on ifconfig output.
> > - Cancel (ctrl+c) the dhclient.
> > - Stop wireshark capture. 
> >
> >
> > Does that capture file show anything interesting to you? 
> 
> I see two devices (excluding the root hub), both with a single
> configuration: 
>  12d1:14fe (addr: 4)
>  12d1:1506 (addr: 5)
> 
> The 12d1:14fe device is before mode switching, so I'll just ignore that
> and concentrate on the two modem interfaces of the 12d1:1506 device:
> 0 (serial, AT command) and 1 (NCM combined).
> 

Correct. 


> Possibly unrelated, but a bit unexpected:  I see a request for string
> descriptor 0xee, which is the "magic Microsoft descriptor".  I don't
> know of any Linux software requesting this by default.  Anyone else?
> The request results in a stall, so it's obviously unsupported by this
> devices and cannot possibly matter.  But I still wonder who sends it...
> 

Hmm.. no idea about that :) This is a pretty standard Fedora 20 box,
with no thirdparty software.. 


> 
> Anyway, I believe I can see the problem. Or some part of it.  I'm still
> not quite sure what the cause is.
> 
> If you look at the data sent by the driver to endpoint 0x02 (which is
> the endpoint used for NCM data from host to device), you'll see
> something like this:
> 
> 0040  4e 43 4d 48 0c 00 01 00 00 80 0c 00 4e 43 4d 30   NCMH........NCM0
> 0050  10 00 00 00 b8 00 56 01 00 00 00 00 00 00 00 00   ......V.........
> 0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00f0  00 00 00 00 00 00 00 00 ff ff ff ff ff ff 0c 5b   ...............[
> 0100  8f 27 9a 64 08 00 45 10 01 48 00 00 00 00 80 11   .'.d..E..H......
> 0110  39 96 00 00 00 00 ff ff ff ff 00 44 00 43 01 34   9..........D.C.4
> 0120  3a dd 01 01 06 00 ef 52 11 28 00 00 00 00 00 00   :......R.(......
> 0130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 5b   ...............[
> 0140  8f 27 9a 64 00 00 00 00 00 00 00 00 00 00 00 00   .'.d............
> 0150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0170  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0180  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0190  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 01f0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0200  00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82   ..............c.
> 0210  53 63 35 01 01 37 0d 01 1c 02 79 0f 06 0c 28 29   Sc5..7....y...()
> 0220  2a 1a 77 03 3d 07 01 0c 5b 8f 27 9a 64 ff 00 00   *.w.=...[.'.d...
> 0230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 0250  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 
> followed by lots of zero bytes because we pad to the max size.
> 
> Looking at the data receided from the device on endpoint 0x83 (which is
> used for data from device to host):
> 
> 0040  6e 63 6d 68 10 00 00 00 6e 00 00 00 10 00 00 00   ncmh....n.......
> 0050  6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00   ncm0 ...........
> 0060  32 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00   2...<...........
> 0070  00 00 ff ff ff ff ff ff 4c 54 99 45 e5 d5 08 06   ........LT.E....
> 0080  00 01 08 00 06 04 00 01 4c 54 99 45 e5 d5 0a 3d   ........LT.E...=
> 0090  8a 41 00 00 00 00 00 00 0a 3d 8a 48 00 00 00 00   .A.......=.H....
> 00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00         ..............
> 
> 
> The padding differences making the latter much more compact can be
> ignored.  But do notice the 'ncmh' != 'NCMH' and 'ncm0' != 'NCM0'.
> These are all standard NCM header and datagram signatures, but the lower
> and upper case versions have different meanings.  The lower case version
> means that the device use 32 bit length and index fields, while the
> driver use the variants with 16 bit fields.
> 
> This explains why the driver drops received frames.  It only supports
> the 16 bit variants.  They are mandatory according to the spec and the
> driver will never accept buffer sizes big enough for the 32 bit variants
> make a difference.  So adding support for the 32 bit versions has so far
> seemed pointless.
> 
> But here we have a device which does not comform to spec (that's OK,
> Huawei doesn't claim it does - this is a vendor specific function after
> all), and which seems to be locked to 32 bit mode?  Either it requires
> the 32 bit variant, or we are doing something "wrong" during setup to
> make the device go into this mode.
> 

Makes sense.. this seems like a good progress getting the "mystery" of this dongle solved.


> Adding 32 bit NCM support should be fairly easy after the changes we
> made to support MBIM.  But we need to know when to enable it, or whether
> we do something wrong during setup.  So it would be useful to see if the
> cdc_ncm_setup function logs any interesting debug messages.
> 
> Since you have dynamic debugging, could you do:
> 
>   mount -t debugfs none /sys/kernel/debug
>   echo "file cdc_ncm.c +fp" >/sys/kernel/debug/dynamic_debug/control
> 
> and then reconnect the device while capturing debug output?
> 

I just did:

# mount -t debugfs none /sys/kernel/debug
(well it was already mounted by fedora)

# cat /proc/sys/kernel/printk
4       4       1       7

# echo 8 > /proc/sys/kernel/printk
# cat /proc/sys/kernel/printk
8       4       1       7

# echo "file cdc_ncm.c +fp" >/sys/kernel/debug/dynamic_debug/control


And then I connected the dongle.. nothing in dmesg. I also tried changing the filename 
to huawei_cdc_ncm.c but that didn't produce any output either. 

I wonder if i'm missing some commands to get debug output to dmesg.. 

> 
> 
> Bjørn

Thanks,

-- Pasi

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Mon, Mar 17, 2014 at 01:59:19PM +0200, Pasi Kärkkäinen wrote:
> On Mon, Mar 17, 2014 at 12:31:53PM +0100, Bjørn Mork wrote:
> > Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:
> > 
> > > http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
> > >
> > > (I did move the dongle to a different usb bus nr 3 to make it the only device on that bus before capturing..) 
> > 
> > Thanks.  That helps.
> > 
> > > So what I did:
> > >
> > > - Start wireshark capture on USB bus nr 3.
> > > - Plug in the Huawei E3276 dongle.
> > > - Wait for usb_modeswitch to happen.
> > > - Use minicom to talk to /dev/cdc-wdm0 and send AT commands to connect to Internet:
> > > 	- ATQ0 V1 E1 S0=0
> > > 	- AT^NDISDUP=1,1,"internet"
> > >
> > > - After the dongle has connected query for DHCP status:
> > > 	- AT^DHCP?
> > >
> > > - Launch dhcp client (dhclient) on wwp0s20u1i1 interface.
> > > - Wait for a while and see RX error counters increasing on ifconfig output.
> > > - Cancel (ctrl+c) the dhclient.
> > > - Stop wireshark capture. 
> > >
> > >
> > > Does that capture file show anything interesting to you? 
> > 
> > I see two devices (excluding the root hub), both with a single
> > configuration: 
> >  12d1:14fe (addr: 4)
> >  12d1:1506 (addr: 5)
> > 
> > The 12d1:14fe device is before mode switching, so I'll just ignore that
> > and concentrate on the two modem interfaces of the 12d1:1506 device:
> > 0 (serial, AT command) and 1 (NCM combined).
> > 
> 
> Correct. 
> 
> 
> > Possibly unrelated, but a bit unexpected:  I see a request for string
> > descriptor 0xee, which is the "magic Microsoft descriptor".  I don't
> > know of any Linux software requesting this by default.  Anyone else?
> > The request results in a stall, so it's obviously unsupported by this
> > devices and cannot possibly matter.  But I still wonder who sends it...
> > 
> 
> Hmm.. no idea about that :) This is a pretty standard Fedora 20 box,
> with no thirdparty software.. 
> 
> 
> > 
> > Anyway, I believe I can see the problem. Or some part of it.  I'm still
> > not quite sure what the cause is.
> > 
> > If you look at the data sent by the driver to endpoint 0x02 (which is
> > the endpoint used for NCM data from host to device), you'll see
> > something like this:
> > 
> > 0040  4e 43 4d 48 0c 00 01 00 00 80 0c 00 4e 43 4d 30   NCMH........NCM0
> > 0050  10 00 00 00 b8 00 56 01 00 00 00 00 00 00 00 00   ......V.........
> > 0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 00b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 00c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 00d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 00e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 00f0  00 00 00 00 00 00 00 00 ff ff ff ff ff ff 0c 5b   ...............[
> > 0100  8f 27 9a 64 08 00 45 10 01 48 00 00 00 00 80 11   .'.d..E..H......
> > 0110  39 96 00 00 00 00 ff ff ff ff 00 44 00 43 01 34   9..........D.C.4
> > 0120  3a dd 01 01 06 00 ef 52 11 28 00 00 00 00 00 00   :......R.(......
> > 0130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 5b   ...............[
> > 0140  8f 27 9a 64 00 00 00 00 00 00 00 00 00 00 00 00   .'.d............
> > 0150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0170  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0180  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0190  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 01a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 01b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 01c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 01d0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 01e0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 01f0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0200  00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82   ..............c.
> > 0210  53 63 35 01 01 37 0d 01 1c 02 79 0f 06 0c 28 29   Sc5..7....y...()
> > 0220  2a 1a 77 03 3d 07 01 0c 5b 8f 27 9a 64 ff 00 00   *.w.=...[.'.d...
> > 0230  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 0250  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> > 
> > followed by lots of zero bytes because we pad to the max size.
> > 
> > Looking at the data receided from the device on endpoint 0x83 (which is
> > used for data from device to host):
> > 
> > 0040  6e 63 6d 68 10 00 00 00 6e 00 00 00 10 00 00 00   ncmh....n.......
> > 0050  6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00   ncm0 ...........
> > 0060  32 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00   2...<...........
> > 0070  00 00 ff ff ff ff ff ff 4c 54 99 45 e5 d5 08 06   ........LT.E....
> > 0080  00 01 08 00 06 04 00 01 4c 54 99 45 e5 d5 0a 3d   ........LT.E...=
> > 0090  8a 41 00 00 00 00 00 00 0a 3d 8a 48 00 00 00 00   .A.......=.H....
> > 00a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00         ..............
> > 
> > 
> > The padding differences making the latter much more compact can be
> > ignored.  But do notice the 'ncmh' != 'NCMH' and 'ncm0' != 'NCM0'.
> > These are all standard NCM header and datagram signatures, but the lower
> > and upper case versions have different meanings.  The lower case version
> > means that the device use 32 bit length and index fields, while the
> > driver use the variants with 16 bit fields.
> > 
> > This explains why the driver drops received frames.  It only supports
> > the 16 bit variants.  They are mandatory according to the spec and the
> > driver will never accept buffer sizes big enough for the 32 bit variants
> > make a difference.  So adding support for the 32 bit versions has so far
> > seemed pointless.
> > 
> > But here we have a device which does not comform to spec (that's OK,
> > Huawei doesn't claim it does - this is a vendor specific function after
> > all), and which seems to be locked to 32 bit mode?  Either it requires
> > the 32 bit variant, or we are doing something "wrong" during setup to
> > make the device go into this mode.
> > 
> 
> Makes sense.. this seems like a good progress getting the "mystery" of this dongle solved.
> 
> 
> > Adding 32 bit NCM support should be fairly easy after the changes we
> > made to support MBIM.  But we need to know when to enable it, or whether
> > we do something wrong during setup.  So it would be useful to see if the
> > cdc_ncm_setup function logs any interesting debug messages.
> > 
> > Since you have dynamic debugging, could you do:
> > 
> >   mount -t debugfs none /sys/kernel/debug
> >   echo "file cdc_ncm.c +fp" >/sys/kernel/debug/dynamic_debug/control
> > 
> > and then reconnect the device while capturing debug output?
> > 
> 
> I just did:
> 
> # mount -t debugfs none /sys/kernel/debug
> (well it was already mounted by fedora)
> 
> # cat /proc/sys/kernel/printk
> 4       4       1       7
> 
> # echo 8 > /proc/sys/kernel/printk
> # cat /proc/sys/kernel/printk
> 8       4       1       7
> 
> # echo "file cdc_ncm.c +fp" >/sys/kernel/debug/dynamic_debug/control
> 
> 
> And then I connected the dongle.. nothing in dmesg. I also tried changing the filename 
> to huawei_cdc_ncm.c but that didn't produce any output either. 
> 
> I wonder if i'm missing some commands to get debug output to dmesg.. 
> 

After playing with it for a while I got this:

[ 1082.972880] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: dwNtbInMaxSize=262144 dwNtbOutMaxSize=32768 wNdpOutPayloadRemainder=2 wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
[ 1082.972893] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: Using default maximum receive length=32768
[ 1082.973281] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: Setting NTB format to 16-bit failed

.. which looks to be related..


-- Pasi

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Pasi Kärkkäinen <pasik@iki.fi> writes:

> After playing with it for a while I got this:
>
> [ 1082.972880] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: dwNtbInMaxSize=262144 dwNtbOutMaxSize=32768 wNdpOutPayloadRemainder=2 wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
> [ 1082.972893] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: Using default maximum receive length=32768
> [ 1082.973281] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: Setting NTB format to 16-bit failed
>
> .. which looks to be related..

Yes, that is what I expected after thinking long enough to realize that
I could just read this out of the usbmon dump you provided.

Thanks a lot for all your help providing extremely useful debug info
here.  This helped fixing (soon, anyway :-) a nasty bug, hitting only a
few devices.

I still don't know for sure, but I do hope this bug is the real cause of
the problems you are having.  I'll send you a patch for testing as soon
as it is ready.


Bjørn

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Mon, Mar 17, 2014 at 02:15:23PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen <pasik@iki.fi> writes:
> 
> > After playing with it for a while I got this:
> >
> > [ 1082.972880] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: dwNtbInMaxSize=262144 dwNtbOutMaxSize=32768 wNdpOutPayloadRemainder=2 wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
> > [ 1082.972893] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: Using default maximum receive length=32768
> > [ 1082.973281] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: Setting NTB format to 16-bit failed
> >
> > .. which looks to be related..
> 
> Yes, that is what I expected after thinking long enough to realize that
> I could just read this out of the usbmon dump you provided.
>

:)
 
> Thanks a lot for all your help providing extremely useful debug info
> here.  This helped fixing (soon, anyway :-) a nasty bug, hitting only a
> few devices.
> 

No problems. Happy to help to get this device working :) 

> I still don't know for sure, but I do hope this bug is the real cause of
> the problems you are having.  I'll send you a patch for testing as soon
> as it is ready.
> 

Sure. I'll be happy to test the patch!

> 
> Bjørn

Thanks,

-- Pasi

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:
> On Mon, Mar 17, 2014 at 02:15:23PM +0100, Bjørn Mork wrote:
>
>> I still don't know for sure, but I do hope this bug is the real cause of
>> the problems you are having.  I'll send you a patch for testing as soon
>> as it is ready.
>> 
>
> Sure. I'll be happy to test the patch!

I ended up with a simple revert of the buggy commit, except for a
conflict due to unrelated context changes.  This seemed like the
cleanest approach given that this fix also needs to go to stable.

Attaching the first version.  Please give it a try if you can. I've
tested it somewhat myself and it doesn't seem to break anything.  Since
it's a simple revert, there isn't really that much that could go wrong
here...


Bjørn


[-- Attachment #2: 0001-net-cdc_ncm-fix-control-message-ordering.patch --]
[-- Type: text/x-diff, Size: 5748 bytes --]

>From 2ad87cde1d386acc31ac3caf66a24d24423ca721 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Mon, 17 Mar 2014 14:58:06 +0100
Subject: [PATCH] net: cdc_ncm: fix control message ordering
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
introduced a specification violation, which caused setup
errors for some devices. In some cases, these errors
resulted in the device and host disagreeing about shared
settings, with complete failure to communicate as the end
result.

The NCM specification require that some commands are sent
only while the NCM Data Interface is in alternate setting 0.
Reverting the commit ensures that we follow this requirement.

Fixes: 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
Reported-by: Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org>
Reported-by: Thomas Schäfer <tschaefer-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
 drivers/net/usb/cdc_ncm.c   | 48 ++++++++++++++++++++++-----------------------
 include/linux/usb/cdc_ncm.h |  1 +
 2 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index dbff290ed0e4..d350d2795e10 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -68,7 +68,6 @@ static struct usb_driver cdc_ncm_driver;
 static int cdc_ncm_setup(struct usbnet *dev)
 {
 	struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
-	struct usb_cdc_ncm_ntb_parameters ncm_parm;
 	u32 val;
 	u8 flags;
 	u8 iface_no;
@@ -82,22 +81,22 @@ static int cdc_ncm_setup(struct usbnet *dev)
 	err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_PARAMETERS,
 			      USB_TYPE_CLASS | USB_DIR_IN
 			      |USB_RECIP_INTERFACE,
-			      0, iface_no, &ncm_parm,
-			      sizeof(ncm_parm));
+			      0, iface_no, &ctx->ncm_parm,
+			      sizeof(ctx->ncm_parm));
 	if (err < 0) {
 		dev_err(&dev->intf->dev, "failed GET_NTB_PARAMETERS\n");
 		return err; /* GET_NTB_PARAMETERS is required */
 	}
 
 	/* read correct set of parameters according to device mode */
-	ctx->rx_max = le32_to_cpu(ncm_parm.dwNtbInMaxSize);
-	ctx->tx_max = le32_to_cpu(ncm_parm.dwNtbOutMaxSize);
-	ctx->tx_remainder = le16_to_cpu(ncm_parm.wNdpOutPayloadRemainder);
-	ctx->tx_modulus = le16_to_cpu(ncm_parm.wNdpOutDivisor);
-	ctx->tx_ndp_modulus = le16_to_cpu(ncm_parm.wNdpOutAlignment);
+	ctx->rx_max = le32_to_cpu(ctx->ncm_parm.dwNtbInMaxSize);
+	ctx->tx_max = le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize);
+	ctx->tx_remainder = le16_to_cpu(ctx->ncm_parm.wNdpOutPayloadRemainder);
+	ctx->tx_modulus = le16_to_cpu(ctx->ncm_parm.wNdpOutDivisor);
+	ctx->tx_ndp_modulus = le16_to_cpu(ctx->ncm_parm.wNdpOutAlignment);
 	/* devices prior to NCM Errata shall set this field to zero */
-	ctx->tx_max_datagrams = le16_to_cpu(ncm_parm.wNtbOutMaxDatagrams);
-	ntb_fmt_supported = le16_to_cpu(ncm_parm.bmNtbFormatsSupported);
+	ctx->tx_max_datagrams = le16_to_cpu(ctx->ncm_parm.wNtbOutMaxDatagrams);
+	ntb_fmt_supported = le16_to_cpu(ctx->ncm_parm.bmNtbFormatsSupported);
 
 	/* there are some minor differences in NCM and MBIM defaults */
 	if (cdc_ncm_comm_intf_is_mbim(ctx->control->cur_altsetting)) {
@@ -146,7 +145,7 @@ static int cdc_ncm_setup(struct usbnet *dev)
 	}
 
 	/* inform device about NTB input size changes */
-	if (ctx->rx_max != le32_to_cpu(ncm_parm.dwNtbInMaxSize)) {
+	if (ctx->rx_max != le32_to_cpu(ctx->ncm_parm.dwNtbInMaxSize)) {
 		__le32 dwNtbInMaxSize = cpu_to_le32(ctx->rx_max);
 
 		err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_INPUT_SIZE,
@@ -162,14 +161,6 @@ static int cdc_ncm_setup(struct usbnet *dev)
 		dev_dbg(&dev->intf->dev, "Using default maximum transmit length=%d\n",
 			CDC_NCM_NTB_MAX_SIZE_TX);
 		ctx->tx_max = CDC_NCM_NTB_MAX_SIZE_TX;
-
-		/* Adding a pad byte here simplifies the handling in
-		 * cdc_ncm_fill_tx_frame, by making tx_max always
-		 * represent the real skb max size.
-		 */
-		if (ctx->tx_max % usb_maxpacket(dev->udev, dev->out, 1) == 0)
-			ctx->tx_max++;
-
 	}
 
 	/*
@@ -439,6 +430,10 @@ advance:
 		goto error2;
 	}
 
+	/* initialize data interface */
+	if (cdc_ncm_setup(dev))
+		goto error2;
+
 	/* configure data interface */
 	temp = usb_set_interface(dev->udev, iface_no, data_altsetting);
 	if (temp) {
@@ -453,12 +448,6 @@ advance:
 		goto error2;
 	}
 
-	/* initialize data interface */
-	if (cdc_ncm_setup(dev))	{
-		dev_dbg(&intf->dev, "cdc_ncm_setup() failed\n");
-		goto error2;
-	}
-
 	usb_set_intfdata(ctx->data, dev);
 	usb_set_intfdata(ctx->control, dev);
 
@@ -475,6 +464,15 @@ advance:
 	dev->hard_mtu = ctx->tx_max;
 	dev->rx_urb_size = ctx->rx_max;
 
+	/* cdc_ncm_setup will override dwNtbOutMaxSize if it is
+	 * outside the sane range. Adding a pad byte here if necessary
+	 * simplifies the handling in cdc_ncm_fill_tx_frame, making
+	 * tx_max always represent the real skb max size.
+	 */
+	if (ctx->tx_max != le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize) &&
+	    ctx->tx_max % usb_maxpacket(dev->udev, dev->out, 1) == 0)
+		ctx->tx_max++;
+
 	return 0;
 
 error2:
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index c3fa80745996..2c14d9cdd57a 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -88,6 +88,7 @@
 #define cdc_ncm_data_intf_is_mbim(x)  ((x)->desc.bInterfaceProtocol == USB_CDC_MBIM_PROTO_NTB)
 
 struct cdc_ncm_ctx {
+	struct usb_cdc_ncm_ntb_parameters ncm_parm;
 	struct hrtimer tx_timer;
 	struct tasklet_struct bh;
 
-- 
1.9.0

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Enrico Mioso]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1570 bytes --]

I admite you, Bjorn: that's talent.
Let's see how it goes.
And congratulations to Pasik also.




On Mon, 17 Mar 2014, Bjørn Mork wrote:

==Date: Mon, 17 Mar 2014 15:23:22
==From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
==To: Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org>
==Cc: Thomas Schäfer <tschaefer-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
==    netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
==    Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
==Subject: Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
==
==Pasi Kärkkäinen <pasik-X3B1VOXEql0@public.gmane.org> writes:
==> On Mon, Mar 17, 2014 at 02:15:23PM +0100, Bjørn Mork wrote:
==>
==>> I still don't know for sure, but I do hope this bug is the real cause of
==>> the problems you are having.  I'll send you a patch for testing as soon
==>> as it is ready.
==>> 
==>
==> Sure. I'll be happy to test the patch!
==
==I ended up with a simple revert of the buggy commit, except for a
==conflict due to unrelated context changes.  This seemed like the
==cleanest approach given that this fix also needs to go to stable.
==
==Attaching the first version.  Please give it a try if you can. I've
==tested it somewhat myself and it doesn't seem to break anything.  Since
==it's a simple revert, there isn't really that much that could go wrong
==here...
==
==
==Bjørn
==
==

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Mon, Mar 17, 2014 at 03:23:22PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen <pasik@iki.fi> writes:
> > On Mon, Mar 17, 2014 at 02:15:23PM +0100, Bjørn Mork wrote:
> >
> >> I still don't know for sure, but I do hope this bug is the real cause of
> >> the problems you are having.  I'll send you a patch for testing as soon
> >> as it is ready.
> >> 
> >
> > Sure. I'll be happy to test the patch!
> 
> I ended up with a simple revert of the buggy commit, except for a
> conflict due to unrelated context changes.  This seemed like the
> cleanest approach given that this fix also needs to go to stable.
> 
> Attaching the first version.  Please give it a try if you can. I've
> tested it somewhat myself and it doesn't seem to break anything.  Since
> it's a simple revert, there isn't really that much that could go wrong
> here...
> 

I applied the patch on top of Linux 3.13.6 kernel and now I'm able to use the wwan0 NCM interface successfully! 
I do get an IP with a dhcp client (this failed earlier without the patch), and Internet seems to work OK. 
So the patch definitely fixes the problem for me with Huawei E3276 4G/LTE USB dongle. 

Thanks a lot!

Tested-by: Pasi Kärkkäinen <pasik@iki.fi>


-- Pasi

> 
> Bjørn
> 

> From 2ad87cde1d386acc31ac3caf66a24d24423ca721 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@mork.no>
> Date: Mon, 17 Mar 2014 14:58:06 +0100
> Subject: [PATCH] net: cdc_ncm: fix control message ordering
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Commit 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
> introduced a specification violation, which caused setup
> errors for some devices. In some cases, these errors
> resulted in the device and host disagreeing about shared
> settings, with complete failure to communicate as the end
> result.
> 
> The NCM specification require that some commands are sent
> only while the NCM Data Interface is in alternate setting 0.
> Reverting the commit ensures that we follow this requirement.
> 
> Fixes: 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
> Reported-by: Pasi Kärkkäinen <pasik@iki.fi>
> Reported-by: Thomas Schäfer <tschaefer@t-online.de>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
>  drivers/net/usb/cdc_ncm.c   | 48 ++++++++++++++++++++++-----------------------
>  include/linux/usb/cdc_ncm.h |  1 +
>  2 files changed, 24 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index dbff290ed0e4..d350d2795e10 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -68,7 +68,6 @@ static struct usb_driver cdc_ncm_driver;
>  static int cdc_ncm_setup(struct usbnet *dev)
>  {
>  	struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
> -	struct usb_cdc_ncm_ntb_parameters ncm_parm;
>  	u32 val;
>  	u8 flags;
>  	u8 iface_no;
> @@ -82,22 +81,22 @@ static int cdc_ncm_setup(struct usbnet *dev)
>  	err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_PARAMETERS,
>  			      USB_TYPE_CLASS | USB_DIR_IN
>  			      |USB_RECIP_INTERFACE,
> -			      0, iface_no, &ncm_parm,
> -			      sizeof(ncm_parm));
> +			      0, iface_no, &ctx->ncm_parm,
> +			      sizeof(ctx->ncm_parm));
>  	if (err < 0) {
>  		dev_err(&dev->intf->dev, "failed GET_NTB_PARAMETERS\n");
>  		return err; /* GET_NTB_PARAMETERS is required */
>  	}
>  
>  	/* read correct set of parameters according to device mode */
> -	ctx->rx_max = le32_to_cpu(ncm_parm.dwNtbInMaxSize);
> -	ctx->tx_max = le32_to_cpu(ncm_parm.dwNtbOutMaxSize);
> -	ctx->tx_remainder = le16_to_cpu(ncm_parm.wNdpOutPayloadRemainder);
> -	ctx->tx_modulus = le16_to_cpu(ncm_parm.wNdpOutDivisor);
> -	ctx->tx_ndp_modulus = le16_to_cpu(ncm_parm.wNdpOutAlignment);
> +	ctx->rx_max = le32_to_cpu(ctx->ncm_parm.dwNtbInMaxSize);
> +	ctx->tx_max = le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize);
> +	ctx->tx_remainder = le16_to_cpu(ctx->ncm_parm.wNdpOutPayloadRemainder);
> +	ctx->tx_modulus = le16_to_cpu(ctx->ncm_parm.wNdpOutDivisor);
> +	ctx->tx_ndp_modulus = le16_to_cpu(ctx->ncm_parm.wNdpOutAlignment);
>  	/* devices prior to NCM Errata shall set this field to zero */
> -	ctx->tx_max_datagrams = le16_to_cpu(ncm_parm.wNtbOutMaxDatagrams);
> -	ntb_fmt_supported = le16_to_cpu(ncm_parm.bmNtbFormatsSupported);
> +	ctx->tx_max_datagrams = le16_to_cpu(ctx->ncm_parm.wNtbOutMaxDatagrams);
> +	ntb_fmt_supported = le16_to_cpu(ctx->ncm_parm.bmNtbFormatsSupported);
>  
>  	/* there are some minor differences in NCM and MBIM defaults */
>  	if (cdc_ncm_comm_intf_is_mbim(ctx->control->cur_altsetting)) {
> @@ -146,7 +145,7 @@ static int cdc_ncm_setup(struct usbnet *dev)
>  	}
>  
>  	/* inform device about NTB input size changes */
> -	if (ctx->rx_max != le32_to_cpu(ncm_parm.dwNtbInMaxSize)) {
> +	if (ctx->rx_max != le32_to_cpu(ctx->ncm_parm.dwNtbInMaxSize)) {
>  		__le32 dwNtbInMaxSize = cpu_to_le32(ctx->rx_max);
>  
>  		err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_INPUT_SIZE,
> @@ -162,14 +161,6 @@ static int cdc_ncm_setup(struct usbnet *dev)
>  		dev_dbg(&dev->intf->dev, "Using default maximum transmit length=%d\n",
>  			CDC_NCM_NTB_MAX_SIZE_TX);
>  		ctx->tx_max = CDC_NCM_NTB_MAX_SIZE_TX;
> -
> -		/* Adding a pad byte here simplifies the handling in
> -		 * cdc_ncm_fill_tx_frame, by making tx_max always
> -		 * represent the real skb max size.
> -		 */
> -		if (ctx->tx_max % usb_maxpacket(dev->udev, dev->out, 1) == 0)
> -			ctx->tx_max++;
> -
>  	}
>  
>  	/*
> @@ -439,6 +430,10 @@ advance:
>  		goto error2;
>  	}
>  
> +	/* initialize data interface */
> +	if (cdc_ncm_setup(dev))
> +		goto error2;
> +
>  	/* configure data interface */
>  	temp = usb_set_interface(dev->udev, iface_no, data_altsetting);
>  	if (temp) {
> @@ -453,12 +448,6 @@ advance:
>  		goto error2;
>  	}
>  
> -	/* initialize data interface */
> -	if (cdc_ncm_setup(dev))	{
> -		dev_dbg(&intf->dev, "cdc_ncm_setup() failed\n");
> -		goto error2;
> -	}
> -
>  	usb_set_intfdata(ctx->data, dev);
>  	usb_set_intfdata(ctx->control, dev);
>  
> @@ -475,6 +464,15 @@ advance:
>  	dev->hard_mtu = ctx->tx_max;
>  	dev->rx_urb_size = ctx->rx_max;
>  
> +	/* cdc_ncm_setup will override dwNtbOutMaxSize if it is
> +	 * outside the sane range. Adding a pad byte here if necessary
> +	 * simplifies the handling in cdc_ncm_fill_tx_frame, making
> +	 * tx_max always represent the real skb max size.
> +	 */
> +	if (ctx->tx_max != le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize) &&
> +	    ctx->tx_max % usb_maxpacket(dev->udev, dev->out, 1) == 0)
> +		ctx->tx_max++;
> +
>  	return 0;
>  
>  error2:
> diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
> index c3fa80745996..2c14d9cdd57a 100644
> --- a/include/linux/usb/cdc_ncm.h
> +++ b/include/linux/usb/cdc_ncm.h
> @@ -88,6 +88,7 @@
>  #define cdc_ncm_data_intf_is_mbim(x)  ((x)->desc.bInterfaceProtocol == USB_CDC_MBIM_PROTO_NTB)
>  
>  struct cdc_ncm_ctx {
> +	struct usb_cdc_ncm_ntb_parameters ncm_parm;
>  	struct hrtimer tx_timer;
>  	struct tasklet_struct bh;
>  
> -- 
> 1.9.0
> 

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Pasi Kärkkäinen <pasik@iki.fi> writes:

> I applied the patch on top of Linux 3.13.6 kernel and now I'm able to use the wwan0 NCM interface successfully! 
> I do get an IP with a dhcp client (this failed earlier without the patch), and Internet seems to work OK. 
> So the patch definitely fixes the problem for me with Huawei E3276 4G/LTE USB dongle. 
>
> Thanks a lot!
>
> Tested-by: Pasi Kärkkäinen <pasik@iki.fi>

Great!  Thanks a lot for quick testing too.  I'll submit this now.
Might be a bit late for 3.14, but should go to stable the next time
davem submits a batch there.


Bjørn

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> writes:

> But here we have a device which does not comform to spec (that's OK,
> Huawei doesn't claim it does - this is a vendor specific function after
> all), and which seems to be locked to 32 bit mode?  Either it requires
> the 32 bit variant, or we are doing something "wrong" during setup to
> make the device go into this mode.

Yuck.  Looking at the code, we do definitely do something wrong here.
We do this during setup:

        /* set NTB format, if both formats are supported */
        if (ntb_fmt_supported & USB_CDC_NCM_NTH32_SIGN) {
                err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT,
                                       USB_TYPE_CLASS | USB_DIR_OUT
                                       | USB_RECIP_INTERFACE,
                                       USB_CDC_NCM_NTB16_FORMAT,
                                       iface_no, NULL, 0);
                if (err < 0)
                        dev_dbg(&dev->intf->dev, "Setting NTB format to 16-bit failed\n");
        }


But USB_CDC_NCM_NTH32_SIGN isn't a flag mask.  It is a constant matching
the the header signature.  I.e. the 'ncmh' string, or 0x686D636E as the
little endian 32 bit number the macro expands to. The ntb_fmt_supported
variable is the bmNtbFormatsSupported bitmap in CPU endianness.  Bit 0
indicates 16 bit support, bit 1 indicates 32 bit support and the rest is
reserved (zero/ignored).  So the test does actually work because it will
return true of bit 1 is set, but it is fundamentally wrong because it
also inspects a number of bits which the host is required to ignore.

And looking at your dump, I see that the GET_NTB_PARAMETERS response is:

Frame 151: 92 bytes on wire (736 bits), 92 bytes captured (736 bits) on interface 0
[..]
0040  1c 00 03 00 00 00 04 00 04 00 02 00 04 00 00 00   ................
0050  00 80 00 00 04 00 02 00 04 00 00 00               ............

This is the structure:

struct usb_cdc_ncm_ntb_parameters {
        __le16  wLength;
        __le16  bmNtbFormatsSupported;
        __le32  dwNtbInMaxSize;
        __le16  wNdpInDivisor;
        __le16  wNdpInPayloadRemainder;
        __le16  wNdpInAlignment;
        __le16  wPadding1;
        __le32  dwNtbOutMaxSize;
        __le16  wNdpOutDivisor;
        __le16  wNdpOutPayloadRemainder;
        __le16  wNdpOutAlignment;
        __le16  wNtbOutMaxDatagrams;
} __attribute__ ((packed));


So bmNtbFormatsSupported is 0x00000003 as expected and we should execute
the SET_NTB_FORMAT above.  And we do.  I can see these NCM control
requests:

frame 150: in GET_NTB_PARAMETERS
frame 152: out SET_NTB_INPUT_SIZE
frame 154: out SET_CRC_MODE
frame 156: out SET_NTB_FORMAT
frame 158: in GET_MAX_DATAGRAM_SIZE

But looking closer, I see that the SET_NTB_FORMAT returned -EPIPE,
i.e. stall.  The driver currently ignores this error, which is why we
end up with different device and host settings. 

Anyone know what the proper driver action is? Note that this error
cannot happen with a spec conforming device, because SET_NTB_FORMAT
support is required for devices claiming 32 bit support.  So the spec
doesn't tell us what to do.

We do of course want to support all devices.  Is the proper action to
add 32 bit support and fall back to setting that?  What if that fails as
well?  Just silently accept 32 bit NTBs?  I have played with that
thought.  It is possible.  But it's likely not more successful unless we
make it automacally switch to sending such NTBs as well, and I'm not
sure that's a good idea.

Just fail?  Well, that doesn't make this device work...

Wonder what happens if you comment out the SET_NTB_FORMAT command?
Maybe the firmware have some odd logic which unconditionally switches
to 32 bit assuming that the host will only send this command for that
case?  And it fails because the "set 16 bit" parameter is unexpected
given this assumption?



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Bjørn Mork]

Bjørn Mork <bjorn@mork.no> writes:

> But looking closer, I see that the SET_NTB_FORMAT returned -EPIPE,
> i.e. stall.  The driver currently ignores this error, which is why we
> end up with different device and host settings. 
>
> Anyone know what the proper driver action is? Note that this error
> cannot happen with a spec conforming device, because SET_NTB_FORMAT
> support is required for devices claiming 32 bit support.  So the spec
> doesn't tell us what to do.

F..k!  OK, my fault.  Proper fix coming up ASAP.

I believe commit 6a9612e2cb22 "net: cdc_ncm: remove ncm_parm field"
messed up big time, because of my lack of understanding of the
importance of control message ordering in this driver, and additional
sloppy spec reading.

Quoting from section 6.2.5 "SetNtbFormat":

 "The host shall only send this command while the NCM Data Interface is
  in alternate setting 0.

The referenced commit moved the call to cdc_ncm_setup() *after*
the usb_set_interface() for the data interface.  This is likely the
cause of the failure.

Thomas: This is probably what made your devices stop work after v3.12 as
well.  The bug was introduced with v3.13.


Bjørn

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Mrkiko Rs]

Which dhcp client are you using?

Inviato da iPhone

> Il giorno 14/mar/2014, alle ore 08:55, "Pasi Kärkkäinen" <pasik@iki.fi> ha scritto:
>
>> On Fri, Mar 14, 2014 at 12:08:12AM +0200, Pasi Kärkkäinen wrote:
>>> On Thu, Mar 13, 2014 at 04:41:47PM -0500, Dan Williams wrote:
>>>> On Thu, 2014-03-13 at 22:25 +0200, Pasi Kärkkäinen wrote:
>>>>> On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
>>>>>
>>>>> [quote Enrico Mioso]
>>>>>
>>>>> So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which
>>>>> supports devices resembling the NCM standard, but using it also as a mean
>>>>> to encapsulate other protocols, as is the case for the Huawei E3131 and
>>>>> E3251 modem devices.
>>>>
>>>> Hello,
>>>>
>>>> I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
>>>> and thus i'm using the new huawei_cdc_ncm driver.
>>>>
>>>> I'm using the /dev/cdc-wdm0 device to send AT commands to it, and that seems to work,
>>>> so the dongle seems like it's connected (also the LED on the dongle suggests it's connected).
>>>>
>>>> .. the problem is the wwan0 interface (well, udev renames it to wwp0s26u1u5i1) doesn't work.
>>>> Launching a dhcp client on the wwp0s26u1u5i1 doesn't get any IP address.
>>>>
>>>> Any tips how to troubleshoot this?
>>
>> Hi,
>>
>>> Which AT commands are you using to start the data connection?
>>
>> I've been using:
>>
>> ATQ0 V1 E1 S0=0
>> AT^NDISDUP=1,1,"internet"
>> AT^DHCP?
>
> Oh, I forgot to mention.. after I send AT^NDISDUP=1,1,"internet" I get this:
>
> ^NDISSTAT:1,,,"IPV4"
>
> .. which to my understanding means it's connected (1==connected).
> Also sending AT^NDISSTATQRY? results in:
>
> ^NDISSTATQRY: 1,,,"IPV4"
>
>
> But I can't get an IP with dhcp client on the wwan0 interface..
>
>
> -- Pasi
>
>
>>
>>> I believe Huawei says that DHCP on the network port is only supported if
>>> network port's USB interface has Class 0x2 + SubClass [0x6 | 0xd] +
>>> Protocol 0x0.
>>
>> # lsusb | grep -i huawei
>> Bus 001 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
>>
>> # lsusb -t
>> ..
>>        |__ Port 5: Dev 10, If 0, Class=Vendor Specific Class, Driver=option, 480M
>>        |__ Port 5: Dev 10, If 1, Class=Vendor Specific Class, Driver=huawei_cdc_ncm, 480M
>>        |__ Port 5: Dev 10, If 2, Class=Mass Storage, Driver=usb-storage, 480M
>>        |__ Port 5: Dev 10, If 3, Class=Mass Storage, Driver=usb-storage, 480M
>>
>> Bus 001 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
>> Device Descriptor:
>>  bLength                18
>>  bDescriptorType         1
>>  bcdUSB               2.00
>>  bDeviceClass            0 (Defined at Interface level)
>>  bDeviceSubClass         0
>>  bDeviceProtocol         0
>>  bMaxPacketSize0        64
>>  idVendor           0x12d1 Huawei Technologies Co., Ltd.
>>  idProduct          0x1506 Modem/Networkcard
>>  bcdDevice            1.02
>>  iManufacturer           2 HUAWEI Technology
>>  iProduct                1 HUAWEI Mobile
>>  iSerial                 0
>>  bNumConfigurations      1
>>  Configuration Descriptor:
>>    bLength                 9
>>    bDescriptorType         2
>>    wTotalLength          173
>>    bNumInterfaces          4
>>    bConfigurationValue     1
>>    iConfiguration          3 Huawei Configuration
>>    bmAttributes         0x80
>>      (Bus Powered)
>>    MaxPower              500mA
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        0
>>      bAlternateSetting       0
>>      bNumEndpoints           2
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      2
>>      bInterfaceProtocol     18
>>      iInterface              0
>>      ** UNRECOGNIZED:  05 24 00 10 01
>>      ** UNRECOGNIZED:  04 24 02 02
>>      ** UNRECOGNIZED:  05 24 01 00 00
>>      ** UNRECOGNIZED:  06 24 06 00 00 00
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x81  EP 1 IN
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval              32
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x01  EP 1 OUT
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval              32
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        1
>>      bAlternateSetting       0
>>      bNumEndpoints           1
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      2
>>      bInterfaceProtocol     22
>>      iInterface              0
>>      ** UNRECOGNIZED:  05 24 00 10 01
>>      ** UNRECOGNIZED:  06 24 1a 00 01 1f
>>      ** UNRECOGNIZED:  0d 24 0f 04 0f 00 00 00 ea 05 03 00 01
>>      ** UNRECOGNIZED:  05 24 06 01 01
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x82  EP 2 IN
>>        bmAttributes            3
>>          Transfer Type            Interrupt
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0040  1x 64 bytes
>>        bInterval               5
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        1
>>      bAlternateSetting       1
>>      bNumEndpoints           3
>>      bInterfaceClass       255 Vendor Specific Class
>>      bInterfaceSubClass      2
>>      bInterfaceProtocol     22
>>      iInterface              0
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x82  EP 2 IN
>>        bmAttributes            3
>>          Transfer Type            Interrupt
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0040  1x 64 bytes
>>        bInterval               5
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x83  EP 3 IN
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval              32
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x02  EP 2 OUT
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval              32
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        2
>>      bAlternateSetting       0
>>      bNumEndpoints           2
>>      bInterfaceClass         8 Mass Storage
>>      bInterfaceSubClass      6 SCSI
>>      bInterfaceProtocol     80 Bulk-Only
>>      iInterface              0
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x03  EP 3 OUT
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval               0
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x84  EP 4 IN
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval               0
>>    Interface Descriptor:
>>      bLength                 9
>>      bDescriptorType         4
>>      bInterfaceNumber        3
>>      bAlternateSetting       0
>>      bNumEndpoints           2
>>      bInterfaceClass         8 Mass Storage
>>      bInterfaceSubClass      6 SCSI
>>      bInterfaceProtocol     80 Bulk-Only
>>      iInterface              0
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x04  EP 4 OUT
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval               0
>>      Endpoint Descriptor:
>>        bLength                 7
>>        bDescriptorType         5
>>        bEndpointAddress     0x85  EP 5 IN
>>        bmAttributes            2
>>          Transfer Type            Bulk
>>          Synch Type               None
>>          Usage Type               Data
>>        wMaxPacketSize     0x0200  1x 512 bytes
>>        bInterval               0
>> Device Qualifier (for other device speed):
>>  bLength                10
>>  bDescriptorType         6
>>  bcdUSB               2.00
>>  bDeviceClass            0 (Defined at Interface level)
>>  bDeviceSubClass         0
>>  bDeviceProtocol         0
>>  bMaxPacketSize0        64
>>  bNumConfigurations      1
>> Device Status:     0x0000
>>  (Bus Powered)
>>
>>
>>> Lastly, I think the E3276 has a couple of different "modes" that it can
>>> switch into with usb_modeswitch too, and only some modes expose the
>>> right network interface.  What modeswitch command is getting sent to the
>>> device?
>>
>> This is on Fedora 20.
>>
>> Mar 13 23:56:36 localhost logger: usb_modeswitch: using overriding config file /etc/usb_modeswitch.d/12d1:14fe; make sure this is intended
>> Mar 13 23:56:36 localhost logger: usb_modeswitch: please report any new or corrected settings; otherwise, check for outdated files
>> Mar 13 23:56:36 localhost usb_modeswitch: switching device 12d1:14fe on 001/009
>> Mar 13 23:56:37 localhost logger: usb_modeswitch: switched to 12d1:1506 on 001/010
>>
>> # cat /etc/usb_modeswitch.d/12d1:14fe
>>
>> # T-Mobile NL (Huawei E352)
>>
>> TargetVendor=  0x12d1
>> TargetProductList="1506,150f,151d"
>>
>> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>>
>>
>> # grep -i e3276 /etc/usb_modeswitch.d/*
>> /etc/usb_modeswitch.d/12d1:156a:# Huawei E3276s-151 and E3251
>>
>>
>> # cat /etc/usb_modeswitch.d/12d1:156a
>>
>> # Huawei E3276s-151 and E3251
>>
>> TargetVendor=  0x12d1
>> TargetProductList="156b,156c"
>>
>> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>>
>>
>>
>> Hopefully that was enough information..
>>
>> Thanks!
>>
>> -- Pasi
>>
>>
>>> Dan
>>>
>>>> I'm seeing "RX errors" listed for the interface in "ifconfig -a" output.. is that normal?
>>>>
>>>> The device in question is (ATI command output):
>>>>
>>>> Manufacturer: huawei
>>>> Model: E3276
>>>> Revision: 21.263.03.00.07
>>>> IMEI: 863XYZXYZXYZXYZ
>>>> +GCAP: +CGSM,+DS,+ES
>>>>
>>>> Thanks!
>>>>
>>>> -- Pasi
>>>>
>>>>
>>>>> Some precisations are needed however - and I encourage discussion on this: and
>>>>> that's why I'm sending this message with a broader CC.
>>>>> Merging those patches might change:
>>>>> - the way Modem Manager interacts with those devices
>>>>> - some regressions might be possible if there are some unknown firmware
>>>>>  variants around (Franko?)
>>>>>
>>>>> First of all: I observed the behaviours of two devices.
>>>>> Huawei E3131: this device doesn't accept NDIS setup requests unless they're
>>>>> sent via the embedded AT channel exposed by this driver.
>>>>> So actually we gain funcionality in this case!
>>>>>
>>>>> The second case, is the Huawei E3251: which works with standard NCM driver,
>>>>> still exposing an AT embedded channel. Whith this patch set applied, you gain
>>>>> some funcionality, loosing the ability to catch standard NCM events for now.
>>>>> The device will work in both ways with no problems, but this has to be
>>>>> acknowledged and discussed. Might be we can develop this driver further to
>>>>> change this, when more devices are tested.
>>>>>
>>>>> We where thinking Huawei changed their interfaces on new devices - but probably
>>>>> this driver only works around a nice firmware bug present in E3131, which
>>>>> prevented the modem from being used in NDIS mode.
>>>>>
>>>>> I think committing this is definitely wortth-while, since it will allow for
>>>>> more Huawei devices to be used without serial connection. Some devices like the
>>>>> E3251 also, reports some status information only via the embedded AT channel,
>>>>> at least in my case.
>>>>> Note: I'm not subscribed to any list except the Modem Manager's one, so please
>>>>> CC me, thanks!!
>>>>>
>>>>> [/quote]
>>>>>
>>>>> Enrico Mioso (3):
>>>>>  net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
>>>>>  net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
>>>>>  net: cdc_ncm: remove non-standard NCM device IDs
>>>>>
>>>>> drivers/net/usb/Kconfig          |   15 +++
>>>>> drivers/net/usb/Makefile         |    1 +
>>>>> drivers/net/usb/cdc_ncm.c        |   17 +--
>>>>> drivers/net/usb/huawei_cdc_ncm.c |  230 ++++++++++++++++++++++++++++++++++++++
>>>>> include/linux/usb/cdc_ncm.h      |    3 +
>>>>> 5 files changed, 253 insertions(+), 13 deletions(-)
>>>>> create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
>>>>>
>>>>> --
>>>>> 1.7.10.4
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem

[Pasi Kärkkäinen]

On Fri, Mar 14, 2014 at 08:58:03AM +0100, Mrkiko Rs wrote:
> Which dhcp client are you using?
> 

"dhclient" in fedora 20.. 

-- Pasi

> Inviato da iPhone
> 
> > Il giorno 14/mar/2014, alle ore 08:55, "Pasi Kärkkäinen" <pasik@iki.fi> ha scritto:
> >
> >> On Fri, Mar 14, 2014 at 12:08:12AM +0200, Pasi Kärkkäinen wrote:
> >>> On Thu, Mar 13, 2014 at 04:41:47PM -0500, Dan Williams wrote:
> >>>> On Thu, 2014-03-13 at 22:25 +0200, Pasi Kärkkäinen wrote:
> >>>>> On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
> >>>>>
> >>>>> [quote Enrico Mioso]
> >>>>>
> >>>>> So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which
> >>>>> supports devices resembling the NCM standard, but using it also as a mean
> >>>>> to encapsulate other protocols, as is the case for the Huawei E3131 and
> >>>>> E3251 modem devices.
> >>>>
> >>>> Hello,
> >>>>
> >>>> I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
> >>>> and thus i'm using the new huawei_cdc_ncm driver.
> >>>>
> >>>> I'm using the /dev/cdc-wdm0 device to send AT commands to it, and that seems to work,
> >>>> so the dongle seems like it's connected (also the LED on the dongle suggests it's connected).
> >>>>
> >>>> .. the problem is the wwan0 interface (well, udev renames it to wwp0s26u1u5i1) doesn't work.
> >>>> Launching a dhcp client on the wwp0s26u1u5i1 doesn't get any IP address.
> >>>>
> >>>> Any tips how to troubleshoot this?
> >>
> >> Hi,
> >>
> >>> Which AT commands are you using to start the data connection?
> >>
> >> I've been using:
> >>
> >> ATQ0 V1 E1 S0=0
> >> AT^NDISDUP=1,1,"internet"
> >> AT^DHCP?
> >
> > Oh, I forgot to mention.. after I send AT^NDISDUP=1,1,"internet" I get this:
> >
> > ^NDISSTAT:1,,,"IPV4"
> >
> > .. which to my understanding means it's connected (1==connected).
> > Also sending AT^NDISSTATQRY? results in:
> >
> > ^NDISSTATQRY: 1,,,"IPV4"
> >
> >
> > But I can't get an IP with dhcp client on the wwan0 interface..
> >
> >
> > -- Pasi
> >
> >
> >>
> >>> I believe Huawei says that DHCP on the network port is only supported if
> >>> network port's USB interface has Class 0x2 + SubClass [0x6 | 0xd] +
> >>> Protocol 0x0.
> >>
> >> # lsusb | grep -i huawei
> >> Bus 001 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
> >>
> >> # lsusb -t
> >> ..
> >>        |__ Port 5: Dev 10, If 0, Class=Vendor Specific Class, Driver=option, 480M
> >>        |__ Port 5: Dev 10, If 1, Class=Vendor Specific Class, Driver=huawei_cdc_ncm, 480M
> >>        |__ Port 5: Dev 10, If 2, Class=Mass Storage, Driver=usb-storage, 480M
> >>        |__ Port 5: Dev 10, If 3, Class=Mass Storage, Driver=usb-storage, 480M
> >>
> >> Bus 001 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
> >> Device Descriptor:
> >>  bLength                18
> >>  bDescriptorType         1
> >>  bcdUSB               2.00
> >>  bDeviceClass            0 (Defined at Interface level)
> >>  bDeviceSubClass         0
> >>  bDeviceProtocol         0
> >>  bMaxPacketSize0        64
> >>  idVendor           0x12d1 Huawei Technologies Co., Ltd.
> >>  idProduct          0x1506 Modem/Networkcard
> >>  bcdDevice            1.02
> >>  iManufacturer           2 HUAWEI Technology
> >>  iProduct                1 HUAWEI Mobile
> >>  iSerial                 0
> >>  bNumConfigurations      1
> >>  Configuration Descriptor:
> >>    bLength                 9
> >>    bDescriptorType         2
> >>    wTotalLength          173
> >>    bNumInterfaces          4
> >>    bConfigurationValue     1
> >>    iConfiguration          3 Huawei Configuration
> >>    bmAttributes         0x80
> >>      (Bus Powered)
> >>    MaxPower              500mA
> >>    Interface Descriptor:
> >>      bLength                 9
> >>      bDescriptorType         4
> >>      bInterfaceNumber        0
> >>      bAlternateSetting       0
> >>      bNumEndpoints           2
> >>      bInterfaceClass       255 Vendor Specific Class
> >>      bInterfaceSubClass      2
> >>      bInterfaceProtocol     18
> >>      iInterface              0
> >>      ** UNRECOGNIZED:  05 24 00 10 01
> >>      ** UNRECOGNIZED:  04 24 02 02
> >>      ** UNRECOGNIZED:  05 24 01 00 00
> >>      ** UNRECOGNIZED:  06 24 06 00 00 00
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x81  EP 1 IN
> >>        bmAttributes            2
> >>          Transfer Type            Bulk
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0200  1x 512 bytes
> >>        bInterval              32
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x01  EP 1 OUT
> >>        bmAttributes            2
> >>          Transfer Type            Bulk
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0200  1x 512 bytes
> >>        bInterval              32
> >>    Interface Descriptor:
> >>      bLength                 9
> >>      bDescriptorType         4
> >>      bInterfaceNumber        1
> >>      bAlternateSetting       0
> >>      bNumEndpoints           1
> >>      bInterfaceClass       255 Vendor Specific Class
> >>      bInterfaceSubClass      2
> >>      bInterfaceProtocol     22
> >>      iInterface              0
> >>      ** UNRECOGNIZED:  05 24 00 10 01
> >>      ** UNRECOGNIZED:  06 24 1a 00 01 1f
> >>      ** UNRECOGNIZED:  0d 24 0f 04 0f 00 00 00 ea 05 03 00 01
> >>      ** UNRECOGNIZED:  05 24 06 01 01
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x82  EP 2 IN
> >>        bmAttributes            3
> >>          Transfer Type            Interrupt
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0040  1x 64 bytes
> >>        bInterval               5
> >>    Interface Descriptor:
> >>      bLength                 9
> >>      bDescriptorType         4
> >>      bInterfaceNumber        1
> >>      bAlternateSetting       1
> >>      bNumEndpoints           3
> >>      bInterfaceClass       255 Vendor Specific Class
> >>      bInterfaceSubClass      2
> >>      bInterfaceProtocol     22
> >>      iInterface              0
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x82  EP 2 IN
> >>        bmAttributes            3
> >>          Transfer Type            Interrupt
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0040  1x 64 bytes
> >>        bInterval               5
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x83  EP 3 IN
> >>        bmAttributes            2
> >>          Transfer Type            Bulk
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0200  1x 512 bytes
> >>        bInterval              32
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x02  EP 2 OUT
> >>        bmAttributes            2
> >>          Transfer Type            Bulk
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0200  1x 512 bytes
> >>        bInterval              32
> >>    Interface Descriptor:
> >>      bLength                 9
> >>      bDescriptorType         4
> >>      bInterfaceNumber        2
> >>      bAlternateSetting       0
> >>      bNumEndpoints           2
> >>      bInterfaceClass         8 Mass Storage
> >>      bInterfaceSubClass      6 SCSI
> >>      bInterfaceProtocol     80 Bulk-Only
> >>      iInterface              0
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x03  EP 3 OUT
> >>        bmAttributes            2
> >>          Transfer Type            Bulk
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0200  1x 512 bytes
> >>        bInterval               0
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x84  EP 4 IN
> >>        bmAttributes            2
> >>          Transfer Type            Bulk
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0200  1x 512 bytes
> >>        bInterval               0
> >>    Interface Descriptor:
> >>      bLength                 9
> >>      bDescriptorType         4
> >>      bInterfaceNumber        3
> >>      bAlternateSetting       0
> >>      bNumEndpoints           2
> >>      bInterfaceClass         8 Mass Storage
> >>      bInterfaceSubClass      6 SCSI
> >>      bInterfaceProtocol     80 Bulk-Only
> >>      iInterface              0
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x04  EP 4 OUT
> >>        bmAttributes            2
> >>          Transfer Type            Bulk
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0200  1x 512 bytes
> >>        bInterval               0
> >>      Endpoint Descriptor:
> >>        bLength                 7
> >>        bDescriptorType         5
> >>        bEndpointAddress     0x85  EP 5 IN
> >>        bmAttributes            2
> >>          Transfer Type            Bulk
> >>          Synch Type               None
> >>          Usage Type               Data
> >>        wMaxPacketSize     0x0200  1x 512 bytes
> >>        bInterval               0
> >> Device Qualifier (for other device speed):
> >>  bLength                10
> >>  bDescriptorType         6
> >>  bcdUSB               2.00
> >>  bDeviceClass            0 (Defined at Interface level)
> >>  bDeviceSubClass         0
> >>  bDeviceProtocol         0
> >>  bMaxPacketSize0        64
> >>  bNumConfigurations      1
> >> Device Status:     0x0000
> >>  (Bus Powered)
> >>
> >>
> >>> Lastly, I think the E3276 has a couple of different "modes" that it can
> >>> switch into with usb_modeswitch too, and only some modes expose the
> >>> right network interface.  What modeswitch command is getting sent to the
> >>> device?
> >>
> >> This is on Fedora 20.
> >>
> >> Mar 13 23:56:36 localhost logger: usb_modeswitch: using overriding config file /etc/usb_modeswitch.d/12d1:14fe; make sure this is intended
> >> Mar 13 23:56:36 localhost logger: usb_modeswitch: please report any new or corrected settings; otherwise, check for outdated files
> >> Mar 13 23:56:36 localhost usb_modeswitch: switching device 12d1:14fe on 001/009
> >> Mar 13 23:56:37 localhost logger: usb_modeswitch: switched to 12d1:1506 on 001/010
> >>
> >> # cat /etc/usb_modeswitch.d/12d1:14fe
> >>
> >> # T-Mobile NL (Huawei E352)
> >>
> >> TargetVendor=  0x12d1
> >> TargetProductList="1506,150f,151d"
> >>
> >> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
> >>
> >>
> >> # grep -i e3276 /etc/usb_modeswitch.d/*
> >> /etc/usb_modeswitch.d/12d1:156a:# Huawei E3276s-151 and E3251
> >>
> >>
> >> # cat /etc/usb_modeswitch.d/12d1:156a
> >>
> >> # Huawei E3276s-151 and E3251
> >>
> >> TargetVendor=  0x12d1
> >> TargetProductList="156b,156c"
> >>
> >> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
> >>
> >>
> >>
> >> Hopefully that was enough information..
> >>
> >> Thanks!
> >>
> >> -- Pasi
> >>
> >>
> >>> Dan
> >>>
> >>>> I'm seeing "RX errors" listed for the interface in "ifconfig -a" output.. is that normal?
> >>>>
> >>>> The device in question is (ATI command output):
> >>>>
> >>>> Manufacturer: huawei
> >>>> Model: E3276
> >>>> Revision: 21.263.03.00.07
> >>>> IMEI: 863XYZXYZXYZXYZ
> >>>> +GCAP: +CGSM,+DS,+ES
> >>>>
> >>>> Thanks!
> >>>>
> >>>> -- Pasi
> >>>>
> >>>>
> >>>>> Some precisations are needed however - and I encourage discussion on this: and
> >>>>> that's why I'm sending this message with a broader CC.
> >>>>> Merging those patches might change:
> >>>>> - the way Modem Manager interacts with those devices
> >>>>> - some regressions might be possible if there are some unknown firmware
> >>>>>  variants around (Franko?)
> >>>>>
> >>>>> First of all: I observed the behaviours of two devices.
> >>>>> Huawei E3131: this device doesn't accept NDIS setup requests unless they're
> >>>>> sent via the embedded AT channel exposed by this driver.
> >>>>> So actually we gain funcionality in this case!
> >>>>>
> >>>>> The second case, is the Huawei E3251: which works with standard NCM driver,
> >>>>> still exposing an AT embedded channel. Whith this patch set applied, you gain
> >>>>> some funcionality, loosing the ability to catch standard NCM events for now.
> >>>>> The device will work in both ways with no problems, but this has to be
> >>>>> acknowledged and discussed. Might be we can develop this driver further to
> >>>>> change this, when more devices are tested.
> >>>>>
> >>>>> We where thinking Huawei changed their interfaces on new devices - but probably
> >>>>> this driver only works around a nice firmware bug present in E3131, which
> >>>>> prevented the modem from being used in NDIS mode.
> >>>>>
> >>>>> I think committing this is definitely wortth-while, since it will allow for
> >>>>> more Huawei devices to be used without serial connection. Some devices like the
> >>>>> E3251 also, reports some status information only via the embedded AT channel,
> >>>>> at least in my case.
> >>>>> Note: I'm not subscribed to any list except the Modem Manager's one, so please
> >>>>> CC me, thanks!!
> >>>>>
> >>>>> [/quote]
> >>>>>
> >>>>> Enrico Mioso (3):
> >>>>>  net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
> >>>>>  net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
> >>>>>  net: cdc_ncm: remove non-standard NCM device IDs
> >>>>>
> >>>>> drivers/net/usb/Kconfig          |   15 +++
> >>>>> drivers/net/usb/Makefile         |    1 +
> >>>>> drivers/net/usb/cdc_ncm.c        |   17 +--
> >>>>> drivers/net/usb/huawei_cdc_ncm.c |  230 ++++++++++++++++++++++++++++++++++++++
> >>>>> include/linux/usb/cdc_ncm.h      |    3 +
> >>>>> 5 files changed, 253 insertions(+), 13 deletions(-)
> >>>>> create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
> >>>>>
> >>>>> --
> >>>>> 1.7.10.4
> >>>>>
> >>>>> --
> >>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >>>>> the body of a message to majordomo@vger.kernel.org
> >>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>> --
> >>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> >>>> the body of a message to majordomo@vger.kernel.org
> >>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >>>