(In reply to Marcin Steć from comment #0)
> Description of problem:
> 3G/LTE HUAWEI E3372 modem has two operational modes. It initially connects
> to the system as mass-storage device. F23 correctly switches it into "usb
> ethernet" mode, while F24 not.

In Fedora 24 my device (E3372s-153) does not switch at work in any kind. Other USB modem (E173s-1) does not work too. Unhopefully, old option i225 is not working, so this appears to be could more general problem.

System is upgraded to current.


P.S. I observer, that in Fedora 23, switching of this modem is slighty weird. Just after machine start modem appeared, after switching, as legacy PPP modem (serial device). After restart, it switched to MBIM mode (USB Ethernet).

I've reported this bug against "pre-release" F24. Now I'm on offical F24 and the behavior slightly changed - when I plug it in, it mounts as mass storage device and Gnome gives me an option to auto-run included software. This behavior is also wrong.

I can confirm that this bug is still present in F24 (release). My Huawei E3131 (12d1:1f01) is detected as USB CD-ROM drive, and I have to modeswitch it manually using "usb_modeswitch -J -v 0x12d1 -p0x1f01" to get it to work as a modem.

Here's the output:

[   52.354272] usb 2-1.2: USB disconnect, device number 4
[   60.034111] usb 2-1.1: USB disconnect, device number 3
[   65.843295] usb 2-1.1: new high-speed USB device number 5 using ehci-pci
[   65.929858] usb 2-1.1: New USB device found, idVendor=12d1, idProduct=1f01
[   65.929865] usb 2-1.1: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[   65.929869] usb 2-1.1: Product: HUAWEI HiLink
[   65.929872] usb 2-1.1: Manufacturer: HUAWEI
[   65.931455] usb-storage 2-1.1:1.0: USB Mass Storage device detected
[   65.931673] scsi host4: usb-storage 2-1.1:1.0
[   66.934085] scsi 4:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[   66.935844] sr 4:0:0:0: [sr1] scsi-1 drive
[   66.936044] sr 4:0:0:0: Attached scsi CD-ROM sr1
[   66.936171] sr 4:0:0:0: Attached scsi generic sg2 type 5

The modem worked fine and was automatically modeswitched with Fedora 23.

I would like to confirm this problem for Huawei E3131 modem:

[19169.459306] usb 1-1.4: new high-speed USB device number 4 using ehci-pci
[19169.545850] usb 1-1.4: New USB device found, idVendor=12d1, idProduct=15ca
[19169.545855] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[19169.545865] usb 1-1.4: Product: HUAWEI Mobile
[19169.545868] usb 1-1.4: Manufacturer: HUAWEI
[19169.545870] usb 1-1.4: SerialNumber: FFFFFFFFFFFFFFFF
[19169.590579] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[19169.590874] scsi host6: usb-storage 1-1.4:1.0
[19170.607285] scsi 6:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[19170.607827] scsi 6:0:0:1: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2

and lsusb output:

Bus 001 Device 004: ID 12d1:15ca Huawei Technologies Co., Ltd. E3131 3G/UMTS/HSPA+ Modem (Mass Storage Mode)

However, manual execution of usb_modeswitch works:

# usb_modeswitch -J -v 12d1 -p 15ca

Look for default devices ...
   product ID matched
 Found devices in default mode (1)
Access device 004 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
     Product: HUAWEI Mobile
  Serial No.: FFFFFFFFFFFFFFFF
-------------------------
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 successfully read (13 bytes).
Reset response endpoint 0x81
Reset message endpoint 0x01
-> Run lsusb to note any changes. Bye!

# lsusb

Bus 001 Device 005: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard

It happend automatically before upgrade to F23.

For me it looks as udevd/systemd-related problem, not a usb_modeswitch fault. The configuration for my modem exists in /etc/usb_modeswitch.d/

I can confirm that this bug in F24 (release). My Huawei 12d1:15e7 is detected as USB CD-ROM drive, and I have to modeswitch it manually using "usb_modeswitch -J -v 0x12d1 -p0x15e7" to get it to work as a modem. It happend automatically before upgrade to F23.

Today's upgrade of systemd/udev to version 229-9 (Fedora 24) solved the issue for me.

(In reply to Adam Buraczewski from comment #6)
> Today's upgrade of systemd/udev to version 229-9 (Fedora 24) solved the
> issue for me.

Not for me :-( 
I still have to switch mode manually.

229-9.f24 did not fix it for me either :-(

Huawei E3372 aka T-Mobile Speedstick LTE V, switching only works via
# usb_modeswitch -J -v 12d1 -p 14fe

Nor sure if relevant, but I think udev/systemd calls usb_modeswitch wrong?

[ plug in ]
Jul 26 07:28:40 t440s.egolov.redhat.com root[5977]: usb_modeswitch: use overriding config file /etc/usb_modeswitch.d/12d1:14fe; make sure this is intended
Jul 26 07:28:40 t440s.egolov.redhat.com root[5978]: usb_modeswitch: please report any new or corrected settings; otherwise, check for outdated files
Jul 26 07:28:40 t440s.egolov.redhat.com usb_modeswitch[5980]: switch device 12d1:14fe on 002/006

In contrast to the log, modem is still in storage mode:
egolov@t440s ~ % lsusb
Bus 001 Device 002: ID 8087:8000 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 5986:026a Acer, Inc 
Bus 002 Device 002: ID 8087:07dc Intel Corp. 
Bus 002 Device 006: ID 12d1:14fe Huawei Technologies Co., Ltd. Modem (Mass Storage Mode)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Let's call usb_modeswitch_dispatcher by hand?
egolov@t440s ~ % sudo usb_modeswitch_dispatcher --switch-mode 12d1/14fe

Still storage:
egolov@t440s ~ % lsusb
Bus 001 Device 002: ID 8087:8000 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 5986:026a Acer, Inc 
Bus 002 Device 002: ID 8087:07dc Intel Corp. 
Bus 002 Device 006: ID 12d1:14fe Huawei Technologies Co., Ltd. Modem (Mass Storage Mode)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Maybe we need the usb bus/dev naming?
egolov@t440s ~ % sudo usb_modeswitch_dispatcher --switch-mode 002/006

Nope, still storage:
egolov@t440s ~ % lsusb
Bus 001 Device 002: ID 8087:8000 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 5986:026a Acer, Inc 
Bus 002 Device 002: ID 8087:07dc Intel Corp. 
Bus 002 Device 006: ID 12d1:14fe Huawei Technologies Co., Ltd. Modem (Mass Storage Mode)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Alright, force it!
egolov@t440s ~ % sudo usb_modeswitch -J -v 12d1 -p 14fe
Look for default devices ...
   product ID matched
 Found devices in default mode (1)
Access device 006 on bus 002
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.: 1111111111111111
-------------------------
Using standard Huawei switching message
Looking for active driver ...
 No active driver found. Detached before or never attached
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 successfully read (13 bytes).
Reset response endpoint 0x81
Reset message endpoint 0x01
 Device is gone, skip any further commands
-> Run lsusb to note any changes. Bye!

Yay, a modem:
egolov@t440s ~ % lsusb                                 
Bus 001 Device 002: ID 8087:8000 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 5986:026a Acer, Inc 
Bus 002 Device 002: ID 8087:07dc Intel Corp. 
Bus 002 Device 007: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Looks like recent update solved the issue. Unfortunately I don't remember what has been updated, didn't save the dnf's output.

(In reply to Marcin Steć from comment #10)
> Looks like recent update solved the issue. Unfortunately I don't remember
> what has been updated, didn't save the dnf's output.

It's most likely:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-494a721a73

Fixes switching on E3372 for me.

I tried the updates you mention, and now all memory cards in my Huawei smartphone are no longer recognised as usb storage, but get modeswitched. Reverting to stock F24 solves the problem immediately, which is the proof that the faulty behaviour is introduced by the patches mentioned in Comment 11.

(In reply to htd from comment #12)
> I tried the updates you mention, and now all memory cards in my Huawei
> smartphone are no longer recognised as usb storage, but get modeswitched.
> Reverting to stock F24 solves the problem immediately, which is the proof
> that the faulty behaviour is introduced by the patches mentioned in Comment
> 11.

As this bug is about Huawei broadband modems not getting mode switched and your (possible) regression is about Huawei smartphone storage devices, that falsely getting mode switched, I would suggest filing a separate bug report.

I added a comment here, hope this helps!
https://bodhi.fedoraproject.org/updates/FEDORA-2016-494a721a73

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.