Automatic Activation, Hotplug and UDEV, Configuration
Post Reply
usbmodeswitchuser
Posts: 6
Joined: 09 Mar 2020, 03:36

Huawei E3531s-2, or is it E3372, or is it E33372, annoyances

Post by usbmodeswitchuser » 11 Mar 2020, 02:07

Device information is:
12d1:1f01 -> 12d1:14dc.
lsusb names 12d1:14dc as

Code: Select all

Huawei Technologies Co., Ltd. E33372 LTE/UMTS/GSM HiLink Modem/Networkcard
Sticker on the device identifies it as Huawei E3531s-2.
Usb_modeswitch works out of the box, with two annoyances:

1.
If the device worked on one OS, and warm reboot changes the OS to another one on a dual boot machine, the device doesn't get automatically fully working. I have to disconnect, and reconnect it, to get it fully working. When it worked on Windows, and warm reboot was made into linux, I can see by lsusb that it is already switched to 12d1:14dc. As if it kept the switching Windows forced it into. Yet linux does not recognizes it as a network adapter. The corresponding cdc_ether kernel module doesn't get loaded automatically. And even if I modprobe it manually, the device is not recognized as a network adapter. ip link doesn't list it. What can I do from the command line to make it reset, or something?

Code: Select all

usb_modeswitch --reset-usb -v 12d1 -p 14dc
output is:

Code: Select all

Look for default devices ...
 Found devices in default mode (1)
Access device 002 on bus 002
Get the current device configuration ...
Current configuration number is 1
Use interface number 0
 with class 224
Warning: no switching method given. See documentation
Reset USB device .
 Device was reset
-> Run lsusb to note any changes. Bye!
lsusb shows nothing changed.

2.
When cold booting the machine into linux (after it was powered off), log has:
I hope I captured it all:

Code: Select all

Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 Sense Key : 0x3 [current] 
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 ASC=0x11 ASCQ=0x0 
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 ff fc 00 00 02 00
Mar 09 02:26:41 kernel: blk_update_request: critical medium error, dev sr1, sector 262128 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Mar 09 02:26:41 kernel: attempt to access beyond end of device
Mar 09 02:26:41 kernel: sr1: rw=0, want=262136, limit=262128
Mar 09 02:26:41 kernel: Buffer I/O error on dev sr1, logical block 32766, async page read
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 Sense Key : 0x3 [current] 
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 ASC=0x11 ASCQ=0x0 
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 fe 80 00 00 3c 00
Mar 09 02:26:41 kernel: blk_update_request: critical medium error, dev sr1, sector 260608 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 Sense Key : 0x3 [current] 
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 ASC=0x11 ASCQ=0x0 
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 fe 80 00 00 02 00
Mar 09 02:26:41 kernel: blk_update_request: critical medium error, dev sr1, sector 260608 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Mar 09 02:26:41 kernel: Buffer I/O error on dev sr1, logical block 32576, async page read
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 Sense Key : 0x3 [current] 
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 ASC=0x11 ASCQ=0x0 
Mar 09 02:26:41 kernel: sr 6:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 ff fa 00 00 02 00
Mar 09 02:26:41 kernel: blk_update_request: critical medium error, dev sr1, sector 262120 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Mar 09 02:26:41 kernel: attempt to access beyond end of device
Mar 09 02:26:41 kernel: sr1: rw=0, want=262128, limit=262120
Mar 09 02:26:41 kernel: Buffer I/O error on dev sr1, logical block 32765, async page read
I think usb_modeswitch start to work only some time afterwards. So that might not be related to usb_modeswitch. Or am I wrong?
If I am right, do you think it is a hardware fault? Something does want more than the limit. 262128, where the limit is 262120. Or, some time sooner, 262136, where the limit is 262128.
Last edited by usbmodeswitchuser on 15 Mar 2020, 19:23, edited 2 times in total.

LOM
Posts: 1404
Joined: 11 Jul 2012, 15:14
Location: Koh Samui, TH

Re: Huawei E3531s-2 E3372 annoyances

Post by LOM » 13 Mar 2020, 03:59

The mode switch message in MS Windows is different from the one in linux, both of them makes the modem morph into 12d1:14dc but for MS Windows the modem interfaces are for NDIS (Microsofts native and proprietary version of ethernet) while for linux they are for common ethernet.

The modem will carry over its configuration from MS Windows to linux on your dual-boot machine if USB power is present all the time so either you break power ie reset the modem by removing-inserting it or you load the rndis_host driver in linux.
The rndis_host driver is dependent on the cdc_ether driver so both of them must be loaded.

usbmodeswitchuser
Posts: 6
Joined: 09 Mar 2020, 03:36

Re: Huawei E3531s-2, or is it E3372, or is it E33372, annoyances

Post by usbmodeswitchuser » 15 Mar 2020, 09:06

  1. One reason why the sticker states it is model E3531s-2 while the USB vendor:product code matches E3372 is that E3372 sometime has antenna ports while my device hasn't. In addition, I am not sure if I previously didn't notice, or something has changed. As of this writing, lsusb reports it is E33372 with a triple 3, not E3372.
  2. rndis_host probably does the job of managing the device with warm reboot from Windows. I used the word probably because I had difficulties with it. Yet these difficulties could be a result of something I had done wrong. I will keep watching it.
    Still, I do prefer to avoid using the rndis_host module.
    Isn't there a way for usb_modeswitch to put the device into the common ethernet mode from the shell command line, without breaking power by removing-inserting it?
  3. On windows, is there a way to reset from linux common ethernet mode into a state that rndis will work? That is, other than breaking power by removing-inserting it after a warm reboot?
  4. Do you think the file system issue is not related to usb_modeswitch?
Last edited by usbmodeswitchuser on 15 Mar 2020, 19:24, edited 1 time in total.

LOM
Posts: 1404
Joined: 11 Jul 2012, 15:14
Location: Koh Samui, TH

Re: Huawei E3531s-2 E3372 annoyances

Post by LOM » 15 Mar 2020, 13:04

You can not switch back a device after it has been switched, it stays in the mode it is in until it loses power.

The file system error is not related to usb_modeswitch, it can't be for many reasons and one of them is that usb_modeswitch is not invoked by udev for 12d1:14dc which is the id your dongle has when detected in linux after coming from windows.
usb_modeswitch does furthermore never read records from the filesystem of a storage device.

usbmodeswitchuser
Posts: 6
Joined: 09 Mar 2020, 03:36

Re: Huawei E3531s-2, or is it E3372, or is it E33372, annoyances

Post by usbmodeswitchuser » 15 Mar 2020, 16:25

LOM wrote: 15 Mar 2020, 13:04 The file system error is not related to usb_modeswitch, it can't be for many reasons and one of them is that usb_modeswitch is not invoked by udev for 12d1:14dc which is the id your dongle has when detected in linux after coming from windows.
usb_modeswitch does furthermore never read records from the filesystem of a storage device.
In case someone will see this thread in the future:
The file system error only occurs when the device is not switched. That is, only if it is 12d1:1f01.
The error occurs before switching. When linux enumerate and check the devices, or something similar.
I guess that after the switch it replaces its cdrom like behavior with a network/modem like behavior.

Post Reply