Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1374913 - USB modeswitch 2.4.0.4 fails to detect HUAWEI mobile phone storage
Summary: USB modeswitch 2.4.0.4 fails to detect HUAWEI mobile phone storage
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: usb_modeswitch-data
Version: 24
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Huzaifa S. Sidhpurwala
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-10 10:15 UTC by htd
Modified: 2017-08-08 17:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-08 17:16:00 UTC


Attachments (Terms of Use)

Description htd 2016-09-10 10:15:58 UTC
Description of problem:

Since the last update (usb_modeswitch-2.4.0-4.fc24.x86_64), I can't access the storage on my Huawei G510 mobile phone any longer. The device shows up in dmesg and lsusb and the storage is detected correctly, but there's no way to access it (mtp can't find a device). Downgrading to the previous usb_modeswitch-2.3.0-1.fc24.x86_64 fixes the problem immediately.

Version-Release number of selected component (if applicable):
See above.

How reproducible:
Can reproduce the error at any time.

Steps to Reproduce:
1. Update to latest F24 containing usb_modeswitch-2.4.0-4.fc24.x86_64.
2. Connect mobile phone to the computer via USB.
3. No way to access the device.
4. Downgrade to usb_modeswitch-2.3.0-1.fc24.x86_64 and repeat 2.. Now, the phone storage shows up immediately.

Actual results:
See above.

Expected results:
See above.

Additional info:

Comment 1 Josua Dietze 2017-01-17 05:43:02 UTC
Can you please provide your phone's USB ID?

Does it NEED usb_modeswitch? (Can you use it normally if usb_modeswitch is globally disabled in /etc/usb_modeswitch.conf?)

Comment 2 George 2017-02-01 01:19:41 UTC
I'm seeing this in Scientific Linux 7 (CentOS7/RHEL7) since updating to 7.3.
If I disable it globally then it works as expected.
My phone is a Huawei Y560.

I've been looking at

https://bbs.archlinux.org/viewtopic.php?id=183190&p=2

and using quirks=0x12d1:0x259a

For my device.

Comment 3 Josua Dietze 2017-02-01 06:53:47 UTC
George,
can you please try the following steps?

- go to /usr/share/usb_modeswitch

- unpack the file configPack.tar.gz in that folder so that you see all the config files

- rename "configPack.tar.gz" to something else

- if there is a file named "12d1:#linux", delete it

- re-enable usb_modeswitch globally, see if the phone works anyway

Comment 4 George 2017-02-01 22:15:25 UTC
Hi Josua,

I can confirm that removing the "12d1:#linux" file makes my phone work as before.

lsusb output for device below.

Bus 003 Device 006: ID 12d1:259a Huawei Technologies Co., Ltd. 

Thanks

Comment 5 George 2017-02-01 22:17:08 UTC
More details

Bus 003 Device 006: ID 12d1:259a Huawei Technologies Co., Ltd. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x12d1 Huawei Technologies Co., Ltd.
  idProduct          0x259a 
  bcdDevice            3.10
  iManufacturer           1 Huawei Incorporated
  iProduct                2 Huawei-LTE Handset
  iSerial                 3 D7CBBBB591804335
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              4 Mass Storage
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

Comment 6 Josua Dietze 2017-02-05 08:26:51 UTC
Hello maintainers,

please re-assign this bug to usb_modeswitch-data.

It is caused by a Huawei catch-all configuration which was meant as a fall-back for modems but affects unrelated devices like phones.

Either simply remove the config file "12d1:#linux" from the config collection or wait for the upstream bugfix release of usb-modeswitch-data which is currently being prepared.

Comment 7 Fedora End Of Life 2017-07-25 22:57:15 UTC
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.

Comment 8 Fedora End Of Life 2017-08-08 17:16:00 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.