[eby]

I have a peculiar problem on Ubuntu 20.04LTS with Huawei E5220 3g hotspot device connected over usb, upon plugging-in it registers as wwan0 (have renamed with GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0" in grub) and i connect to internet using "dhclient -v wwan0".

The hotspot gets switched off randomly and after turning it on/re-plugging/etc... wwan0 (net) port is not registered till the computer is restarted.

I did not had this issue with Ubuntu 14.04(Had to build v2.5.2) or 18.04 LTS versions.

I'm not sure if this is ubuntu related or usb_modeswitch related, have posted the same in ubuntu forums and askubuntu.

current kernel is 5.4.0-52-generic.

Any help to resolve this is appreciated.

Thanks,

[LOM]

I don't think it is usb_modeswitch related, your log shows a successful modeswitch two times with the dongle going into standby/charge mode (12d1:1c20) in between them.
You don't get a cdc_ncm driver binding the second time after leaving standby/charge mode but that is likely a linux driver problem.

What does the usb-devices command show for the device after the second switch?

[eby]

when plugged for the first time.

Code: Select all

T:  Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1506 Rev=01.02
S:  Manufacturer=HUAWEI
S:  Product=HUAWEI Mobile
C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#=0x0 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=16 Driver=huawei_cdc_ncm
I:  If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=03 Driver=option
I:  If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=02 Driver=option
I:  If#=0x3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

when plugged for second time.

Code: Select all

T:  Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1506 Rev=01.02
S:  Manufacturer=HUAWEI
S:  Product=HUAWEI Mobile
C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#=0x0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=16 Driver=option
I:  If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=03 Driver=option
I:  If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=02 Driver=option
I:  If#=0x3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

[LOM]

The option driver is grabbing the net interface in the second plug-in, it does this only if you force it to load manually by using the new_id function.
Don't do that, when the option driver is loaded automagically then it knows to not take the net interface!

[eby]

The option driver is grabbing the net interface in the second plug-in, it does this only if you force it to load manually by using the new_id function.
Don't do that, when the option driver is loaded automagically then it knows to not take the net interface!

I don't understand "force it to load manually by using the new_id function", do you mind telling where these configs can be changed ?.

the only config change done is adding GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0", have even tried removing these and tried with liveCD, both exhibit the same behaviour.

Have not had this problem on ubuntu 18.04, 4.15.0-20-generic #21, usb_modeswitch v2.5.2 or ubuntu 14.04 with usb_modeswitch v2.5.2.

[LOM]

If you haven't done a manual bind of the option driver then there is only one possible reason left for why the option driver binds to the net interface and that is Ubuntu's modification of usb-modeswitch where they do driver loading for certain interfaces.

This is something that was removed from generic usb-modeswitch years ago because it was unreliable and because usb-modeswitch is a switching utility that should keeps it hands off driver loading and leave that to the kernel.
I noticed a while back that Ubuntu is still using that old code and implemented it on their re-written version of newer usb-modeswitch releases.

You can download and install the generic usb-modeswitch version which you find here:

https://www.draisberghof.de/usb_modeswitch/

[LOM]

You can also download the Ubuntu usb-modeswitch package for "groovy" in which they finally have removed the driver loading from usb-modeswitch.

[eby]

I noticed a while back that Ubuntu is still using that old code and implemented it on their re-written version of newer usb-modeswitch releases.

Interesting, how come this was working on 18.04LTS without any manual binding ?. Both 18.04 & 20.04 have v2.5.2 installed by default. Anyway, will try disabling options for Huawei and see what happens.

You can also download the Ubuntu usb-modeswitch package for "groovy" in which they finally have removed the driver loading from usb-modeswitch.

Will try this also.

[LOM]

There may be other problems remaining when you have got rid of the option driver from interface #0.
I just realized that in your second usb-devices listing it only have one endpoint while in the first listing it has three (this is corrrect, the ncm driver needs three endpoints in order to bind).

In any case, an interface with Class/SubClass/Protocol attributes of ff/02/16 is reserved for huawei_cdc_ncm to grab and bind to, the option driver does not take this interface unless it has been forced to do it and it is the Ubuntu usb-modeswitch which does that.

[eby]

I did the following to figure out the root cause, tested with usb_modeswitch packages that were installed by Ubuntu 20.04LTS, did not use packages for "groovy" or the official packages from here.

1, Disabled all Huawei related rules from and restarted the udevadm rules & trigger.

Code: Select all

/lib/udev/rules.d/40-usb_modeswitch.rules

2, plug the device, the device got listed as 12d1:14fe,

3, Extracted the 12d1:14fe file from the "/usr/share/usb_modeswitch/configPack.tar.gz" to /etc/usb_modeswitch.d/12d1:14fe

Code: Select all

# Huawei E352 (T-Mobile NL), E173s (Variant)
TargetVendor=0x12d1
TargetProductList="1506,150f,151d,1c1e"
HuaweiNewMode=1

4, Re-enabled the first generic entry for Huawei in 40-usb_modeswitch.rules and restarted the "udevadm" rules & trigger.

5, Plug the device 2nd time, same issue, no wwan0.

6, modify the 12d1:14fe file to, and restart "udevadm" rules & trigger.

Code: Select all

# Huawei E352 (T-Mobile NL), E173s (Variant)
TargetVendor=0x12d1
TargetProductList="1506"
HuaweiNewMode=1
NoDriverLoading=1

7, Plug the device 2nd time, same issue, no wwan0.

8, Disabled all Huawei related rules from 40-usb_modeswitch.rules, added the following device specific rule and restart "udevadm" rules & trigger.

Code: Select all

ATTR{idVendor}=="12d1", ATTR{idProduct}=="14fe", RUN+="usb_modeswitch '/%k'" 

9, Plug the device 2nd time, voila!! wwan0 is registered no matter how many times the device been re-plugged!!

mmcli -L also number it accordingly to the number of times the device been re-plugged during current boot.

first time when plugged.

Code: Select all

/org/freedesktop/ModemManager1/Modem/0 [huawei] E5220

3rd time when plugged..

Code: Select all

/org/freedesktop/ModemManager1/Modem/3 [huawei] E5220

Looks like the Generic usb_modeswitch rules for Huawei devices were messing with.

Remaining issue is the interface won't show up in network-manager, without the interface listed, vpn won't connect.

[LOM]

Looks like the Generic usb_modeswitch rules for Huawei devices were messing with.

So the rules file in Ubuntu 20.04 is not the same as the one used in your tests with 14.04 and 18.04?
The general single line rule for all Huawei devices hasn't been changed since usb_modeswitch 2.2.2 and is still the same in the current 2.6.0 version.
For some strange reason no one else has reported a problem with it and I guess you are not the only Ubuntu 20.04 user with a Huawei modem.

I suggest you install the general usb_modeswitch from us or the "groovy" version, I expect both of them to not display the problem you did encounter.

[eby]

So the rules file in Ubuntu 20.04 is not the same as the one used in your tests with 14.04 and 18.04?

For some strange reason no one else has reported a problem with it and I guess you are not the only Ubuntu 20.04 user with a Huawei modem.

I suggest you install the general usb_modeswitch from us or the "groovy" version, I expect both of them to not display the problem you did encounter.

usb_modeswitch version available on 14.04 repo did not work(i don't remember the exact version number), i had to make v2.5.2 for it and add custom rules for this device and entry in /etc/usb_modeswitch.d/12d1:14fe

for 18.04, it came with v2.5.2 and autoswitched, for 20.04 the same and autoswitched, but not switching once re-plugged without device specific rules and entry in /etc/usb_modeswitchd/

This device E5220 is a mi-fi or whatever they call device, this is not a pure usb modem, usually it is connected over wireless, since i don't have a wireless card, i prefer to connect using usb ethernet instead of getting a usb wireless card. I can't comment on no one else reporting this problem.

installed ubs_modeswitch from groovy and it doesn't work, every time i have to switch mode manually !!!!.

[eby]

1, removed existing manual entries and installed latest "groovy" packages. v2.6.1(had to install tcl-8.6.10)

auto modeswitch not happening with latest version and default rules, device list as;

Code: Select all

Bus 002 Device 006: ID 12d1:14fe Huawei Technologies Co., Ltd. Modem (Mass Storage Mode)

only manual switching works.

Code: Select all

sudo usb_modeswitch -v 12d1 -p 14fe -J

2, auto switch not happening even after - default generic huawei rules + adding entry to /etc/usb_modeswitch.d/12d1:14fe - restarted udevadm rules & trigger / computer restarted.

3, auto switch not happening even after - Disabled generic huawei entries from rules, added device specific rule - restarted udevadm rules & trigger / computer restarted.

Code: Select all

ATTR{idVendor}=="12d1", ATTR{idProduct}=="14fe", RUN+="usb_modeswitch '/%k'"

the device list as;

Code: Select all

Bus 002 Device 006: ID 12d1:14fe Huawei Technologies Co., Ltd. Modem (Mass Storage Mode)

usb_modeswitch -e

Code: Select all

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

 ! PLEASE REPORT NEW CONFIGURATIONS !

dmesg

Code: Select all

 usb 2-5: new high-speed USB device number 5 using xhci_hcd
 usb 2-5: New USB device found, idVendor=12d1, idProduct=1c20, bcdDevice= 1.02
 usb 2-5: New USB device strings: Mfr=2, Product=1, SerialNumber=0
 usb 2-5: Product: HUAWEI Mobile
 usb 2-5: Manufacturer: HUAWEI
 usb-storage 2-5:1.0: USB Mass Storage device detected
 scsi host3: usb-storage 2-5:1.0
 usbcore: registered new interface driver usb-storage
 usbcore: registered new interface driver uas
 scsi 3:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
 sr 3:0:0:0: [sr0] scsi-1 drive
 cdrom: Uniform CD-ROM driver Revision: 3.20
 sr 3:0:0:0: Attached scsi CD-ROM sr0
 sr 3:0:0:0: Attached scsi generic sg1 type 5
 usb 2-5: USB disconnect, device number 5
 usb 2-5: new high-speed USB device number 6 using xhci_hcd
 usb 2-5: New USB device found, idVendor=12d1, idProduct=14fe, bcdDevice= 1.02
 usb 2-5: New USB device strings: Mfr=2, Product=1, SerialNumber=0
 usb 2-5: Product: HUAWEI Mobile
 usb 2-5: Manufacturer: HUAWEI
 usb-storage 2-5:1.0: USB Mass Storage device detected
 scsi host3: usb-storage 2-5:1.0
 scsi 3:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
 sr 3:0:0:0: [sr0] scsi-1 drive
 sr 3:0:0:0: Attached scsi CD-ROM sr0
 sr 3:0:0:0: Attached scsi generic sg1 type 5
 sr 3:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
 sr 3:0:0:0: [sr0] tag#0 Sense Key : Hardware Error [current] 
 sr 3:0:0:0: [sr0] tag#0 Add. Sense: No additional sense information
 sr 3:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 ff fc 00 00 02 00

usb-devices

Code: Select all

T:  Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=14fe Rev=01.02
S:  Manufacturer=HUAWEI
S:  Product=HUAWEI Mobile
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#=0x0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

what next ?.

[LOM]

In one end you have udev detecting the device on the bus and taking the action specified in the rules file, in the other end you have the main usb_modeswitch program, I don't think they are responsible for your problems, manual switching works for you so the main usb_modeswitch program is ok.

The glue between udev and the main usb_modeswitch are a shell script and the usb_modeswitch dispatcher and it is in these two you have your problem, it is these two that Ubuntu has tried for a couple of years to rewrite and each time they have only created an even buggier usb_modeswitch package, check their bugzilla and you will see what I mean.
It is a mess and I really thought they had finally fixed it in "groove" based on other Ubuntu users feedback.
There is no other linux distro having so many usb_modeswitch problems, there usually are none, but then they are also using the original usb_modeswitch and not rewriting part of it!!

I suggest that you report your problems in Ubuntu bugzilla, I don't know what usb_modeswitch 2.6.1 is, the latest official version on this site is 2.6.0. I am also extremely frustrated over having to deal with Ubuntu's never ending usb_modeswitch bugs.

Josh may be able to help you next time he appears here, I can't. Sorry!

Edit: Your problem is not related to your dongle being a MiFi device, usb_modeswitch has no problem handling such devices.

[eby]

I don't know what usb_modeswitch 2.6.1 is

I guess, it is Ubuntu's way of doing things.... any way, after installing usb-modeswitch_2.6.1-1ubuntu2_amd64.deb found in "groovy" update, things started working as it should, no more device specific rules and no device entry file in /etc/usb_modeswitch.d/.

thanks for suggesting "groovy" packages.