Bug 1373274

Created attachment 1198002 [details]
log file for usb_modeswitch 2.3.0

Created attachment 1198003 [details]
log file for usb_modeswitch 2.4.0

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 ?

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 ?

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 ...

After=systemd-modules-load.service
Before=systemd-udev-trigger.service

... 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 ...

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: /
           ├─init.scope
           │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
           └─system.slice
             ├─dbus.service
             │ └─443 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
             ├─ModemManager.service
             │ └─520 /usr/sbin/ModemManager
             ├─wpa_supplicant.service
             │ └─464 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -s
             ├─systemd-journald.service
             │ └─277 /usr/lib/systemd/systemd-journald
             ├─rescue.service
             │ ├─417 /bin/sh -c /usr/sbin/sulogin; /usr/bin/systemctl --job-mode=fail --no-block default
             │ ├─418 bash
             │ └─556 systemctl status
             ├─systemd-udevd.service
             │ └─301 /usr/lib/systemd/systemd-udevd
             ├─polkit.service
             │ └─463 /usr/lib/polkit-1/polkitd --no-debug
             └─NetworkManager.service
               ├─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
-bash-4.3$ 

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.

Created attachment 1198152 [details]
current log file run in single mode boot

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.

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.

(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.

Does any rule in /usr/lib/udev/rules.d/40-usb_modeswitch.rules match ATTR{idVendor} and ATTR{idProduct} of your device?

(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.

(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.

(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.

Bug is acknowledged upstream and will be fixed in the (pending) next release.

New upstream release 2.5.0 is available.
It was tested with the Icon 225.

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.