Bug 1373274 - usb_modeswitch 2.4.0-4 won't detect my HSDPA modem, while 2.3.0-1 does.
Summary: usb_modeswitch 2.4.0-4 won't detect my HSDPA modem, while 2.3.0-1 does.
Alias: None
Product: Fedora
Classification: Fedora
Component: usb_modeswitch
Version: 24
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: romal
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-09-05 16:27 UTC by Ali Akcaagac
Modified: 2017-08-08 17:02 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-08 17:02:19 UTC
Type: Bug

Attachments (Terms of Use)
log file for usb_modeswitch 2.3.0 (1.69 KB, text/plain)
2016-09-05 17:37 UTC, Ali Akcaagac
no flags Details
log file for usb_modeswitch 2.4.0 (1.65 KB, text/plain)
2016-09-05 17:38 UTC, Ali Akcaagac
no flags Details
current log file run in single mode boot (1.66 KB, text/plain)
2016-09-06 09:39 UTC, Ali Akcaagac
no flags Details

Description Ali Akcaagac 2016-09-05 16:27:09 UTC
I reported an issue earlier this day that my HSDPA modem wasn't detected under Fedora 24 (while it does perfectly with Fedora 20 and 22 (and earlier)).

The report can be found here:


After an entire day of trying to figure out the issue I finally found out that usb_modeswitch 2.4.0-4 is the cause of the problem. Going back to usb_modeswitch 2.3.0-1 solved the problem, as explained here:


I heard that there has been some issues and that latest usb_modeswitch has solved them... Unfortunately the *latest* is 2.4.0-4 (which sadly introduces issues with my HSDPA modem).

I have an old web'n walk stick from T-Online (Option iCON 225).

Please fix if possible.

My ISP had issues last night and entire network, telephone, tv was down. I had to use my HSDPA as backup but sadly spent the entire day to figure out why this new issue failed...

Comment 1 Ali Akcaagac 2016-09-05 17:37:54 UTC
Created attachment 1198002 [details]
log file for usb_modeswitch 2.3.0

Comment 2 Ali Akcaagac 2016-09-05 17:38:18 UTC
Created attachment 1198003 [details]
log file for usb_modeswitch 2.4.0

Comment 3 Ali Akcaagac 2016-09-05 19:58:34 UTC
I was able to isolate this issue even more and got the thing running under usb_modeswitch-2.4.0-4.

The problem seem to be laying with the systemd service file and the usb_modeswitch udev file.

I removed replaced the systemd service and udev file of 2.4.0 with the old ones that came with 2.3.0 after usb_modeswitch-2.4.0-4.rpm got installed.

Now the HSDPA stick works as usually.

I believe there is some timing issue.

The udev script from 2.3.0 has a while loop inside, that spawns a separate thread, waits max 20 seconds and retries dispatcher calles... the while loop has been removed within the udev script from 2.4.0 and all it does is call one shot.

Can this be reviewed please ?

Comment 4 Ali Akcaagac 2016-09-05 20:55:29 UTC
Isolating even more.

Assume that usb_modeswitch* (incl. data) is being installed (reinstalled) from scratch. All systemd and udev files installes properly into /usr/lib/systemd /usr/lib/udev

In the previous comment I said that I replaced the 2.4.0 systemd/udev files with the ones that came by 2.3.0... This is not required.

Infact the udev script still is the cause of the issues I have with my HSDPA modem.

Deleting "/usr/lib/udev/usb_modeswitch" basicly solves the issue.

The reason why 2.3.0 udev usb_modeswitch worked was, because within the while [ 20 ] it wasn't able to find one of the conditions and existed.

The udev_modeswitch from 2.4.0 otoh causes the error that my device is not being detected because it executes.

if [ `basename $init_path` = "systemd" ] ; then
  systemctl --no-block start usb_modeswitch@$p1'_'$p2.service
elif ...

So the systemctl --no-block... is being executed and this will cause the HSDPA modem to not show up.

Deleting that said line (and replacing it with an empty echo to satisfy the "if" clause) makes everything work.

Please don't ask me why, how and what... I don't know either and it doesn't make any sense for me at all... But my HSDPA doesn't want anything inside there to be executed at all.. Just leaving it...

What could cause this and why is this so ? And even more... How can this be solved correctly within the package ?

Comment 5 Ali Akcaagac 2016-09-06 07:46:33 UTC
Today I spent some time playing with the usb_modeset@.service file that came with the usb_modesetting-2.4.0-1 package.

My thoughts can be described as following.

I have to remove the usb_modeprobe file from udev to get my HSDPA stick to operate normally.

The udev script triggers the usb_modeset@.service file.

The questions are... when ? what time ? in which row ? ... and does this cause the problem that the HSDPA stick is not recognized ?

Most systemd service files have dependencies that are marked with the "Before" and "After" keywords.

The questions here are ...

1) Are all kernel modules loaded before this script is triggered.
2) Is the UDEV service already running before this script is triggered.
3) Will any other script undo module loading or something else.
4) Are drivers for external USB hubs being loaded before.

Right now the usb_modeset@.service file is just a oneshot.

Once UDEV is triggered it shots the usb_modeset script which triggers the usb_modeset@.service systemd service.

Is it guaranteed that all kernel modules are loaded at that time ? So the HSDPA modem (or kernel module) has the time to load before it triggers any of that above ? And so on...

I was playing with some "Before" and "After" keywords ...


... and had mixed results ... One time I got the HSDPA stick respond with a connect signal (the way the LED blinks) and then the moment after it dropped it again ...

Comment 6 Ali Akcaagac 2016-09-06 09:38:31 UTC
I booted Fedora 24 in single user mode (without any gui and least possible services loaded... the step after rescue)...

From that point I manually started the NetworkManager and ModemManager service.

-bash-4.3$ sudo cat /root/resc.txt
● localhost.localdomain
    State: maintenance
     Jobs: 0 queued
   Failed: 0 units
    Since: Tue 2016-09-06 10:46:16 CEST; 3min 8s ago
   CGroup: /
           │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
             │ └─443 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
             │ └─520 /usr/sbin/ModemManager
             │ └─464 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -s
             │ └─277 /usr/lib/systemd/systemd-journald
             │ ├─417 /bin/sh -c /usr/sbin/sulogin; /usr/bin/systemctl --job-mode=fail --no-block default
             │ ├─418 bash
             │ └─556 systemctl status
             │ └─301 /usr/lib/systemd/systemd-udevd
             │ └─463 /usr/lib/polkit-1/polkitd --no-debug
               ├─440 /usr/sbin/NetworkManager --no-daemon
               └─485 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-wlp0s18f2u1u4.pid -lf /var/lib/NetworkManager/dhclient-0debaac7-c283-4864-a17c-4abaf1540e94-wlp0s18f2u1u4.lease -cf /var/lib/NetworkManager/dhclient-wlp0s18f2u1u4.conf wlp0s18f2u1u4

The systemd-udevd.service is being triggered and this again triggers the usb_modeswitch script within the /usr/lib/udev directory.

This instantly triggers the...

systemctl --no-block start usb_modeswitch@$p1'_'$p2.service

... call which results in the attached usb_modeswitch_1-1.2 log

... as soon as the dispatcher within said service file is triggered, the HSDPA stick won't do anything anymore. No loadup, no dialing nothing. It just sits there blinking. Even ModemManager is not able to login into the ISP.

My only solution so far is disabling the entire systemctl line within the usb_modeset script within the /usr/lib/udev directory, so the dispatcher isn't called at all.

After this has been done, rebooting the system will have ModemManager instantly connect the HSDPA stick to the ISP.

Comment 7 Ali Akcaagac 2016-09-06 09:39:08 UTC
Created attachment 1198152 [details]
current log file run in single mode boot

Comment 8 Ali Akcaagac 2016-09-06 10:40:34 UTC
Sorry for the spam lately...

As it turns out usb_modeswitch is not necessary needed for this HSDPA modem, since it already boots up in the correct mode. Most likely caused by the hso.ko driver.

I didn't know this before receiving and dealing with this issue at all. Still raises the question why usb_modeswitch is installed by default on the Workstation (which is no problem at all). But even more, why usb_modeswitch won't leave the device *untouched* if it detects it in it's list and no switch is needed ?

My proper solution to this right now is to entirely "dnf remove usb_mode*" from this installation. Everything is working now.

Comment 9 Dan Williams 2016-09-14 15:41:26 UTC
usb_modeswitch is required for a large number of devices, so installation on Workstation is appropriate.

For your iCON 225, there is a USB storage driver that will force older Option devices into modem mode without usb_modeswitch.  This driver is a very-old left-over from before usb_modeswitch became the preferred solution, but cannot be removed from the kernel due to backwards compatibility reasons.  So it's not surprising usb_modeswitch isn't required for your device.

What is surprising is that usb_modeswitch cannot deal with this, and somehow disables the modem.

Comment 10 Ali Akcaagac 2016-09-20 09:26:46 UTC
(In reply to Dan Williams from comment #9)
> What is surprising is that usb_modeswitch cannot deal with this, and somehow
> disables the modem.

Thanks for the throughly and informative feedback. Is there anything I can do to help solving the *disable* modem issue ? This may be useful for other participants as well.

Comment 11 samoht0 2016-09-30 14:43:03 UTC
Does any rule in /usr/lib/udev/rules.d/40-usb_modeswitch.rules match ATTR{idVendor} and ATTR{idProduct} of your device?

Comment 12 Ali Akcaagac 2016-10-25 11:00:49 UTC
(In reply to samoht0 from comment #11)
> Does any rule in /usr/lib/udev/rules.d/40-usb_modeswitch.rules match
> ATTR{idVendor} and ATTR{idProduct} of your device?

Yes it does. I also provided the logs above where idVendor and idProduct is listed. The values appear in 40-usb_modeswitch.rules.

Comment 13 samoht0 2016-10-25 17:55:15 UTC
(In reply to Ali Akcaagac from comment #12)
> Yes it does. I also provided the logs above where idVendor and idProduct is
> listed. The values appear in 40-usb_modeswitch.rules.

So my suggestion is to comment that rules out. This should stop the switching.

Comment 14 Ali Akcaagac 2016-11-10 11:52:22 UTC
(In reply to samoht0 from comment #13)
> So my suggestion is to comment that rules out. This should stop the
> switching.

Thanks for your feedback. I already uninstalled the entire package to solve this issue for *me*. Unfortunately this is not the proper solution to this problem. The problem should be fixed in a way, that it won't show up anymore even for other people and even for the future. In 2 years I most likely forgot what I did to make this thing running and most likely deal with other new problems in other areas of fedora. Therefore it would make sense to fix this correctly.

Comment 15 Josua Dietze 2017-01-17 05:35:08 UTC
Bug is acknowledged upstream and will be fixed in the (pending) next release.

Comment 16 Josua Dietze 2017-01-17 20:35:13 UTC
New upstream release 2.5.0 is available.
It was tested with the Icon 225.

Comment 17 Fedora End Of Life 2017-07-25 22:50:45 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 18 Fedora End Of Life 2017-08-08 17:02:19 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

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.