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
