usb-modeswitch: support for Huawei E5576-320 CDC

[LupeChristoph]

Apologies, I am unable to find out where the kernel module package kmod-usb-net-huawei-cdc-ncm is maintained, so I'm guessing. Thusly, I cannot locate the Makefile.

Maintainer:DUNNO @\ (find it by checking history of the package Makefile) Environment: ath79/nand, Netgear WNDR4300, r16122-c2139eef27

Description: I purchased a Huawei E5576-320 to use as a mobile modem. It works out of the box with Ubuntu 20.10. When I plug it into a WNDR4300 running 21.02.0-rc2 with kmod-usb-net-huawei-cdc-ncm and all its requirements installed, the kernel only says:

[Thu Jun 17 17:29:54 2021] usb 1-1: USB disconnect, device number 2
[Thu Jun 17 17:30:12 2021] usb 1-1: new high-speed USB device number 3 using ehci-platform
[Thu Jun 17 17:30:13 2021] usb 1-1: USB disconnect, device number 3
[Thu Jun 17 17:30:13 2021] usb 1-1: new high-speed USB device number 4 using ehci-platform
[Thu Jun 17 17:30:16 2021] usb 1-1: USB disconnect, device number 4
[Thu Jun 17 17:30:16 2021] usb 1-1: new high-speed USB device number 5 using ehci-platform
[Thu Jun 17 17:30:17 2021] usb 1-1: USB disconnect, device number 5
[Thu Jun 17 17:30:17 2021] usb 1-1: new high-speed USB device number 6 using ehci-platform
[Thu Jun 17 17:30:19 2021] usb 1-1: USB disconnect, device number 6
... etc ad nauseam

I ran a tight loop monitoring the USB devices with this:

while true; do lsusb | grep 12d1; sleep 0.2; done

(That's coreutils' sleep.) That gave me:

Bus 001 Device 002: ID 12d1:1c20 HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 002: ID 12d1:1c20 HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 003: ID 12d1:1f01 HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 003: ID 12d1:1f01 HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 003: ID 12d1:1f01 HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 004: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Bus 001 Device 005: ID 12d1:1f01 HUAWEI_MOBILE HUAWEI_MOBILE
... etc

12d1:1c20 is the E5576-320 powered down (not really...). 12d1:14db is the CDC mode. 12d1:1f01 AFAIK is mass storage mode.

So it looks like there is a loop in the modeswitch. I understand the modeswitch logic too little to experiment with changes to /etc/usb-mode.json.

Here is an article about the E5576-320 modesitch. But i don't know how to translate a usb_modeswitch file from, say, Ubuntu to an OpenWRT modeswitch entry.

[LupeChristoph]

I just installed rc3 and retried. I accidentally omitted installing usb-modeswitch. Without that, I get an optiocal USB storage drive with an ISO image that contains Windows files, probably to do a mode switch on older Windows versions.

When I install usb-modeswitch, the RC2 behavior is back.

I had a look /etc/usb-mode.json and found an entry for 12d1:1f01 that makes sense. The t_product array contains 5339, which is 14db hex. Maybe the "HuaweiNew" mode has a problem and falls back to 1f01?

[LupeChristoph]

Ok, with quite some use of Google and fiddling I got a /etc/usb-mode.json that gets me a cdc_ncm device. This is also mentioned in the article I linked above. It is a mode used for Android.

[Fri Jun 18 17:06:30 2021] cdc_ncm 1-1:1.1: MAC-Address: 00:1e:10:1f:00:00
[Fri Jun 18 17:06:30 2021] cdc_ncm 1-1:1.1: setting rx_max = 16384
[Fri Jun 18 17:06:31 2021] cdc_ncm 1-1:1.1 wwan0: register 'cdc_ncm' at usb-1b000000.usb-1, Mobile Broadband Network Device, 00:1e:10:1f:00:00

But this proves that the modswitch should be able to switch to the cdc_ether device 14db.

I would still appreciate any support for this.

Here is the single-entry /etc/usb-mode.json I used:

        "messages" : [
                "55534243123456780000000000000011063000000100010000000000000000"
        ],

        "devices" : {
                "12d1:1f01": {
                        "*": {
                                "t_vendor": 4817,
                                "t_product": [ 5339, 5340 ],
                                "msg": [ 0 ]
                        }
                },
        }
}```

[compliment]

Looks usb-modeswitch is completely gone for most architectures. @LupeChristoph /etc/usb-mode.json is read by usb-modeswitch itself?

[LupeChristoph]

@compliment, I understand that process to work like this: When a new USB device is attached (probably also when a USB device is detached), the hotplug mechanism invokes /etc/hotplug.d/usb/20-usb_mode. This calls /etc/init.d/usbmode start:

# Copyright (C) 2013 OpenWrt.org

START=20
USE_PROCD=1

start_service()
{
        procd_open_instance
        procd_set_param command "/sbin/usbmode" -s
        procd_close_instance
}

usbmode -s modeswitches matching devices, using the default configuration file /etc/usb-mode.json.

I've tried the switching message for 12d1:14db mentioned in the article I linked, but I'm back to USB disconnects and alternating between 12d1:1f01 and 12d1:14db.

Since I'm out of time for today, this will be that last for today: The kernel is continuously calling /sbin/hotplug-call usb. I just caught a full ps --forest for that:

root      5842     1  0 18:12 ?        00:00:00 /bin/sh /etc/rc.common /etc/init.d/usbmode running
root      5877  5842  0 18:12 ?        00:00:00  \_ /bin/sh /etc/rc.common /etc/init.d/usbmode running
root      5878  5877  0 18:12 ?        00:00:00      \_ /bin/sh /etc/rc.common /etc/init.d/usbmode running
root      5843     1  0 18:12 ?        00:00:00 /bin/sh /sbin/hotplug-call usb
root      5848  5843  0 18:12 ?        00:00:00  \_ /bin/sh /sbin/hotplug-call usb
root      5850  5848  0 18:12 ?        00:00:00      \_ /bin/sh /etc/rc.common /etc/init.d/usbmode start

I don't understand what the "running" scripts do, I'll have a look tomorrow.

[LupeChristoph]

Sorry for taking so long. I instrumented /etc/init.d/usbmode to log when it is called with which command, and the result is quite surprising. Not only is it called several times per second thusly:

Wed Jun 23 14:11:36 CEST 2021 /etc/init.d/usbmode start
Wed Jun 23 14:11:37 CEST 2021 /etc/init.d/usbmode running
Wed Jun 23 14:11:37 CEST 2021 /etc/init.d/usbmode start
Wed Jun 23 14:11:37 CEST 2021 /etc/init.d/usbmode running
Wed Jun 23 14:11:37 CEST 2021 /etc/init.d/usbmode start
Wed Jun 23 14:11:37 CEST 2021 /etc/init.d/usbmode running
Wed Jun 23 14:11:37 CEST 2021 /etc/init.d/usbmode start
Wed Jun 23 14:11:38 CEST 2021 /etc/init.d/usbmode running

That loop continues for quite some time after I unplugged the device. Something smells very strange here.

I think somebody who understands hotplug has to have a look at that. I refuse to dig into kernel space. But I'll try to understand why the modeswitch mechanism reverts to 12d1:1f01 which my actually cause the look by starting more events than can be handled, building a backlog that takes a while to be cleared after the event stop being generated (I'm speculating, of course).

[mmokrejs]

https://openwrt.org/docs/guide-user/network/wan/wwan/3gdongle may be of help.

I think usb_modeswitch https://www.draisberghof.de/usb_modeswitch/ https://www.draisberghof.de/usb_modeswitch/device_reference.txt was replaced by usb-modeswitch https://openwrt.org/docs/guide-user/network/wan/wwan/usb-modeswitching.

You can also send manually eject /dev/sr0 to the fake CDROM drive to switch to USB modem dongle to real modem mode.

There used to be a page page describing additional tweaks to get 3G/4G connection restored if your operator drops it every few days, see https://github.com/oilervoss/openvpnForNordvpn/tree/master/etc/init.d . I hit this problem with 19.07 it is probably still not fixed in default 21.02-rc3 config.

[LupeChristoph]

Thanks for the links, they let me understand a bit more about the package.

The usb-modeswitch package still relies on the data files at Draisberghof, see the Makefile:

PKG_DATA_URL:=http://www.draisberghof.de/usb_modeswitch
PKG_DATA_PATH:=usb-modeswitch-data-$(PKG_DATA_VERSION)
PKG_DATA_FILENAME:=$(PKG_DATA_PATH).tar.bz2```

> You can also send manually eject /dev/sr0 to the fake CDROM drive to switch to USB modem dongle to real modem mode.

This does not work with the E5576-320, it stays in CD-ROM mode. It does eject the ISO image, though. You have to press the button to make the device switch. Fun - pressing the button again gets you the CD-ROM mode back, with the ISO still ejected :-) Even plugging it off dows not get you the ISO image back. Probably needs a factory reset.

The device does not get far enough to create a network device, so the 3G/$G fix does not apply. And since the usb-modeswitch package has not changed since 18.06.0, it does not seem to be involved with that (ex-)problem.

[LupeChristoph]

It hurts! It hurts! To be Stoopid(tm).

Neither of us had the idea to just install all the kmod-usb-net packages. I just did that, and Presto!

Tue Sep 21 13:42:02 2021 kern.info kernel: [  472.469602] usb 1-1: new high-speed USB device number 2 using ehci-platform
Tue Sep 21 13:42:03 2021 kern.info kernel: [  472.633416] usb-storage 1-1:1.0: USB Mass Storage device detected
Tue Sep 21 13:42:03 2021 kern.info kernel: [  472.653721] scsi host0: usb-storage 1-1:1.0
Tue Sep 21 13:42:04 2021 kern.notice kernel: [  473.686998] scsi 0:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Tue Sep 21 13:43:14 2021 kern.info kernel: [  543.680662] usb 1-1: USB disconnect, device number 2
Tue Sep 21 13:43:31 2021 kern.info kernel: [  561.153312] usb 1-1: new high-speed USB device number 3 using ehci-platform
Tue Sep 21 13:43:31 2021 kern.info kernel: [  561.317465] usb-storage 1-1:1.0: USB Mass Storage device detected
Tue Sep 21 13:43:31 2021 kern.info kernel: [  561.337426] scsi host0: usb-storage 1-1:1.0
Tue Sep 21 13:43:32 2021 kern.info kernel: [  561.783418] usb 1-1: USB disconnect, device number 3
Tue Sep 21 13:43:32 2021 kern.info kernel: [  562.353384] usb 1-1: new high-speed USB device number 4 using ehci-platform
Tue Sep 21 13:43:33 2021 kern.info kernel: [  562.602772] cdc_ether 1-1:1.0 usb0: register 'cdc_ether' at usb-1b000000.usb-1, CDC Ethernet Device, 62:8c:97:ae:da:83

A little playing with Luci, and I have this:

9: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 62:8c:97:ae:da:83 brd ff:ff:ff:ff:ff:ff
    inet 192.168.243.132/24 brd 192.168.243.255 scope global usb0
       valid_lft forever preferred_lft forever
    inet6 fe80::608c:97ff:feae:da83/64 scope link 
       valid_lft forever preferred_lft forever

I removed all but kmod-usb-net-cdc-ether and kmod-usb-net and rebooted. The interface ius still configured, the default route is set, name resolution works. I can reach remote hosts.

Thanks for you patience, @mmokrejs. Next time, don't believe somebody can't be that stupid. :-(