GNOME Bugzilla – Bug 698897
[MM 0.8] Detection and NDISDUP problems with Huawei E3276
Last modified: 2014-10-15 16:13:12 UTC
This is apparently an NDISDUP-only device driven by cdc-ncm but MM has troubles controlling it. It does *not* use PPP at all, since the only serial port it exposes does not have an interrupt endpoint, and thus cannot support PPP. Bus 003 Device 007: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM 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 E398 LTE/UMTS/GSM 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) [73457.125251] usbcore: registered new interface driver option [73457.125279] usbserial: USB Serial support registered for GSM modem (1-port) [73457.128607] usb 3-2: MAC-Address: 0c:5b:8f:27:9a:64 [73457.129102] cdc_ncm 3-2:1.1 wwan0: register 'cdc_ncm' at usb-0000:00:1d.7-2, Mobile Broadband Network Device, 0c:5b:8f:27:9a:64 [73457.129156] usbcore: registered new interface driver cdc_ncm [73457.130743] option 3-2:1.0: GSM modem (1-port) converter detected [73457.131088] usb 3-2: GSM modem (1-port) converter now attached to ttyUSB0 The cdc-ncm driver has this line: /* Huawei NCM devices disguised as vendor specific */ { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16), .driver_info = (unsigned long)&wwan_info, }, thus it grabs this device. However, our udev rules have this: SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="02", ATTRS{bInterfaceSubClass}=="06",ATTRS{bInterfaceProtocol}=="00", ENV{ID_MM_HUAWEI_NDISDUP_SUPPORTED}="1" SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="02", ATTRS{bInterfaceSubClass}=="0d",ATTRS{bInterfaceProtocol}=="00", ENV{ID_MM_HUAWEI_NDISDUP_SUPPORTED}="1" which do *not* tag this device as being NDISDUP capable, yet NDISDUP does work on this device. I'd like to get some clarification from Huawei here as to whether the udev rules are incomplete.
Also very odd is that the modem doesn't respond to MM's queries on the AT port, but it does work in minicom. Are there specific requirements for serial setup on this device? ModemManager[14266]: <info> [1366921559.467216] [mm-serial-port.c:857] mm_serial_port_open(): (ttyUSB0) opening serial port... ModemManager[14266]: <warn> [1366921559.471333] [mm-serial-port.c:414] real_config_fd(): (ttyUSB0): port attributes not fully set ModemManager[14266]: <debug> [1366921559.472768] [mm-serial-port.c:926] mm_serial_port_open(): (ttyUSB0) device open count is 1 (open) ModemManager[14266]: <debug> [1366921559.574412] [mm-at-serial-port.c:392] debug_log(): (ttyUSB0): --> 'AT^CURC=0<CR>' ModemManager[14266]: <debug> [1366921563.304671] [mm-at-serial-port.c:392] debug_log(): (ttyUSB0): --> 'AT^CURC=0<CR>' ModemManager[14266]: <debug> [1366921567.304022] [mm-at-serial-port.c:392] debug_log(): (ttyUSB0): --> 'AT^CURC=0<CR>' ModemManager[14266]: <debug> [1366921571.304346] [mm-port-probe.c:146] mm_port_probe_set_result_at(): (tty/ttyUSB0) port is not AT-capable ModemManager[14266]: <debug> [1366921571.304491] [mm-port-probe.c:502] serial_probe_qcdm(): (tty/ttyUSB0) probing QCDM... ModemManager[14266]: <debug> [1366921571.304524] [mm-serial-port.c:966] mm_serial_port_close(): (ttyUSB0) device open count is 0 (close) ModemManager[14266]: <info> [1366921571.304554] [mm-serial-port.c:982] mm_serial_port_close(): (ttyUSB0) closing serial port... ModemManager[14266]: <info> [1366921571.304621] [mm-serial-port.c:1014] mm_serial_port_close(): (ttyUSB0) serial port closed ModemManager[14266]: <info> [1366921571.304667] [mm-serial-port.c:1083] mm_serial_port_close_force(): (ttyUSB0) forced to close port ModemManager[14266]: <info> [1366921571.304787] [mm-serial-port.c:857] mm_serial_port_open(): (ttyUSB0) opening serial port... ModemManager[14266]: <debug> [1366921571.305358] [mm-serial-port.c:926] mm_serial_port_open(): (ttyUSB0) device open count is 1 (open) ModemManager[14266]: <debug> [1366921571.305438] [mm-qcdm-serial-port.c:202] debug_log(): (ttyUSB0): --> 7e 00 78 f0 7e ModemManager[14266]: <debug> [1366921574.303587] [mm-qcdm-serial-port.c:202] debug_log(): (ttyUSB0): --> 7e 00 78 f0 7e ModemManager[14266]: <debug> [1366921577.304268] [mm-port-probe.c:240] mm_port_probe_set_result_qcdm(): (tty/ttyUSB0) port is not QCDM-capable ModemManager[14266]: <debug> [1366921577.304480] [mm-serial-port.c:966] mm_serial_port_close(): (ttyUSB0) device open count is 0 (close) ModemManager[14266]: <info> [1366921577.304538] [mm-serial-port.c:982] mm_serial_port_close(): (ttyUSB0) closing serial port... ModemManager[14266]: <info> [1366921577.304624] [mm-serial-port.c:1014] mm_serial_port_close(): (ttyUSB0) serial port closed ModemManager[14266]: <info> [1366921577.304676] [mm-serial-port.c:1083] mm_serial_port_close_force(): (ttyUSB0) forced to close port ModemManager[14266]: <debug> [1366921577.304772] [mm-plugin-manager.c:323] plugin_supports_port_ready(): (Plugin Manager) (Huawei) [ttyUSB0] found best plugin for port ModemManager[14266]: <debug> [1366921577.304827] [mm-plugin-manager.c:186] port_probe_context_finished(): (Plugin Manager) (Huawei) [ttyUSB0]: found best plugin for device (/sys/devices/pci0000:00/0000:00:1d.7/usb3/3-2) ModemManager[14266]: <debug> [1366921577.304901] [mm-plugin-manager.c:257] suggest_port_probe_result(): (Plugin Manager) (Huawei) [wwp0s29f7u2i1] deferred task completed, got suggested plugin ModemManager[14266]: <debug> [1366921577.305000] [mm-plugin.c:665] mm_plugin_supports_port(): (Huawei) [wwp0s29f7u2i1] probing deferred until result suggested ModemManager[14266]: <debug> [1366921577.305062] [mm-plugin-manager.c:390] plugin_supports_port_ready(): (Plugin Manager) (Huawei) [wwp0s29f7u2i1] task completed, got suggested plugin ModemManager[14266]: <info> [1366921577.305116] [mm-device.c:467] mm_device_create_modem(): Creating modem with plugin 'Huawei' and '2' ports ModemManager[14266]: <debug> [1366921577.311428] [huawei/mm-plugin-huawei.c:472] grab_port(): (net/wwp0s29f7u2i1) Port will have AT flags 'none' ModemManager[14266]: <debug> [1366921577.311564] [mm-base-modem.c:263] mm_base_modem_grab_port(): (wwp0s29f7u2i1) type 'net' claimed by /sys/devices/pci0000:00/0000:00:1d.7/usb3/3-2 ModemManager[14266]: <debug> [1366921577.311613] [huawei/mm-plugin-huawei.c:472] grab_port(): (tty/ttyUSB0) Port will have AT flags 'none' ModemManager[14266]: <warn> [1366921577.311700] [mm-plugin.c:818] mm_plugin_create_modem(): Could not grab port (tty/ttyUSB0): 'Cannot add port 'tty/ttyUSB0', unhandled serial type' ModemManager[14266]: <debug> [1366921577.311800] [mm-base-modem.c:1252] finalize(): Modem (Huawei) '/sys/devices/pci0000:00/0000:00:1d.7/usb3/3-2' completely disposed ModemManager[14266]: <warn> [1366921577.311851] [mm-manager.c:145] find_device_support_ready(): Couldn't create modem for device at '/sys/devices/pci0000:00/0000:00:1d.7/usb3/3-2': Failed to find primary AT port
Random thought, maybe the device's firmware doesn't like send_delay for the serial port, and wants the whole command in one USB transaction? Should we set send_delay to zero when probing Huawei devices if they are tagged as supporting NDISDUP?
Verified with the user that "AT^CURC=0" in minicom returns "OK", unlike in MM where it simply doesn't respond.
We can try the send_delay=0 and see if that helps? Configuring the send_delay=0 in the Huawei plugin should work, because it will always be the first plugin tried when probing the tty port (thanks to the re-ordering done based on the pre-probing filters, as Huawei has the vendor ID filter), no other plugin should try it before. If there was another plugin trying it before, configuring the send_delay in the Huawei plugin would be useless.
Device's SETPORT is configured like so: 12,16,A1,A2 which means (12) 4G PCUI, (16) NCM, (A1) CDROM, (A2) SD. The Huawei software got installed on the system which may have screwed up the device configuration.
So we got the user to change the device mode with ^SETPORT and it now shows up more usefully with a few serial ports and the NCM port. So I believe the issues with talking to the device on the AT port are solved. But we still want to know why the device's NCM port isn't handled by the udev rules Huawei sent.
Some additional issues reported about the 3276: 1) it doesn't appear to support the additional authentication (PAP, CHAP, etc) parameter to NDISDUP 2) it *does* change the given PDP context, eg NDISDUP=<cid>,1,<apn> will also set the PDP context defined by <cid> to whatever <apn> is, as reported by CGDCONT?. Other modems like the UMG1831 don't change the PDP context. 3) the number of supported NDISDUP contexts as reported by NDISDUP=? is (1-20) but the number of supported PDP contexts is (0-31), so they disagree and if the modem had 20 contexts defined, we apparently couldn't use anything over 20. But I've asked the reporter to check and see if that's true. I think we should probably try to send the right CID to ndisdup instead of always sending '1', since that parameter is apparently a CID on some modems, and I don't think the other modems actually care what that number is.
Ok, so Huawei says NDISDUP is not supported on these devices only because they don't test them in their labs with Linux and NDISDUP. But we know it's supported for these devices, since that's what Windows uses, and we should try to provide the best experience here. So I believe we should support devices that we know work with NDISDUP, and that includes the 3276 when SETPORT results are compatible. Graham Inggs on the NM mailing list has posted detailed logs for the 3276, which in conjunction with these, we can use to add the right udev rules. I believe that for now we should probably whitelist devices, until we find enough of them to ensure that they all work correctly with NDISDUP.
Moving bugreport to the new ModemManager bugzilla in fd.o; summarized the issue there as well. Please subscribe to the new bugreport to get new updates. https://bugs.freedesktop.org/show_bug.cgi?id=85068 Closing this report as NOTGNOME.