Page 1 of 1

[solved] Huawei E3372 (HiLink) doesn't work w/ 2.4.0 on Arch

Posted: 16 Jul 2016, 12:45
by pklaus
edit: The problem is solved. It was a packaging problem in Arch Linux which appeared in usb_modeswitch-2.4.0-1 and was fixed in usb_modeswitch-2.4.0-2.

-----------
original post:

I'm using a Huawei E3372 LTE Modem (exact model: E3372h-153) with a Raspberry Pi 3 running Arch Linux ARM.

It worked fine for months with the 2.3.0 version (Arch Linux ARM package usb_modeswitch-2.3.0-1-armv7h.pkg.tar.xz).

Now I updated my Arch Linux packages, usb_modeswitch to 2.4.0 (usb_modeswitch-2.4.0-1-armv7h.pkg.tar.xz on Arch Linux ARM). After the package update, the E3372 doesn't work anymore. It isn't properly mode-switched anymore.

Kernel messages for v2.4.0 (not working):

Code: Select all

[   44.020225] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
[   44.121112] usb 1-1.4: New USB device found, idVendor=12d1, idProduct=1f01
[   44.121237] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   44.121354] usb 1-1.4: Product: HUAWEI_MOBILE
[   44.121430] usb 1-1.4: Manufacturer: HUAWEI_MOBILE
[   44.121512] usb 1-1.4: SerialNumber: 0123456789ABCDEF
[   44.154595] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[   44.155297] scsi host0: usb-storage 1-1.4:1.0
[   45.157769] scsi 0:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[   45.159517] scsi 0:0:0:1: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[   45.169126] sd 0:0:0:1: [sda] Attached SCSI removable disk
[   45.183070] sr 0:0:0:0: [sr0] scsi-1 drive
[   45.185694] cdrom: Uniform CD-ROM driver Revision: 3.20
[   45.189096] sr 0:0:0:0: Attached scsi CD-ROM sr0
[   47.590920] sr 0:0:0:0: [sr0] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[   47.619662] sr 0:0:0:0: [sr0] tag#0 Sense Key : 0x3 [current] 
[   47.634047] sr 0:0:0:0: [sr0] tag#0 ASC=0x11 ASCQ=0x0 
[   47.648042] sr 0:0:0:0: [sr0] tag#0 CDB: opcode=0x28 28 00 00 00 0f fe 00 00 02 00
[   47.675683] blk_update_request: critical medium error, dev sr0, sector 16376
[   47.696058] sr 0:0:0:0: [sr0] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[   47.725846] sr 0:0:0:0: [sr0] tag#0 Sense Key : 0x3 [current] 
[   47.740912] sr 0:0:0:0: [sr0] tag#0 ASC=0x11 ASCQ=0x0 
[   47.755693] sr 0:0:0:0: [sr0] tag#0 CDB: opcode=0x28 28 00 00 00 0f fe 00 00 02 00
[   47.785347] blk_update_request: critical medium error, dev sr0, sector 16376
[   47.800680] Buffer I/O error on dev sr0, logical block 2047, async page read
When I downgrade to v2.3.0 version everything is back to normal.

Kernel messages for v2.3.0 (working):

Code: Select all

[   81.910235] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
[   82.011142] usb 1-1.4: New USB device found, idVendor=12d1, idProduct=1f01
[   82.011277] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   82.011395] usb 1-1.4: Product: HUAWEI_MOBILE
[   82.011472] usb 1-1.4: Manufacturer: HUAWEI_MOBILE
[   82.011554] usb 1-1.4: SerialNumber: 0123456789ABCDEF
[   82.070988] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[   82.071440] scsi host0: usb-storage 1-1.4:1.0
[   82.958360] usb 1-1.4: USB disconnect, device number 5
[   83.710232] usb 1-1.4: new high-speed USB device number 6 using dwc_otg
[   83.811009] usb 1-1.4: New USB device found, idVendor=12d1, idProduct=14dc
[   83.811130] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   83.811248] usb 1-1.4: Product: HUAWEI_MOBILE
[   83.811324] usb 1-1.4: Manufacturer: HUAWEI_MOBILE
[   83.921664] usb-storage 1-1.4:1.2: USB Mass Storage device detected
[   83.924133] scsi host1: usb-storage 1-1.4:1.2
[   84.109036] cdc_ether 1-1.4:1.0 eth0: register 'cdc_ether' at usb-3f980000.usb-1.4, CDC Ethernet Device, 0c:5b:8f:12:45:78
[   84.113774] usbcore: registered new interface driver cdc_ether
[   84.128795] cdc_ether 1-1.4:1.0 lte0: renamed from eth0
[   84.925849] scsi 1:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[   84.933220] sd 1:0:0:0: [sda] Attached SCSI removable disk
What information should I collect to further scrutinize the issue?

Re: Huawei E3372 (HiLink) doesn't work with 2.4.0

Posted: 17 Jul 2016, 02:11
by LOM
Do you see the same problem on a desktop linux computer?

We have had lots of different problems reported that is caused by the substandard usb controller and driver (dwc_otg) that Rpi uses and there is nothing we can do about them.
I guess, since there has been no other bug reports for usb_modeswitch 2.4.0, that your problem is related to Rpi only and is therefore something the maintainers of your linux distro should fix.

Re: Huawei E3372 (HiLink) doesn't work with 2.4.0

Posted: 17 Jul 2016, 07:29
by Josh
I'm going to test this on my Raspi 2 with my E3372 - as soon as I find the little box that I've temporarily misplaced ...

Re: Huawei E3372 (HiLink) doesn't work with 2.4.0

Posted: 17 Jul 2016, 16:48
by pklaus
On a Debian 8 desktop computer (amd64), I didn't have the problem before/after upgrading from the shipped package version 2.2.0 ("2.2.0+repack0-2") to the backported package version 2.4.0 ("2.4.0+repack0-1~bpo8+1").

I will try later with an Arch Linux based desktop computer. I'll keep you up-to-date.

Re: Huawei E3372 (HiLink) doesn't work with 2.4.0

Posted: 17 Jul 2016, 23:15
by pklaus
So my Arch Linux computer (amd64 / desktop / Linux kernel 4.6.4) has the same problem as the Raspberry Pi:

Code: Select all

[   76.441022] usb 1-1.2.2: new high-speed USB device number 6 using ehci-pci
[   76.600475] usb-storage 1-1.2.2:1.0: USB Mass Storage device detected
[   76.600612] scsi host10: usb-storage 1-1.2.2:1.0
[   77.606551] scsi 10:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[   77.607162] scsi 10:0:0:1: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[   77.609742] sr 10:0:0:0: [sr1] scsi-1 drive
[   77.609843] sr 10:0:0:0: Attached scsi CD-ROM sr1
[   77.616347] sd 10:0:0:1: [sdg] Attached SCSI removable disk
[   79.928741] sr 10:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[   79.928744] sr 10:0:0:0: [sr1] tag#0 Sense Key : 0x3 [current] 
[   79.928746] sr 10:0:0:0: [sr1] tag#0 ASC=0x11 ASCQ=0x0 
[   79.928748] sr 10:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 0f fe 00 00 02 00
[   79.928750] blk_update_request: critical medium error, dev sr1, sector 16376
[   79.940710] sr 10:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[   79.940712] sr 10:0:0:0: [sr1] tag#0 Sense Key : 0x3 [current] 
[   79.940713] sr 10:0:0:0: [sr1] tag#0 ASC=0x11 ASCQ=0x0 
[   79.940715] sr 10:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 0f fe 00 00 02 00
[   79.940716] blk_update_request: critical medium error, dev sr1, sector 16376
[   79.940718] Buffer I/O error on dev sr1, logical block 2047, async page read
Thus, it definitely isn't a USB controller issue with the Raspberry Pi. Anyhow, the E3372 was working perfectly for month on my Raspberry Pi 3.
So the problem could be with the packaging or build configuration for Arch Linux in this case.

Running journalctl -r revealed another message missing in the kernel log: An error message from systemd-udevd. No idea, if this is problematic:

Code: Select all

-- Logs begin at Sat 2014-01-25 15:05:06 CET, end at Sun 2016-07-17 22:53:51 CEST. --
Jul 17 22:53:48 owl systemd-udevd[6082]: error opening ATTR{/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/host10/scsi_host/host10/link_power_management_policy} for writing: Permission denied
I tried running the troubleshooting instructions but no log file shows up. So I tried to evoke usb_modeswitch manually:

Code: Select all

$ usb_modeswitch -v 12d1 -p 1f01 -c /usr/share/usb_modeswitch/12d1\:1f01
Look for target devices ...
 No devices in target mode or class found
Look for default devices ...
   product ID matched
 Found devices in default mode (1)
Access device 007 on bus 001
Get the current device configuration ...
Current configuration number is 1
Use interface number 0
Use endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: HUAWEI_MOBILE
     Product: HUAWEI_MOBILE
  Serial No.: 0123456789ABCDEF
-------------------------
Using standard Huawei switching message
Looking for active driver ...
 OK, driver detached
Set up interface 0
Use endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
 OK, message successfully sent
Read the response to message 1 (CSW) ...
 Response reading failed (error -1)
 Device is gone, skip any further commands
-> Run lsusb to note any changes. Bye!
This is based on the supplied config file for the stick, /usr/share/usb_modeswitch/12d1:1f01, with the following content:

Code: Select all

# Huawei E353 (3.se) and others
TargetVendor=0x12d1
TargetProductList="14db,14dc"
HuaweiNewMode=1
NoDriverLoading=1
Also dmesg / the kernel log shows the success:

Code: Select all

[ 1143.185441] usb 1-1.2.2: USB disconnect, device number 7
[ 1144.922154] usb 1-1.2.2: new high-speed USB device number 8 using ehci-pci
[ 1145.183141] usb-storage 1-1.2.2:1.2: USB Mass Storage device detected
[ 1145.183405] scsi host10: usb-storage 1-1.2.2:1.2
[ 1145.272687] cdc_ether 1-1.2.2:1.0 eth0: register 'cdc_ether' at usb-0000:00:1a.0-1.2.2, CDC Ethernet Device, 0c:5b:8f:12:45:78
[ 1145.272701] usbcore: registered new interface driver cdc_ether
[ 1145.273513] cdc_ether 1-1.2.2:1.0 enp0s26u1u2u2: renamed from eth0
[ 1146.191036] scsi 10:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[ 1146.221534] sd 10:0:0:0: [sdg] Attached SCSI removable disk
But even after this manual invocation I don't have any /var/log/usb_modeswitch_* logfile.

Anyhow. The whole thing seems to work (yeah!), the problem might be rather the udev invocation failling. Any further ideas?

And thanks, by the way, for the great usb_modeswitch. It's just awesome to have this free software working with all kinds of different hardware (modems) on Linux.

Re: Huawei E3372 (HiLink) doesn't work with 2.4.0 on Arch Li

Posted: 22 Jul 2016, 08:12
by pklaus
The problem was solved with the update of the Arch Linux package usb_modeswitch-2.4.0-2-x86_64.pkg.tar.xz.

The problem in the packaging, which lead to a non-functional systemd/udev setup concerning usb_modeswitch, was resolved (see here).

Everything seems to work fine again. So thanks once more USB_ModeSwitch!

Re: [solved] Huawei E3372 (HiLink) doesn't work w/ 2.4.0 on

Posted: 11 Jan 2018, 13:31
by rakotomandimby
Just for the record,

On usb_modeswitch 2.4.2, I also had the problem. Upgraded to 2.5.2 and it works.
I'm running Archlinux, It might be a packaging issue, or not, but I just record here to inform about the working version.

Thank you!