[simonc]

Hello,

I have a Huawei E5331 which is a Wi-Fi dongle with a USB port as well. The device works ok in Wi-fi mode, but I want to use it with some Linux systems in USB mode as well.

Using the current versions of USB_ModeSwitch and the data package, I can mode switch this device just fine, but it always mode switches into a Ethernet over USB mode with id 12d1:1c1f.

However if you look here, http://ubuntuforums.org/showthread.php?t=2098728 you will see this poster starts out with this device mode switching into 12d1:1506 and the dmesg output shows it as a GSM modem in that mode.

Given the other issues in that thread with Ethernet over USB (which I have also experienced with my non-Ubuntu based distribution) I would like to run the device in GSM modem mode using option or usbserial.

Does anyone here know how to switch the device into 12d1:1506 mode instead of 12d1:1c1f ? I have tried the other switching variants in the data package for 12d1:* without success; the switch is either not performed or the device is switched into Ethernet over USB mode.

BTW, when in Ethernet over USB mode, a serial port shows up which can be attached to with usbserial, but when you connect to it, you are presented with RSSI and data transfer statistics status lines; trying to dial with *99# anyway does not result in a PPP connection.

Thanks for any ideas.

PS: Even if you don't know the answer to my question, it would also be useful to know if this device actually _does_ have a GSM modem mode. Given the above poster's inability to make those ports work in 12d1:1506 mode they could, for example, just be diagnostic or firmware upload ports.

[LOM]

Test if it gives you a different target id when when using
MessageContent="55534243123456780000000000000011060000000000000000000000000000"

What is the default id before switching?

[simonc]

Thanks for the suggestion but it still mode switches to 12d1:1c1f.

The default ID after power up is 12d1

Code: Select all

Bus 001 Device 002: ID 12d1:14fe Huawei Technologies Co., Ltd. 

I am using usb-modeswitch-data-20121109/usb_modeswitch.d/12d1:14fe as the template:

Code: Select all

# T-Mobile NL (Huawei E352)

TargetVendor=  0x12d1
TargetProduct= 0x1506

MessageContent="55534243123456780000000000000011062000000100000000000000000000"

The command used was:

Code: Select all

/usr/sbin/usb_modeswitch -c 12d1\:14fe -W --default-vendor 12d1 --default-product 14fe

This results in:

Code: Select all

Bus 001 Device 007: ID 12d1:1c1f Huawei Technologies Co., Ltd. 

Modifying the template to use your new message content command:

Code: Select all

# T-Mobile NL (Huawei E352)

TargetVendor=  0x12d1
TargetProduct= 0x1506

#MessageContent="55534243123456780000000000000011062000000100000000000000000000"
MessageContent="55534243123456780000000000000011060000000000000000000000000000"

gives:

Code: Select all

Bus 001 Device 009: ID 12d1:1c1f Huawei Technologies Co., Ltd. 

Here is the last part of the output from usb_modeswitch:

Code: Select all

Looking for default devices ...
  searching devices, found USB ID 12d1:14fe
   found matching vendor ID
   found matching product ID
   adding device
  searching devices, found USB ID 0000:0000
  searching devices, found USB ID 0000:0000
  searching devices, found USB ID 0000:0000
  searching devices, found USB ID 0000:0000
  searching devices, found USB ID 0000:0000
 Found device in default mode, class or configuration (1)
Accessing device 008 on bus 001 ...
Getting the current device configuration ...
 OK, got current device configuration (1)
Using interface number 0
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...
Looking for active driver ...
 OK, driver found ("usb-storage")
 OK, driver "usb-storage" detached

SCSI inquiry data (for identification)
-------------------------
  Vendor String: HUAWEI  
   Model String: Mass Storage    
Revision String: 2.31
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: HUAWEI
     Product: HUAWEI Mobile
  Serial No.: not provided
-------------------------
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
 OK, message successfully sent
Resetting response endpoint 0x81
USB error: could not clear/halt ep 129: Protocol error
 Could not reset endpoint (probably harmless): -71
Resetting message endpoint 0x01
USB error: could not clear/halt ep 1: Protocol error
 Could not reset endpoint (probably harmless): -71
-> Run lsusb to note any changes. Bye.

[LOM]

The message I gave you works with some Huawei sticks of net type but not with all of them, seems yours is one of those non-working.

The drivers you need for getting the device to work in linux are usbnet, cdc_ncm, and cdc_wdm where the first 2 will create a /dev/wwan device for ethernet data and the last one will create a /dev/wdm device for management.

Huawei's own linux driver will most likely work with this device, it comes with source and prebuilt binaries for Debian, Fedora, Mandriva, Mint, and OpenSUSE.

[simonc]

Thanks for the feedback.

I tend to run Linux distributions which are built around stability rather than leading edge features and this unit (in the Ethernet over USB mode) will not complete the configuration process on those distributions as the kernel level support for this specific device does not exist, so I guess the next thing to look at are indeed the Huawei Linux drivers.

[bmork]

Thanks for the feedback.

I tend to run Linux distributions which are built around stability rather than leading edge features and this unit (in the Ethernet over USB mode) will not complete the configuration process on those distributions as the kernel level support for this specific device does not exist,

I don't think that is a problem. Patches which only add new device IDs or minor probing adjustments to support new devices are usually backported to stable kernels and will most likely end up in the stable distro kernels in a few weeks time.

But looking at this particular device it seems I missed this device ID when adding Huawei vendor specific ACM devices recently. I guess we need to add an exception for 12d1:1c1f as well. Could you confirm that doing

Code: Select all

modprobe option
echo 12d1 1c1f  >/sys/bus/usb-serial/drivers/option1/new_id

results in one working serial port? (it may cause more than one ttyUSBx serial port to appear, but only one of them will work).

so I guess the next thing to look at are indeed the Huawei Linux drivers.

You may of course do so, but IMHO that is quite a lot more experimental than running a recent mainline kernel...


Bjørn

[LOM]

%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C1F&MI_00 pcui

%NCMDeviceDesc% = ew_jucdcncm.ndi, USBCDCNCM\VID_12D1&PID_1C1F&MI_02 cdc_ncm

%BTDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C1F&MI_04 bluetooth

Code: Select all

Bus 002 Device 008: ID 12d1:1c1f Huawei Technologies Co., Ltd. 
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          0x1c1f 
  bcdDevice            1.02
  iManufacturer           2 HUAWEI
  iProduct                1 HUAWEI Mobile
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          149
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol    255 Vendor Specific (MSFT RNDIS?)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC ACM:
        bmCapabilities       0x00
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          0
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         0 
      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           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      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               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 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        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass     13 
      bInterfaceProtocol      0 
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      UNRECOGNIZED CDC:  06 24 1a 00 01 1f
      CDC Ethernet:
        iMacAddress                      3 582C80139263
        bmEthernetStatistics    0x00000005
        wMaxSegmentSize               1514
        wNumberMCFilters            0x0003
        bNumberPowerFilters              1
      CDC Union:
        bMasterInterface        2
        bSlaveInterface         2 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 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        2
      bAlternateSetting       1
      bNumEndpoints           3
      bInterfaceClass         2 Communications
      bInterfaceSubClass     13 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 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     0x84  EP 4 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     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
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)

No ACM union, just the ACM driver being used for normal serial comm so the id needs option support for the 2/2/ff interface.

[simonc]

But looking at this particular device it seems I missed this device ID when adding Huawei vendor specific ACM devices recently. I guess we need to add an exception for 12d1:1c1f as well. Could you confirm that doing

Code: Select all

modprobe option
echo 12d1 1c1f  >/sys/bus/usb-serial/drivers/option1/new_id

results in one working serial port? (it may cause more than one ttyUSBx serial port to appear, but only one of them will work).

Yes, this works.

(To avoid any functionality problems with stable kernel versions, I used a system rescue live CD I had to hand which has a more recent kernel. The system rescue live CD is Gentoo based in case it makes a difference.)

You get two serial ports. ttyUSB0 is correctly bound to the first interface and ttyUSB1 is wrongly bound to the NCM interface. From the dmesg:

Code: Select all

[  318.856825] option 1-4:1.0: GSM modem (1-port) converter detected
[  318.858901] usb 1-4: GSM modem (1-port) converter now attached to ttyUSB0
[  318.859033] option 1-4:1.2: GSM modem (1-port) converter detected
[  318.862022] usb 1-4: GSM modem (1-port) converter now attached to ttyUSB1

Note that "works" means I get a serial port, as with my earlier experiments with usbserial directly. It does not mean I get something I can use with PPP. When I try to dial *99# anyway, the port locks up and I cannot even hangup the call to drop back to AT mode.

The serial port appears to be the PCUI port which appears to be confirmed by the device's response to the ^GETPORTMODE command:

Code: Select all

^GETPORTMODE: TYPE: WCDMA: huawei,PCUI:0,CDROM:1,NDIS:2

I also get regular DSFLOWRPT and RSSI messages on the port as you would expect for the PCUI port.

so I guess the next thing to look at are indeed the Huawei Linux drivers.

You may of course do so, but IMHO that is quite a lot more experimental than running a recent mainline kernel...


Bjørn

I am certainly not comfortable with the idea of using the drivers but the problem is that if you look at the Ubuntu discussion I linked to in my original posting, you will see the USB descriptors are encoded in such a way that they will not be processed correctly unless you are running the very latest versions of the Linux kernel.

BTW, before I try installing it on a live system, I have had a quick look at the driver kit over the last day or so (but in a live CD environment) to try and assess the quality of the drivers. I've only looked at HWActivator so far and I was not impressed by the fact it appears to be writing temporary files into /usr/local instead of into /tmp. Some example commands embedded in the binary:

Code: Select all

rm -f /usr/local/.find.log
/usr/bin/lshal >/usr/local/.hal.log

I also see HWActivator needs /dev/hwcdrom defining (unlike USB_Modeswitch ).

(Before anyone reminds me, yes, I know discussion of the driver kit is probably OT for this forum, so I will not comment on it any further. )

[simonc]

%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C1F&MI_00 pcui

%NCMDeviceDesc% = ew_jucdcncm.ndi, USBCDCNCM\VID_12D1&PID_1C1F&MI_02 cdc_ncm

%BTDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C1F&MI_04 bluetooth

I didn't realise there was a version of this device with Bluetooth support. If you look at the ^GETPORTMODE response I posted, you will see my version of this device does not support Bluetooth. I don't know if that makes a difference to anyone.

[bmork]

%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C1F&MI_00 pcui

%NCMDeviceDesc% = ew_jucdcncm.ndi, USBCDCNCM\VID_12D1&PID_1C1F&MI_02 cdc_ncm

%BTDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C1F&MI_04 bluetooth

Hmm, the lsusb output you posted did not include any interface number 4. Only available in some device variants, or something you need to enable somehow?

Anyway, based on the above I guess the bluetooth interface will appear as another serial port, possibly using the same 02/02/ff class codes? That may not work as expected. But we'll need some experimenting with a device having this interface to find out for sure.

Code: Select all

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass     13 
      bInterfaceProtocol      0 
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      UNRECOGNIZED CDC:  06 24 1a 00 01 1f
      CDC Ethernet:
        iMacAddress                      3 582C80139263
        bmEthernetStatistics    0x00000005
        wMaxSegmentSize               1514
        wNumberMCFilters            0x0003
        bNumberPowerFilters              1
      CDC Union:
        bMasterInterface        2
        bSlaveInterface         2 

Wow, Huawei are getting closer and closer to the spec

Still have the weird combined control+data interface, but the class codes are now standard CDC NCM. This should work fine with the current cdc_ncm driver, but the interface name will end up as usbX instead of wwanX. We can fix that if necessary. Probably is if you are going to use NetworkManager/ModemManager. I'll check that.

[bmork]

But looking at this particular device it seems I missed this device ID when adding Huawei vendor specific ACM devices recently. I guess we need to add an exception for 12d1:1c1f as well. Could you confirm that doing

Code: Select all

modprobe option
echo 12d1 1c1f  >/sys/bus/usb-serial/drivers/option1/new_id

results in one working serial port? (it may cause more than one ttyUSBx serial port to appear, but only one of them will work).

Yes, this works.

(To avoid any functionality problems with stable kernel versions, I used a system rescue live CD I had to hand which has a more recent kernel. The system rescue live CD is Gentoo based in case it makes a difference.)

You get two serial ports. ttyUSB0 is correctly bound to the first interface and ttyUSB1 is wrongly bound to the NCM interface. From the dmesg:

Code: Select all

[  318.856825] option 1-4:1.0: GSM modem (1-port) converter detected
[  318.858901] usb 1-4: GSM modem (1-port) converter now attached to ttyUSB0
[  318.859033] option 1-4:1.2: GSM modem (1-port) converter detected
[  318.862022] usb 1-4: GSM modem (1-port) converter now attached to ttyUSB1

Note that "works" means I get a serial port, as with my earlier experiments with usbserial directly. It does not mean I get something I can use with PPP. When I try to dial *99# anyway, the port locks up and I cannot even hangup the call to drop back to AT mode.

The serial port appears to be the PCUI port which appears to be confirmed by the device's response to the ^GETPORTMODE command:

Code: Select all

^GETPORTMODE: TYPE: WCDMA: huawei,PCUI:0,CDROM:1,NDIS:2

I also get regular DSFLOWRPT and RSSI messages on the port as you would expect for the PCUI port.

Thanks for checking, and thanks for all the details leaving no doubt.

Yes, this is as expected. These devices do not support PPP. The network interface is the only data capable port. The serial port is only for device management.

The CDC NCM port should already be supported by the latest stable 3.6+ kernels, but will appear as usbX instead of wwanX. So what we need to fully support this device is just an entry in the option driver making it support the 02/02/ff serial port. We should also add an entry in cdc_ncm telling it to make this a wwanX device, but that is not strictly required to make it work.

I am certainly not comfortable with the idea of using the drivers but the problem is that if you look at the Ubuntu discussion I linked to in my original posting, you will see the USB descriptors are encoded in such a way that they will not be processed correctly unless you are running the very latest versions of the Linux kernel.

Yes, you need commit bbc8d92 ("net: cdc_ncm: add Huawei devices") to make cdc_ncm accept a combined control+data interface. This is included in v3.7 and later and backported to the 3.6 stable kernels (from v3.6.11), but not any other stable kernels. I'll take a look at why it didn't go to the 3.2 and 3.0 stable series. Probably minor details only.

If you are running anything older then I guess you need to build your own out-of-tree driver. But do note that it often is almost as easy picking and building a mainline driver from a recent lernel on older kernels as building any other out-of-tree driver. Using the v3.8 cdc_ncm this way will be difficult because of usbnet API changes and other refactoring. The v3.7.9 version can however be made working some minor effort:

Code: Select all

bjorn@nemi:/usr/local/src/git/linux$ make -C /lib/modules/`uname -r`/build SUBDIRS=/usr/local/src/git/linux/drivers/net/usb cdc_ncm.ko
make: Entering directory `/usr/src/linux-headers-3.2.0-4-amd64'
  CC [M]  /usr/local/src/git/linux/drivers/net/usb/cdc_ncm.o
/usr/local/src/git/linux/drivers/net/usb/cdc_ncm.c:1281:2: error: unknown field ‘disable_hub_initiated_lpm’ specified in initializer
/usr/local/src/git/linux/drivers/net/usb/cdc_ncm.c:1284:1: warning: data definition has no type or storage class [enabled by default]
/usr/local/src/git/linux/drivers/net/usb/cdc_ncm.c:1284:1: warning: type defaults to ‘int’ in declaration of ‘module_usb_driver’ [-Wimplicit-int]
/usr/local/src/git/linux/drivers/net/usb/cdc_ncm.c:1284:1: warning: parameter names (without types) in function declaration [enabled by default]
/usr/local/src/git/linux/drivers/net/usb/cdc_ncm.c:1272:26: warning: ‘cdc_ncm_driver’ defined but not used [-Wunused-variable]
make[3]: *** [/usr/local/src/git/linux/drivers/net/usb/cdc_ncm.o] Error 1
make[2]: *** [cdc_ncm.ko] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-headers-3.2.0-4-amd64'

OK, that did not work because of two uninteresting USB driver API changes since v3.2 (adding adding a new field to struct usb_driver and a macro for the boilerplate module init/exit code). We can just ignore those changes, reverting the last few lines of the driver to the v3.2 code:

Code: Select all

bjorn@nemi:/usr/local/src/git/linux$ patch -p1 -l <<EOP
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 74fab1a..da5f58c 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1278,10 +1278,22 @@ static struct usb_driver cdc_ncm_driver = {
        .resume = usbnet_resume,
        .reset_resume = usbnet_resume,
        .supports_autosuspend = 1,
-       .disable_hub_initiated_lpm = 1,
 };
 
-module_usb_driver(cdc_ncm_driver);
+static int __init cdc_ncm_init(void)
+{
+       printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION "\n");
+       return usb_register(&cdc_ncm_driver);
+}
+
+module_init(cdc_ncm_init);
+
+static void __exit cdc_ncm_exit(void)
+{
+       usb_deregister(&cdc_ncm_driver);
+}
+
+module_exit(cdc_ncm_exit);
 
 MODULE_AUTHOR("Hans Petter Selasky");
 MODULE_DESCRIPTION("USB CDC NCM host driver");
EOP

Then it works:

Code: Select all

bjorn@nemi:/usr/local/src/git/linux$ make -C /lib/modules/`uname -r`/build SUBDIRS=/usr/local/src/git/linux/drivers/net/usb cdc_ncm.ko
make: Entering directory `/usr/src/linux-headers-3.2.0-4-amd64'
  CC [M]  /usr/local/src/git/linux/drivers/net/usb/cdc_ncm.o
  MODPOST 1 modules
  CC      /usr/local/src/git/linux/drivers/net/usb/cdc_ncm.mod.o
  LD [M]  /usr/local/src/git/linux/drivers/net/usb/cdc_ncm.ko
make: Leaving directory `/usr/src/linux-headers-3.2.0-4-amd64'

(where /usr/local/src/git/linux contains the full v3.7.9 source and I have the linux-headers-`uname -r` Debian package installed)

You now have a v3.7.9 cdc_ncm driver built for the Debian wheezy kernel. If you install the resulting cdc_ncm.ko in /lib/modules/`uname -r`/updates/, then it will be used instead of the distro provided version. There is no need to remove or replace the driver from the distro kernel package.

[simonc]

I am certainly not comfortable with the idea of using the drivers but the problem is that if you look at the Ubuntu discussion I linked to in my original posting, you will see the USB descriptors are encoded in such a way that they will not be processed correctly unless you are running the very latest versions of the Linux kernel.

Yes, you need commit bbc8d92 ("net: cdc_ncm: add Huawei devices") to make cdc_ncm accept a combined control+data interface. This is included in v3.7 and later and backported to the 3.6 stable kernels (from v3.6.11), but not any other stable kernels. I'll take a look at why it didn't go to the 3.2 and 3.0 stable series. Probably minor details only.

If you are running anything older then I guess you need to build your own out-of-tree driver. But do note that it often is almost as easy picking and building a mainline driver from a recent lernel on older kernels as building any other out-of-tree driver. Using the v3.8 cdc_ncm this way will be difficult because of usbnet API changes and other refactoring. The v3.7.9 version can however be made working some minor effort:

Thanks for the suggestions and in particular thanks for the commit id; that's very useful. I also noticed the followup patch as well.

I tend to run RHEL based clones and RH are very conservative with kernel versions; that's why I originally came at this from the GSM modem angle when I saw the Ubuntu forum posting showing the E5331 with a different mode ID from any which I've seen and which implied it may be a GSM modem mode.

BTW, looking once again at the thread which I pointed to in my original message, I see it was you who made the NCM comments there. To answer your question there: yes, this device has both a web server (for configuration/monitoring only) and a DHCP server built in and Huawei was clearly not thinking ahead as the device's default address is 192.168.1.1.