USB modprobe problems in 21.02.0-rc3

For technical details, please refer to the ticket kmod-usb-net-huawei-cdc-ncm: USB modprobe support for Huawei E5576-320 CDC.

In that ticket, compliment says

Looks usb-modeswitch is completely gone for most architectures.

I was able to set my Huawei E5576-320 to the "Android" mode and it remained there. Setting it to the cdc-ether mode got the hotplug/modeswitch mechanism in a loop. The device works on Ubuntu 20.10 without any changes to the OS or the device.

So if anybody using a USB device that requires a mode switch to work could check if the mode switch continues to work in 21.02.0-rc3 or newer, that would probably useful for the RC series.

Talking as a long time user OpenWRT, starting in 2005, without any involvement in the development yet.

Thank you!

are you asking about an actual device detection regression or availability of a package?

i'm not clear on what the question is...

1 Like

I asking for people with similar hardware who are willing to check if that work with RC3 or whatever is current when they check.

There is already a ticket for the problem. It started out a a device regression but now seems to have a larger scope. See my initial post.

seems like this particular device is triggering a 'modeswitch loop' through hotplug...

fwiw... my build runs modeswitch on by default... and there have been zero reports of issues

I analyzed this a little deeper but got stuck because I have no idea how hotplug works.

The loop is probably not triggered by every device. That's why I asked for experiences. Can you please tell me which device you use and the USB vendor/type numbers? Thanks!

none... (occasional usb tethering / usb nics) but i'm aware of (community)build users using fancy usb modems and whatnot... probably at least 6 different types by now with no issues (major reported)...

i'd actually take that a bit further and say 'seems only to be triggered by that device'

No change in RC4.

1 Like

@bmork, I got my USB 3.0 hub today and had a look at the behavior when the E5576-320 was connected through the hub. Alas, no change.

I though that maybe loading the device's battery interfered because of a high loading current, so I gave it time to fully load the battery. This lowered the currents significantly, to abround 100 mA when the device is fluttering, and around 50 mA in storage mode. Which nicely explains the little difference in currents when the device is loading.

So we made no progress, except that I now have a nice USB 3.0 hub with a 5V 3A power supply, which can provide fours ports with full 3.0 currect and load something in addition.

I'll take some time tomorrow to try to understand what's happening, and what could cause this behaviour. Mainly I'll have a look at the behavior on the access point side of the device. Is the WLAN also fluttering?

@bmork, any wisdom from your side?

PS: Anybody confused because this seems to start in the middle of a conversation - it is. Look at 4G LTE Router Recommendation with good Wireguard Performance? starting with @bmorks reply to my post.

Too bad it didn't help, but still worth checking out.

Do you see any drivers being loaded and bound to the modem, except for usb-storage? There is obviously something we do to the device which makes it crash(?) and revert to storage mode. But that means that we have to send some USB request to it, and this won't happen without drivers except for pulling the device and config descriptors.

I didn't return to this for a while to gain a little distance. I haven't tried the released 21.02, but I doubt this will help. The kernel drivers don't seem to get involved, judging from the kernel messages, and the m,odprobe stuff sits in its own package.

I checked for a firmware update for the E5576, but there is none.

So I'm giving up now. It didn't want to do use WLAN to connect to the E5576, but that seems to be the only solution. So I've prepared the OpenWRT wireless configuration to connect to the E5576.

Lesson learned: let others figure out if a given hardware works with OpenWRT :wink:

Please leave this ticket open as the problem is unresolved and the cause is unknown.

As I just wrote in the Github ticket, it was just an error 40, or PEBKAC. Once I installed the right kmod-usb-net driver, it worked.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.