* [PATCH net-next v6 0/3] The huawei_cdc_ncm driver
@ 2013-11-04 8:50 Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use Bjørn Mork
` (4 more replies)
0 siblings, 5 replies; 34+ messages in thread
From: Bjørn Mork @ 2013-11-04 8:50 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Enrico Mioso, Oliver Neukum,
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH net-next v6 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
2013-11-04 8:50 [PATCH net-next v6 0/3] The huawei_cdc_ncm driver Bjørn Mork
@ 2013-11-04 8:50 ` Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver Bjørn Mork
` (3 subsequent siblings)
4 siblings, 0 replies; 34+ messages in thread
From: Bjørn Mork @ 2013-11-04 8:50 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Enrico Mioso, Oliver Neukum, 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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH net-next v6 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
2013-11-04 8:50 [PATCH net-next v6 0/3] The huawei_cdc_ncm driver Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use Bjørn Mork
@ 2013-11-04 8:50 ` Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 3/3] net: cdc_ncm: remove non-standard NCM device IDs Bjørn Mork
` (2 subsequent siblings)
4 siblings, 0 replies; 34+ messages in thread
From: Bjørn Mork @ 2013-11-04 8:50 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Enrico Mioso, Oliver Neukum, 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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH net-next v6 3/3] net: cdc_ncm: remove non-standard NCM device IDs
2013-11-04 8:50 [PATCH net-next v6 0/3] The huawei_cdc_ncm driver Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver Bjørn Mork
@ 2013-11-04 8:50 ` Bjørn Mork
2013-11-05 20:22 ` [PATCH net-next v6 0/3] The huawei_cdc_ncm driver David Miller
2014-03-13 20:25 ` [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem Pasi Kärkkäinen
4 siblings, 0 replies; 34+ messages in thread
From: Bjørn Mork @ 2013-11-04 8:50 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Enrico Mioso, Oliver Neukum, 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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver
2013-11-04 8:50 [PATCH net-next v6 0/3] The huawei_cdc_ncm driver Bjørn Mork
` (2 preceding siblings ...)
2013-11-04 8:50 ` [PATCH net-next v6 3/3] net: cdc_ncm: remove non-standard NCM device IDs Bjørn Mork
@ 2013-11-05 20:22 ` David Miller
2014-03-13 20:25 ` [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem Pasi Kärkkäinen
4 siblings, 0 replies; 34+ messages in thread
From: David Miller @ 2013-11-05 20:22 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, mrkiko.rs, oliver
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!
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2013-11-04 8:50 [PATCH net-next v6 0/3] The huawei_cdc_ncm driver Bjørn Mork
` (3 preceding siblings ...)
2013-11-05 20:22 ` [PATCH net-next v6 0/3] The huawei_cdc_ncm driver David Miller
@ 2014-03-13 20:25 ` Pasi Kärkkäinen
2014-03-13 21:41 ` Dan Williams
4 siblings, 1 reply; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-13 20:25 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-13 20:25 ` [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem Pasi Kärkkäinen
@ 2014-03-13 21:41 ` Dan Williams
2014-03-13 22:08 ` Pasi Kärkkäinen
0 siblings, 1 reply; 34+ messages in thread
From: Dan Williams @ 2014-03-13 21:41 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Bjørn Mork, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-13 21:41 ` Dan Williams
@ 2014-03-13 22:08 ` Pasi Kärkkäinen
2014-03-14 7:55 ` Pasi Kärkkäinen
[not found] ` <385896107.16855.1394783754007.JavaMail.mobile-sync@vcpd12>
0 siblings, 2 replies; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-13 22:08 UTC (permalink / raw)
To: Dan Williams
Cc: Bjørn Mork, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
>
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-13 22:08 ` Pasi Kärkkäinen
@ 2014-03-14 7:55 ` Pasi Kärkkäinen
[not found] ` <20140314075548.GX3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
[not found] ` <385896107.16855.1394783754007.JavaMail.mobile-sync@vcpd12>
1 sibling, 1 reply; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-14 7:55 UTC (permalink / raw)
To: Dan Williams
Cc: Bjørn Mork, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
> >
> >
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <385896107.16855.1394783754007.JavaMail.mobile-sync@vcpd12>
@ 2014-03-14 7:58 ` Mrkiko Rs
2014-03-14 8:01 ` Pasi Kärkkäinen
0 siblings, 1 reply; 34+ messages in thread
From: Mrkiko Rs @ 2014-03-14 7:58 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Dan Williams, Bjørn Mork,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 7:58 ` Mrkiko Rs
@ 2014-03-14 8:01 ` Pasi Kärkkäinen
0 siblings, 0 replies; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-14 8:01 UTC (permalink / raw)
To: Mrkiko Rs
Cc: Dan Williams, Bjørn Mork, netdev@vger.kernel.org,
linux-usb@vger.kernel.org, Oliver Neukum
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
> >>>
> >>>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <20140314075548.GX3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
@ 2014-03-14 8:34 ` Bjørn Mork
2014-03-14 8:41 ` Pasi Kärkkäinen
0 siblings, 1 reply; 34+ messages in thread
From: Bjørn Mork @ 2014-03-14 8:34 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Dan Williams, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 8:34 ` Bjørn Mork
@ 2014-03-14 8:41 ` Pasi Kärkkäinen
2014-03-14 8:58 ` Bjørn Mork
0 siblings, 1 reply; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-14 8:41 UTC (permalink / raw)
To: Bjørn Mork
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 8:41 ` Pasi Kärkkäinen
@ 2014-03-14 8:58 ` Bjørn Mork
2014-03-14 9:05 ` Pasi Kärkkäinen
0 siblings, 1 reply; 34+ messages in thread
From: Bjørn Mork @ 2014-03-14 8:58 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 8:58 ` Bjørn Mork
@ 2014-03-14 9:05 ` Pasi Kärkkäinen
2014-03-14 9:24 ` Enrico Mioso
2014-03-14 9:24 ` Bjørn Mork
0 siblings, 2 replies; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-14 9:05 UTC (permalink / raw)
To: Bjørn Mork
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 9:05 ` Pasi Kärkkäinen
@ 2014-03-14 9:24 ` Enrico Mioso
2014-03-14 9:24 ` Bjørn Mork
1 sibling, 0 replies; 34+ messages in thread
From: Enrico Mioso @ 2014-03-14 9:24 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Bjørn Mork, Dan Williams, netdev, linux-usb, Enrico Mioso,
Oliver Neukum
[-- 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
==
==
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 9:05 ` Pasi Kärkkäinen
2014-03-14 9:24 ` Enrico Mioso
@ 2014-03-14 9:24 ` Bjørn Mork
[not found] ` <87ob19nndo.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
1 sibling, 1 reply; 34+ messages in thread
From: Bjørn Mork @ 2014-03-14 9:24 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <87ob19nndo.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
@ 2014-03-14 9:37 ` Enrico Mioso
2014-03-14 12:59 ` Pasi Kärkkäinen
1 sibling, 0 replies; 34+ messages in thread
From: Enrico Mioso @ 2014-03-14 9:37 UTC (permalink / raw)
To: Bjørn Mork
Cc: Pasi Kärkkäinen, Dan Williams,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum
[-- 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
==
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <87ob19nndo.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2014-03-14 9:37 ` Enrico Mioso
@ 2014-03-14 12:59 ` Pasi Kärkkäinen
2014-03-14 13:33 ` Bjørn Mork
1 sibling, 1 reply; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-14 12:59 UTC (permalink / raw)
To: Bjørn Mork
Cc: Dan Williams, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 12:59 ` Pasi Kärkkäinen
@ 2014-03-14 13:33 ` Bjørn Mork
2014-03-14 14:25 ` Pasi Kärkkäinen
0 siblings, 1 reply; 34+ messages in thread
From: Bjørn Mork @ 2014-03-14 13:33 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 13:33 ` Bjørn Mork
@ 2014-03-14 14:25 ` Pasi Kärkkäinen
2014-03-14 17:16 ` Dan Williams
[not found] ` <20140314142559.GD3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
0 siblings, 2 replies; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-14 14:25 UTC (permalink / raw)
To: Bjørn Mork
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-14 14:25 ` Pasi Kärkkäinen
@ 2014-03-14 17:16 ` Dan Williams
[not found] ` <1394817415.5829.6.camel-ZWpNTBV2bRGs1BDpvl8NfQ@public.gmane.org>
[not found] ` <20140314142559.GD3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
1 sibling, 1 reply; 34+ messages in thread
From: Dan Williams @ 2014-03-14 17:16 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Bjørn Mork, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <1394817415.5829.6.camel-ZWpNTBV2bRGs1BDpvl8NfQ@public.gmane.org>
@ 2014-03-14 17:33 ` Pasi Kärkkäinen
0 siblings, 0 replies; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-14 17:33 UTC (permalink / raw)
To: Dan Williams
Cc: Bjørn Mork, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <20140314142559.GD3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
@ 2014-03-17 11:31 ` Bjørn Mork
2014-03-17 11:59 ` Pasi Kärkkäinen
[not found] ` <87k3btm57a.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
0 siblings, 2 replies; 34+ messages in thread
From: Bjørn Mork @ 2014-03-17 11:31 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Dan Williams, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-17 11:31 ` Bjørn Mork
@ 2014-03-17 11:59 ` Pasi Kärkkäinen
[not found] ` <20140317115919.GK3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
[not found] ` <87k3btm57a.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
1 sibling, 1 reply; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-17 11:59 UTC (permalink / raw)
To: Bjørn Mork
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <20140317115919.GK3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
@ 2014-03-17 12:45 ` Pasi Kärkkäinen
2014-03-17 13:15 ` Bjørn Mork
0 siblings, 1 reply; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-17 12:45 UTC (permalink / raw)
To: Bjørn Mork
Cc: Dan Williams, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <87k3btm57a.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
@ 2014-03-17 12:56 ` Bjørn Mork
2014-03-17 13:10 ` Bjørn Mork
0 siblings, 1 reply; 34+ messages in thread
From: Bjørn Mork @ 2014-03-17 12:56 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Dan Williams, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-17 12:56 ` Bjørn Mork
@ 2014-03-17 13:10 ` Bjørn Mork
0 siblings, 0 replies; 34+ messages in thread
From: Bjørn Mork @ 2014-03-17 13:10 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Thomas Schäfer, Dan Williams, netdev, linux-usb,
Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-17 12:45 ` Pasi Kärkkäinen
@ 2014-03-17 13:15 ` Bjørn Mork
2014-03-17 13:17 ` Pasi Kärkkäinen
0 siblings, 1 reply; 34+ messages in thread
From: Bjørn Mork @ 2014-03-17 13:15 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-17 13:15 ` Bjørn Mork
@ 2014-03-17 13:17 ` Pasi Kärkkäinen
[not found] ` <20140317131731.GM3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
0 siblings, 1 reply; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-17 13:17 UTC (permalink / raw)
To: Bjørn Mork
Cc: Dan Williams, netdev, linux-usb, Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <20140317131731.GM3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
@ 2014-03-17 14:23 ` Bjørn Mork
[not found] ` <87txawlx9h.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2014-03-17 15:05 ` Pasi Kärkkäinen
0 siblings, 2 replies; 34+ messages in thread
From: Bjørn Mork @ 2014-03-17 14:23 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Thomas Schäfer, Dan Williams, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Enrico Mioso, Oliver Neukum
[-- 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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
[not found] ` <87txawlx9h.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
@ 2014-03-17 14:46 ` Enrico Mioso
0 siblings, 0 replies; 34+ messages in thread
From: Enrico Mioso @ 2014-03-17 14:46 UTC (permalink / raw)
To: Bjørn Mork
Cc: Pasi Kärkkäinen, Thomas Schäfer, Dan Williams,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum
[-- 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
==
==
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-17 14:23 ` Bjørn Mork
[not found] ` <87txawlx9h.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
@ 2014-03-17 15:05 ` Pasi Kärkkäinen
2014-03-17 15:07 ` Bjørn Mork
1 sibling, 1 reply; 34+ messages in thread
From: Pasi Kärkkäinen @ 2014-03-17 15:05 UTC (permalink / raw)
To: Bjørn Mork
Cc: Thomas Schäfer, Dan Williams, netdev, linux-usb,
Enrico Mioso, Oliver Neukum
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
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
2014-03-17 15:05 ` Pasi Kärkkäinen
@ 2014-03-17 15:07 ` Bjørn Mork
0 siblings, 0 replies; 34+ messages in thread
From: Bjørn Mork @ 2014-03-17 15:07 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: Thomas Schäfer, Dan Williams, netdev, linux-usb,
Enrico Mioso, Oliver Neukum
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
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2014-03-17 15:29 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-04 8:50 [PATCH net-next v6 0/3] The huawei_cdc_ncm driver Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver Bjørn Mork
2013-11-04 8:50 ` [PATCH net-next v6 3/3] net: cdc_ncm: remove non-standard NCM device IDs Bjørn Mork
2013-11-05 20:22 ` [PATCH net-next v6 0/3] The huawei_cdc_ncm driver David Miller
2014-03-13 20:25 ` [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem Pasi Kärkkäinen
2014-03-13 21:41 ` Dan Williams
2014-03-13 22:08 ` Pasi Kärkkäinen
2014-03-14 7:55 ` Pasi Kärkkäinen
[not found] ` <20140314075548.GX3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
2014-03-14 8:34 ` Bjørn Mork
2014-03-14 8:41 ` Pasi Kärkkäinen
2014-03-14 8:58 ` Bjørn Mork
2014-03-14 9:05 ` Pasi Kärkkäinen
2014-03-14 9:24 ` Enrico Mioso
2014-03-14 9:24 ` Bjørn Mork
[not found] ` <87ob19nndo.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2014-03-14 9:37 ` Enrico Mioso
2014-03-14 12:59 ` Pasi Kärkkäinen
2014-03-14 13:33 ` Bjørn Mork
2014-03-14 14:25 ` Pasi Kärkkäinen
2014-03-14 17:16 ` Dan Williams
[not found] ` <1394817415.5829.6.camel-ZWpNTBV2bRGs1BDpvl8NfQ@public.gmane.org>
2014-03-14 17:33 ` Pasi Kärkkäinen
[not found] ` <20140314142559.GD3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
2014-03-17 11:31 ` Bjørn Mork
2014-03-17 11:59 ` Pasi Kärkkäinen
[not found] ` <20140317115919.GK3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
2014-03-17 12:45 ` Pasi Kärkkäinen
2014-03-17 13:15 ` Bjørn Mork
2014-03-17 13:17 ` Pasi Kärkkäinen
[not found] ` <20140317131731.GM3200-GxtO3QLqHcLR7s880joybQ@public.gmane.org>
2014-03-17 14:23 ` Bjørn Mork
[not found] ` <87txawlx9h.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2014-03-17 14:46 ` Enrico Mioso
2014-03-17 15:05 ` Pasi Kärkkäinen
2014-03-17 15:07 ` Bjørn Mork
[not found] ` <87k3btm57a.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2014-03-17 12:56 ` Bjørn Mork
2014-03-17 13:10 ` Bjørn Mork
[not found] ` <385896107.16855.1394783754007.JavaMail.mobile-sync@vcpd12>
2014-03-14 7:58 ` Mrkiko Rs
2014-03-14 8:01 ` Pasi Kärkkäinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).