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
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 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 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 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
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 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 on wire (512 b
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 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 on wire (512 b
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ää 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 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 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