bugreport: Netdev watchdog timeout on wwan0, huawei E3276 modem always fails on GSM UDP up/downlink iperf3
Problem: up/dowlink UDP with iperf3 over GSM crashes Huawei E3276 USB modem on 32-bit Debian-stable (wheezy) with 3.13 kernel and newer kernels. Error also seen on 64-bit machines/Linux kernels. Keywords: huawei_cdc_ncm, GSM, cdc-wdm, wwan0, netdev watchdog Detailed problem description: Sending/receiving UDP 100+100kbit/s up-and-downlink UDP traffic with 2 iperf3 processes over a Huawei E3276 USB modem in GSM mode (GSM RAT) *always* fails after 3-15 minutes. Modem disconnects and kernel log shows 'NETDEV WATCHDOG: wwan0 (huawei_cdc_ncm): transmit queue 0 timed out'. Reproduced on a range of real and virtualized systems, all running Debian or Kubuntu Linux with Linux kernel supporting the modem (3.13 and higher). Output below is from a debian-jessie (unstable) system with custom-built dbg kernel, but debian wheezy (stable) also reproduces same bug. A clean way to reproduce is to use a clean debian wheezy install and only adding iperf3 and a 3.16 kernel from debian-unstable. At the end of this post I paste an excerpt from kern.log, if more logs etc are needed I can provide them. Command line of test application (showing uplink iperf UDP/GSM, downlink is the same but with -R switch): './iperf3 -B MODEM DHCP ADDR -u -t 3600 -i 5 -p 5503 -b 100K -c IP ADDR OF IPERF SERVER' Distribution: debian-unstable Kernel version: 3.16.7, vanilla debian unstable 3.17.0-trunk-686-pae, 3.17.2. All kernels that support the E3276 modem (kernels from 3.13 and upward) seem to fail. Kernel modules: huawei_cdc_ncm, cdc_ncm, cdc_wdm, usb_wwan Modem firmware version: 21.436.03.00.00 Lsusb showing modem/vendor id: Bus 003 Device 027: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard Output of lsb_release -a: Distributor ID: Debian Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 Codename: jessie Additional info: E3276 modem seems to be stable in Windows, so it may be an issue with the huawei_cdc_ncm driver in Linux. But it may still be a modem hw/firmware issue, and the netdev watchdog timeout on wwan0 could be caused by modem firmware crash. Modem also works much better in Linux when using 3G (WCDMA) or 4G (LTE) instead of 2G (GSM). Merry Christmas, /Erik Alapää Excerpt from kern.log: Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877612] [ cut here ] Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877647] WARNING: CPU: 0 PID: 0 at /build/linux-n7UL8Q/linux-3.17.4/net/sched/sch_generic.c:264 dev_watchdog+0x1ec/0x200() Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877649] NETDEV WATCHDOG: wwan0 (huawei_cdc_ncm): transmit queue 0 timed out Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877650] Modules linked in: huawei_cdc_ncm nls_utf8 udf isofs crc_itu_t ppdev lp rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc loop cdc_wdm option usb_storage usb_wwan cdc_ncm usbserial usbnet snd_ens1371 snd_seq_midi snd_seq_midi_event snd_rawmidi ecb btusb bluetooth rfkill snd_ac97_codec snd_pcm snd_seq snd_seq_device snd_timer snd coretemp soundcore psmouse vmw_balloon ac97_bus serio_raw crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul ablk_helper cryptd evdev gameport pcspkr parport_pc parport vmwgfx shpchp ttm drm_kms_helper drm i2c_piix4 i2c_core processor thermal_sys vmw_vmci button battery ac ext4 crc16 mbcache jbd2 sr_mod cdrom sg ata_generic hid_generic usbhid hid sd_mod crc_t10dif crct10dif_common crc32c_intel floppy ehci_pci uhci_hcd ehci_hcd pcnet32 mii usbcore usb_common ata_piix mptspi scsi_transport_spi mptscsih mptbase libata scsi_mod [last unloaded: huawei_cdc_ncm] Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877768] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-trunk-686-pae #1 Debian 3.17.4-1~exp1 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877769] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.80] de409ef4 c149bcff de409f04 c10598a8 c15d8868 de409f20 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.82] c15d88a4 0108 c13de8bc 0108 c13de8bc 0009 db25b800 fff09a96 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.83] fb7e de409f0c c10598f3 0009 de409f04 c15d8868 de409f20 de409f40 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.85] Call Trace: Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877780] [c149bcff] ? dump_stack+0x3e/0x4e Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877785] [c10598a8] ? warn_slowpath_common+0x88/0xa0 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877787] [c13de8bc] ? dev_watchdog+0x1ec/0x200 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877788] [c13de8bc] ? dev_watchdog+0x1ec/0x200 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877789] [c10598f3] ? warn_slowpath_fmt+0x33/0x40 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877790] [c13de8bc] ? dev_watchdog+0x1ec/0x200 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877796] [c10acb20] ? call_timer_fn+0x30/0x100 Dec 15 13:12:10 vmw
bugreport: huawei_cdc_ncm kernel driver and control device unbinds after 121 AT commands sent
Problem: The huawei_cdc_ncm driver (for the 4G LTE dongle Huawei
E3276) gets unregistered and the control device /dev/cdc-wdmN
disappears after sending exactly 121 AT commands to the device. After
a few seconds, the driver is re-registered and the control device
reappears. Test program causing the error included at the end of this
message.
Keywords: huawei_cdc_ncm, LTE, AT commands, cdc-wdm
Detailed problem description:
The behavior has been verified on kernel 3.16.0 and on kernel 3.17.1,
on a 64-bit Core i5 x86 machine and on a a smaller embedded 32-bit x86
machine. Exact command does not matter, used 'ATI' and 'AT^HCSQ?'
with same result. Distros used are Kubuntu 14.04.1 LTS on the i5 and
Debian Wheezy on the embedded machine.
Kernel modules: huawei_cdc_ncm, cdc_ncm
The test program contains some rudimentary C++ but should be readable
even to die-hard C guys ;) The program is crude but hopefully useful
for debugging.
If more info is needed, let me know and I will provide it.
Best regards,
/Erik Alapää
//
// Program that causes temporary loss of cdc-wdmN device and huawei_cdc_ncm
// driver reload after 121 AT commands sent.
//
// No makefile, just compile with 'g++ -g wdm_err.cpp -o wdm_err'.
//
// Usage, see 'Usage: ' message in the code below.
//
#include cstdio
#include cstdlib
#include cerrno
#include cstring
#include sys/time.h
#include sys/types.h
#include fcntl.h
#include unistd.h
#include stdexcept
#include string
#include iostream
#include fstream
using std::string;
using std::cout;
using std::runtime_error;
using std::endl;
using std::fstream;
int main(int argc, char* argv[])
{
fd_set rfds;
fd_set wfds;
struct timeval tv;
struct timeval tv2;
int retval;
int n;
const int SZ = 512;
char errbuf[SZ];
char ctrlin_buf[SZ];
//string command(AT^HCSQ?\n);
string command(ATI\n);
string response;
string resp_line;
fstream at_file;
int sleep_us = 0;
int sendcount = 0;
char CTRL_DEVICE[SZ];
// Get file descriptor for select()
if (argc == 3)
{
cout Setting AT ctrl device to \' argv[1] \'\n;
strcpy(CTRL_DEVICE, argv[1]);
cout Sleep interval sleep_us us\n;
}
else
{
cout Usage: rw2 at-ctrl-device sleeptime in us (ctrl
is typically /dev/cdc-wdmN)\n\n;
throw std::runtime_error(Too few args, no ctrl device specified!);
}
int ctrl = open(CTRL_DEVICE, O_RDWR);
if (ctrl == -1)
{
throw std::runtime_error(strerror_r(errno, errbuf, SZ));
}
sleep_us = atoi(argv[2]);
// Get fstream for C++-style reading and writing
at_file.open(CTRL_DEVICE, std::fstream::in | std::fstream::out |
std::fstream::app);
if (!at_file)
{
throw runtime_error(Could not open wdm device file!\n);
}
for (;;)
{
tv.tv_sec = 10;
tv.tv_usec = 0;
FD_ZERO(rfds);
FD_SET(ctrl, rfds);
FD_ZERO(wfds);
FD_SET(ctrl, wfds);
if (at_file.bad())
{
throw runtime_error(wdm device file gone bad!);
}
tv2.tv_sec = 0;
tv2.tv_usec = sleep_us;
retval = select(0, NULL, NULL, NULL, tv2); // sleep
if (retval == -1)
{
throw std::runtime_error(strerror_r(errno, errbuf, SZ));
}
retval = select(ctrl+1, rfds, wfds, NULL, tv);
if (retval == -1)
{
throw std::runtime_error(strerror_r(errno, errbuf, SZ));
}
if (at_file.bad())
{
throw runtime_error(wdm device file gone bad!);
}
if (FD_ISSET(ctrl, wfds))
{
cout Writing command \' command \' to ctrl device\n;
command += \r;
at_file command endl;
cout sendcount++;
}
if (FD_ISSET(ctrl, rfds))
{
n = read(ctrl, ctrlin_buf, SZ); // ifstrem::read fails for
some reason
if (n == -1)
{
throw std::runtime_error(strerror_r(errno, errbuf, SZ));
}
response = std::string(ctrlin_buf, n);
cout response endl;
}
}
return 0;
}
--
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
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
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 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
1... = Direction: IN Endpoint 0011 = Endpoint Number: 0x03 bmAttributes: 0x02 ..10 = Transfertype: Bulk-Transfer (0x02) 00.. = Synchronisationtype: No Sync (0x00) ..00 = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 512 ..10 = Maximum Packet Size: 512 bInterval: 32 ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: ENDPOINT (5) bEndpointAddress: 0x02 OUT Endpoint:2 0... = Direction: OUT Endpoint 0010 = Endpoint Number: 0x02 bmAttributes: 0x02 ..10 = Transfertype: Bulk-Transfer (0x02) 00.. = Synchronisationtype: No Sync (0x00) ..00 = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 512 ..10 = Maximum Packet Size: 512 bInterval: 32 INTERFACE DESCRIPTOR (2.0): class Vendor Specific bLength: 9 bDescriptorType: INTERFACE (4) bInterfaceNumber: 2 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0x02 bInterfaceProtocol: 0x16 iInterface: 0 UNKNOWN DESCRIPTOR bLength: 5 bDescriptorType: Unknown (36) UNKNOWN DESCRIPTOR bLength: 6 bDescriptorType: Unknown (36) UNKNOWN DESCRIPTOR bLength: 13 bDescriptorType: Unknown (36) UNKNOWN DESCRIPTOR bLength: 5 bDescriptorType: Unknown (36) ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: ENDPOINT (5) bEndpointAddress: 0x84 IN Endpoint:4 1... = Direction: IN Endpoint 0100 = Endpoint Number: 0x04 bmAttributes: 0x03 ..11 = Transfertype: Interrupt-Transfer (0x03) 00.. = Synchronisationtype: No Sync (0x00) ..00 = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 64 ...0 0... = Transactions per microframe: 1 (0) ..00 0100 = Maximum Packet Size: 64 bInterval: 5 INTERFACE DESCRIPTOR (2.1): class Vendor Specific bLength: 9 bDescriptorType: INTERFACE (4) bInterfaceNumber: 2 bAlternateSetting: 1 bNumEndpoints: 3 bInterfaceClass: Vendor Specific (0xff) bInterfaceSubClass: 0x02 bInterfaceProtocol: 0x16 iInterface: 0 ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: ENDPOINT (5) bEndpointAddress: 0x84 IN Endpoint:4 1... = Direction: IN Endpoint 0100 = Endpoint Number: 0x04 bmAttributes: 0x03 ..11 = Transfertype: Interrupt-Transfer (0x03) 00.. = Synchronisationtype: No Sync (0x00) ..00 = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 64 ...0 0... = Transactions per microframe: 1 (0) ..00 0100 = Maximum Packet Size: 64 bInterval: 5 ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: ENDPOINT (5) bEndpointAddress: 0x85 IN Endpoint:5 1... = Direction: IN Endpoint 0101 = Endpoint Number: 0x05 bmAttributes: 0x02 ..10 = Transfertype: Bulk-Transfer (0x02) 00.. = Synchronisationtype: No Sync (0x00) ..00 = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 512 ..10 = Maximum Packet Size: 512 bInterval: 32 ENDPOINT DESCRIPTOR bLength: 7 bDescriptorType: ENDPOINT (5) bEndpointAddress: 0x03 OUT Endpoint:3 0... = Direction: OUT Endpoint 0011 = Endpoint Number: 0x03 bmAttributes: 0x02 ..10 = Transfertype: Bulk-Transfer (0x02) 00.. = Synchronisationtype: No Sync (0x00) ..00 = Behaviourtype: Data-Endpoint (0x00) wMaxPacketSize: 512 ..10 = Maximum Packet Size: 512 bInterval: 32 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
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
