[yegorich]

OS: Buildroot
Kernels tested: 4.2 - 4.5
Modems: Huawei MU609 and ME909u-521 (both have the same ID 12d1:1573)

Upon finding modem I get following messages (for MU609):

# usb 1-1.3: new high-speed USB device number 3 using musb-hdrc
cdc_ether 1-1.3:2.0 eth2: register 'cdc_ether' at usb-musb-hdrc.0.auto-1.3, CDC Ethernet Device, 00:a0:c6:75:25:90
option 1-1.3:2.2: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
option 1-1.3:2.3: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1
option 1-1.3:2.4: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
option 1-1.3:2.5: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB3
option 1-1.3:2.6: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4
cdc_ether 1-1.3:2.0 eth2: unregister 'cdc_ether' usb-musb-hdrc.0.auto-1.3, CDC Ethernet Device
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #1
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #1
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #1
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #1
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #1

For ME909:

# usb 1-1.3: new high-speed USB device number 3 using musb-hdrc
cdc_ether 1-1.3:2.0 usb0: register 'cdc_ether' at usb-musb-hdrc.0.auto-1.3, CDC Ethernet Device, 02:1e:10:1f:00:00
option 1-1.3:2.2: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
option 1-1.3:2.3: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1
option 1-1.3:2.4: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
option 1-1.3:2.5: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB3
cdc_ether 1-1.3:2.0 usb0: unregister 'cdc_ether' usb-musb-hdrc.0.auto-1.3, CDC Ethernet Device
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #3
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #3
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #3
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #3
usb 1-1.3: usbfs: interface 2 claimed by option while 'usb_modeswitch' sets config #3

As a result - no ethx or usbx interface for the card as cdc_ether was unregistered.

Both cards share the same VID/PID and working without the need of usb_modeswitch. But usb_modeswitch_data_20151101 introduced support for Huawei ME909u-521 [12d1:1573]. What was the need for this change and how can we fix this breakage? Let me know, what info should provide to clarify this issue.

Thanks.

yegorich

[LOM]

Modems: Huawei MU609 and ME909u-521 (both have the same ID 12d1:1573)

They seem to have a different interface layout though and also different number of configs.

What was the need for this change and how can we fix this breakage?

The reason for it was to switch the config into mbim which is the preferred protocol under linux, mbim is in config #2 in one of your cards and in config#3 in the other.
We do also need a default config in case there are no mbim support in the os, config #1 is the config which is not mbim in your 2-config card.
I don't consider any of this to be a breakage, you can easily disable usb_modeswitch if you don't want any switching to take place.
The whole mess is created by Huawei re-using the vid:pid for a completely different card after having already used it for another one.

[yegorich]

I've this post http://www.draisberghof.de/usb_modeswit ... f=4&t=2458 and now the things become more clear to me. The user in that post has Me909 with 3 configurations, my card shows only 2. I can successfully switch them via sysfs: 1 - qmi, 2- cdc_ether. The kernel seems to switch it to 2. USB_NET_CDC_MBIM is compiled into the kernel and libmbim is also provided in rootfs. I'm attaching the output for ME909 card.

Does usb_modeswitch just try to switch the mode via sysfs or does it also try to load/unload drivers etc. in this case?

[yegorich]

Looking at usb_modeswitch log I found, that it more or less "requires" driver being compiled as modules. With recompiled kernel I can at least see, that log ended with success. Now I have another problem:

Code: Select all

usb 1-1.3: new high-speed USB device number 3 using musb-hdrc
cdc_ether 1-1.3:2.0 eth2: register 'cdc_ether' at usb-musb-hdrc.0.auto-1.3, CDC Ethernet Device, 00:a0:c6:75:25:90
cdc_ether 1-1.3:2.0 eth2: unregister 'cdc_ether' usb-musb-hdrc.0.auto-1.3, CDC Ethernet Device
usbcore: registered new interface driver option
usbserial: USB Serial support registered for GSM modem (1-port)
option 1-1.3:1.0: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
option 1-1.3:1.1: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1
option 1-1.3:1.2: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
option 1-1.3:1.3: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB3
option 1-1.3:1.4: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4
option 1-1.3:1.5: GSM modem (1-port) converter detected
usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5
usbcore: registered new interface driver qmi_wwan
udevd[994]: 'usb_modeswitch --symlink-name /devices/platform/ocp/47400000.usb/47401400.usb/musb-hdrc.0.auto/usb1/1-1/1-1.3/1-1.3:1.4/ttyUSB4/tty/ttyUSB4 12d1 1573 ' [1001] terminated by signal 11 (Segmentation fault)
udevd[998]: 'usb_modeswitch --symlink-name /devices/platform/ocp/47400000.usb/47401400.usb/musb-hdrc.0.auto/usb1/1-1/1-1.3/1-1.3:1.1/ttyUSB1/tty/ttyUSB1 12d1 1573 ' [1003] terminated by signal 11 (Segmentation fault)
udevd[980]: 'usb_modeswitch --symlink-name /devices/platform/ocp/47400000.usb/47401400.usb/musb-hdrc.0.auto/usb1/1-1/1-1.3/1-1.3:1.2/ttyUSB2/tty/ttyUSB2 12d1 1573 ' [1005] terminated by signal 11 (Segmentation fault)
udevd[979]: 'usb_modeswitch --symlink-name /devices/platform/ocp/47400000.usb/47401400.usb/musb-hdrc.0.auto/usb1/1-1/1-1.3/1-1.3:1.3/ttyUSB3/tty/ttyUSB3 12d1 1573 ' [1002] terminated by signal 11 (Segmentation fault)
udevd[995]: 'usb_modeswitch --symlink-name /devices/platform/ocp/47400000.usb/47401400.usb/musb-hdrc.0.auto/usb1/1-1/1-1.3/1-1.3:1.5/ttyUSB5/tty/ttyUSB5 12d1 1573 ' [1016] terminated by signal 6 (Aborted)
udevd[998]: 'usb_modeswitch --symlink-name /devices/platform/ocp/47400000.usb/47401400.usb/musb-hdrc.0.auto/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0/tty/ttyUSB0 12d1 1573 ' [1057] terminated by signal 6 (Aborted)

I have usb_modeswitch 2.3.0

Code: Select all

# usb_modeswitch -e

 * usb_modeswitch: handle USB devices with multiple modes
 * Version 2.3.0 (C) Josua Dietze 2015
 * Based on libusb1/libusbx

 ! PLEASE REPORT NEW CONFIGURATIONS !

I've looked at the source code and I couldn't find --symlink-name parameter. Any idea, what is wrong?

[LOM]

Your lsusb listing is for a 3 configs device, ppp dialup modem + qmi in config #1, ppp dialup modem + cdc_ether network device in config #2, and cdc_mbim in config #3
.
You have forgotten to build the wrapper (usb_modeswitch.tcl) which among other things handles the selection of the mbim config for devices with mbim interfaces if the kernel has mbim drivers.
The missing wrapper is also the reason for your --symlink-name segfaults.

[yegorich]

You're right my ME909 has 3 configurations. Have mixed it with MU609. I could disable MBIM activation via /etc/usb_modeswitch.conf (DisableMBIMGlobal=1).

After enabling TCL for Buildroot I don't experience Segmentation faults any more. Now I can look further into it.

Btw. are you going to create a GitHub based mirror of your internal repo? It would make patch creation and changes history check very easy.