bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
Correction: Unfortunately, there was a bug in my test program, an '\r' was added to the AT command at each lap of the loop... So the driver reboots when 120 superfluous '\r' are included in the AT message. May still be a bug, but a less obvious one. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
On Mon, Nov 03, 2014 at 09:18:10PM +0100, Erik Alapää wrote: Correction: Unfortunately, there was a bug in my test program, an '\r' was added to the AT command at each lap of the loop... So the driver reboots when 120 superfluous '\r' are included in the AT message. May still be a bug, but a less obvious one. This really sounds like a bug in the device itself, not in the kernel driver, as there's nothing we can do about this. Have you tried reporting it to the hardware company? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
Will try reporting to the hw company, maybe there is a firmware upgrade on the horizon. /Erik Alapää On Mon, Nov 3, 2014 at 9:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Nov 03, 2014 at 09:18:10PM +0100, Erik Alapää wrote: Correction: Unfortunately, there was a bug in my test program, an '\r' was added to the AT command at each lap of the loop... So the driver reboots when 120 superfluous '\r' are included in the AT message. May still be a bug, but a less obvious one. This really sounds like a bug in the device itself, not in the kernel driver, as there's nothing we can do about this. Have you tried reporting it to the hardware company? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
On Fri, Oct 3, 2014 at 10:01 AM, Erik Alapää erik.ala...@gmail.com wrote: Problem: When connecting to a Huawei E3276 LTE modem using 'AT+CGACT=1,1' in minicom over /dev/cdc-wdm1, the cdc-wdm device freezes for 3-5 minutes until accepting AT commands again. Keywords: huawei_cdc_ncm, LTE, AT commands, cdc-wdm Detailed problem description: I am using a 4G mobile USB dongle with the huawei_cdc_ncm driver in Linux kernel 3.16. In general, the driver works well, but one major issue is that bringing the modem up using 'AT+CGACT=1.1' freezes the /dev/cdc-wdm1 control device for 3-5 minutes. After that, the device accepts more commands over minicom. Note that I do get connectivity, directly after the CGACT I can get a DHCP address for wwan0 and the bandwidth is approx 20 Mbit/s downstream and 6 Mbit/s upstream. I have tried building a custom 3.16 kernel with a few printk:s in cdc_ncm.c and huawei_cdc_ncm.c, but found nothing suspicious. Kernel version (from /proc/version): 3.16 Environment: Thinkpad L440 64-bit x86 (Intel Core i5-4200M cpu) laptop with Kubuntu 14.04.1 LTS Kernel modules: huawei_cdc_ncm,cdc_ncm Workaround: Bring up the device with AT^NDISDUP=1,1,internet.telenor.se instead. Also worth noting is that AT+CGACT=1,1 does not freeze the control connection if using /dev/ttyUSB0. Regardless of the actual issue in the kernel driver, if any, NDISDUP in the cdc-wdm device is the way to go to connect that modem. -- Aleksander https://aleksander.es -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
On Sat, Oct 4, 2014 at 12:02 AM, Oliver Neukum oli...@neukum.org wrote:
I suggest you take an usbmon trace to look for the CDC notification.
Hi again, took a while to respond because I have been away on a trip.
I am new at sniffing USB traffic, so forgive me if the below info is
inadequate. I reset the 4G modem with AT+CFUN=4 followed by AT+CFUN=6.
The modem is on bus 3, device id 10, and after reset the new device Id
is 11. Below is a text dump (exported from wireshark) of the first few
USB packets seen when the device pops up after reset (takes ~10
seconds from AT+CFUN=6 is issued).
Two additional things to note:
1. When I do the command that freezes the cdc-wdm control line for
several minutes (AT+CGACT=1,1), I do not see the AT command in the USB
dump as I do with other AT commands like AT+CFUN.
2. In the kernel logs I can see an error message (not caused by
AT+CGACT) that emanates from linux/drivers/usb/class/cdc-wdm.c:
Oct 7 13:43:36 hilbert kernel: [13872.317954] huawei_cdc_ncm 3-3:1.2:
unknown notification 3 received: index 2 len 4
Excerpt from when device pops up after reset with AT+CFUN:
No. Time SourceDestination
Protocol Length Info
2995 53.388617000 host 11.0 USB
64 GET DESCRIPTOR Request DEVICE
Frame 2995: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct 7, 2014 11:52:44.22313 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1412675564.22313 seconds
[Time delta from previous captured frame: 0.015917000 seconds]
[Time delta from previous displayed frame: 0.015917000 seconds]
[Time since reference or first frame: 53.388617000 seconds]
Frame Number: 2995
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0x8800c7aa2b40
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
1... = Direction: IN (1)
.000 = Endpoint value: 0
Device: 11
URB bus id: 3
Device setup request: relevant (0)
Data: not present ('')
URB sec: 1412675564
URB usec: 223130
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 18
Data length [bytes]: 0
[Response in: 2996]
URB setup
bmRequestType: 0x80
1... = Direction: Device-to-host
.00. = Type: Standard (0x00)
...0 = Recipient: Device (0x00)
bRequest: GET DESCRIPTOR (6)
Descriptor Index: 0x00
bDescriptorType: DEVICE (1)
Language Id: no language specified (0x)
wLength: 18
No. Time SourceDestination
Protocol Length Info
2996 53.388789000 11.0 host USB
82 GET DESCRIPTOR Response DEVICE
Frame 2996: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct 7, 2014 11:52:44.223302000 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1412675564.223302000 seconds
[Time delta from previous captured frame: 0.000172000 seconds]
[Time delta from previous displayed frame: 0.000172000 seconds]
[Time since reference or first frame: 53.388789000 seconds]
Frame Number: 2996
Frame Length: 82 bytes (656 bits)
Capture Length: 82 bytes (656 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0x8800c7aa2b40
URB type: URB_COMPLETE ('C')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
1... = Direction: IN (1)
.000 = Endpoint value: 0
Device: 11
URB bus id: 3
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1412675564
URB usec: 223302
URB status: Success (0)
URB length [bytes]: 18
Data length [bytes]: 18
[Request in: 2995]
[Time from request: 0.000172000 seconds]
[bInterfaceClass: Unknown (0x)]
DEVICE DESCRIPTOR
bLength: 18
bDescriptorType: DEVICE (1)
bcdUSB: 0x0200
bDeviceClass: Device (0x00)
bDeviceSubClass: 0
bDeviceProtocol: 0 (Use class code info from Interface Descriptors)
bMaxPacketSize0: 64
idVendor: Huawei Technologies Co., Ltd. (0x12d1)
idProduct: Modem/Networkcard (0x1506)
bcdDevice: 0x0102
iManufacturer: 3
iProduct: 2
iSerialNumber: 0
bNumConfigurations: 1
No. Time SourceDestination
Protocol Length Info
2997 53.388816000 host 11.0 USB
64 GET DESCRIPTOR Request CONFIGURATION
Frame 2997: 64 bytes
Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
On Sat, Oct 4, 2014 at 12:02 AM, Oliver Neukum oli...@neukum.org wrote:
I suggest you take an usbmon trace to look for the CDC notification.
Hi again, took a while to respond because I have been away on a trip.
I am new at sniffing USB traffic, so forgive me if the below info is
inadequate. I reset the 4G modem with AT+CFUN=4 followed by AT+CFUN=6.
The modem is on bus 3, device id 10, and after reset the new device Id
is 11. Below is a text dump (exported from wireshark) of the first few
USB packets seen when the device pops up after reset (takes ~10
seconds from AT+CFUN=6 is issued).
Two additional things to note:
1. When I do the command that freezes the cdc-wdm control line for
several minutes (AT+CGACT=1,1), I do not see the AT command in the USB
dump as I do with other AT commands like AT+CFUN.
2. In the kernel logs I can see an error message (not caused by
AT+CGACT) that emanates from linux/drivers/usb/class/cdc-wdm.c:
Oct 7 13:43:36 hilbert kernel: [13872.317954] huawei_cdc_ncm 3-3:1.2:
unknown notification 3 received: index 2 len 4
Excerpt from when device pops up after reset with AT+CFUN:
No. Time SourceDestination
Protocol Length Info
2995 53.388617000 host 11.0 USB
64 GET DESCRIPTOR Request DEVICE
Frame 2995: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct 7, 2014 11:52:44.22313 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1412675564.22313 seconds
[Time delta from previous captured frame: 0.015917000 seconds]
[Time delta from previous displayed frame: 0.015917000 seconds]
[Time since reference or first frame: 53.388617000 seconds]
Frame Number: 2995
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0x8800c7aa2b40
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
1... = Direction: IN (1)
.000 = Endpoint value: 0
Device: 11
URB bus id: 3
Device setup request: relevant (0)
Data: not present ('')
URB sec: 1412675564
URB usec: 223130
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 18
Data length [bytes]: 0
[Response in: 2996]
URB setup
bmRequestType: 0x80
1... = Direction: Device-to-host
.00. = Type: Standard (0x00)
...0 = Recipient: Device (0x00)
bRequest: GET DESCRIPTOR (6)
Descriptor Index: 0x00
bDescriptorType: DEVICE (1)
Language Id: no language specified (0x)
wLength: 18
No. Time SourceDestination
Protocol Length Info
2996 53.388789000 11.0 host USB
82 GET DESCRIPTOR Response DEVICE
Frame 2996: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct 7, 2014 11:52:44.223302000 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1412675564.223302000 seconds
[Time delta from previous captured frame: 0.000172000 seconds]
[Time delta from previous displayed frame: 0.000172000 seconds]
[Time since reference or first frame: 53.388789000 seconds]
Frame Number: 2996
Frame Length: 82 bytes (656 bits)
Capture Length: 82 bytes (656 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0x8800c7aa2b40
URB type: URB_COMPLETE ('C')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
1... = Direction: IN (1)
.000 = Endpoint value: 0
Device: 11
URB bus id: 3
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1412675564
URB usec: 223302
URB status: Success (0)
URB length [bytes]: 18
Data length [bytes]: 18
[Request in: 2995]
[Time from request: 0.000172000 seconds]
[bInterfaceClass: Unknown (0x)]
DEVICE DESCRIPTOR
bLength: 18
bDescriptorType: DEVICE (1)
bcdUSB: 0x0200
bDeviceClass: Device (0x00)
bDeviceSubClass: 0
bDeviceProtocol: 0 (Use class code info from Interface Descriptors)
bMaxPacketSize0: 64
idVendor: Huawei Technologies Co., Ltd. (0x12d1)
idProduct: Modem/Networkcard (0x1506)
bcdDevice: 0x0102
iManufacturer: 3
iProduct: 2
iSerialNumber: 0
bNumConfigurations: 1
No. Time SourceDestination
Protocol Length Info
2997 53.388816000 host 11.0 USB
64 GET DESCRIPTOR Request CONFIGURATION
Frame 2997: 64 bytes
Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
On Sat, Oct 4, 2014 at 12:02 AM, Oliver Neukum oli...@neukum.org wrote: I suggest you take an usbmon trace to look for the CDC notification. OK, I will do so and post the results. Thank you for the suggestion. Regards, /Erik Alapää -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
On Sat, Oct 4, 2014 at 12:02 AM, Oliver Neukum oli...@neukum.org wrote: I suggest you take an usbmon trace to look for the CDC notification. OK, I will do so and post the results. Thank you for the suggestion. Regards, /Erik Alapää On Sat, Oct 4, 2014 at 12:02 AM, Oliver Neukum oli...@neukum.org wrote: On Fri, 2014-10-03 at 10:01 +0200, Erik Alapää wrote: Workaround: Bring up the device with AT^NDISDUP=1,1,internet.telenor.se instead. Also worth noting is that AT+CGACT=1,1 does not freeze the control connection if using /dev/ttyUSB0. If more info is needed, let me know and I will provide it. I suggest you take an usbmon trace to look for the CDC notification. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
Problem: When connecting to a Huawei E3276 LTE modem using 'AT+CGACT=1,1' in minicom over /dev/cdc-wdm1, the cdc-wdm device freezes for 3-5 minutes until accepting AT commands again. Keywords: huawei_cdc_ncm, LTE, AT commands, cdc-wdm Detailed problem description: I am using a 4G mobile USB dongle with the huawei_cdc_ncm driver in Linux kernel 3.16. In general, the driver works well, but one major issue is that bringing the modem up using 'AT+CGACT=1.1' freezes the /dev/cdc-wdm1 control device for 3-5 minutes. After that, the device accepts more commands over minicom. Note that I do get connectivity, directly after the CGACT I can get a DHCP address for wwan0 and the bandwidth is approx 20 Mbit/s downstream and 6 Mbit/s upstream. I have tried building a custom 3.16 kernel with a few printk:s in cdc_ncm.c and huawei_cdc_ncm.c, but found nothing suspicious. Kernel version (from /proc/version): 3.16 Environment: Thinkpad L440 64-bit x86 (Intel Core i5-4200M cpu) laptop with Kubuntu 14.04.1 LTS Kernel modules: huawei_cdc_ncm,cdc_ncm Workaround: Bring up the device with AT^NDISDUP=1,1,internet.telenor.se instead. Also worth noting is that AT+CGACT=1,1 does not freeze the control connection if using /dev/ttyUSB0. If more info is needed, let me know and I will provide it. /Erik Alapää -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem
On Fri, 2014-10-03 at 10:01 +0200, Erik Alapää wrote: Workaround: Bring up the device with AT^NDISDUP=1,1,internet.telenor.se instead. Also worth noting is that AT+CGACT=1,1 does not freeze the control connection if using /dev/ttyUSB0. If more info is needed, let me know and I will provide it. I suggest you take an usbmon trace to look for the CDC notification. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
