Author Message

<  Everything Coding  ~  Top device directory not found (usb_modeswitch 2.4.0)

PostPosted: Wed Jan 04, 2017 2:45 pm Reply with quote
Posts: 3 Joined: Wed Jan 04, 2017 1:31 pm
Hi,

I've got a problem with usb_modeswitch_dispatcher not properly detecting the top-directory.

viewtopic.php?f=2&t=2601 might relate.

The log contains:

Code:
greyscale ~ # cat /var/log/usb_modeswitch_3-1\:1.0

USB_ModeSwitch log from Wed Jan 04 13:22:09 SAST 2017

Use global config file: /etc/usb_modeswitch.conf
Raw args from udev: 0000:00:14.0/3-1:1.0

argList: 0000:00:14.0
argList: 3-1:1.0
Top device directory not found (/sys/bus/usb/devices/0000)! Exit

greyscale ~ #


I've modified the dispatcher slightly:

Code:
# arg 0: the bus id for the device (udev: %b), often ommitted
# arg 1: the "kernel name" for the device (udev: %k)
#
# Used to determine the top directory for the device in sysfs

set ifChk 0
if {[string length [lindex $argList 0]] == 0} {
    if {[string length [lindex $argList 1]] == 0} {
        Log "No device number values given from udev! Exit"
        SafeExit
    } else {
        if {![regexp {(.*?):} [lindex $argList 1] d dev_top]} {
            if {![regexp {([0-9]+-[0-9]+\.?[0-9]*.*)} [lindex $argList 1] d dev_top]} {
                Log "Could not determine device dir from udev values! Exit"
                SafeExit
            }
        }
    }
} else {
    Log "argList: [lindex $argList 0]"
    Log "argList: [lindex $argList 1]"
    set dev_top [lindex $argList 0]
    regexp {(.*?):} $dev_top d dev_top
}

set devdir /sys/bus/usb/devices/$dev_top


The reason I think the referenced topic might relate is due to it discussing the busname - but I don't know enough to know if it's definitely the same thing (the code here references bus id).

For now I've simply modified the above code to read as:

Code:
# arg 0: the bus id for the device (udev: %b), often ommitted
# arg 1: the "kernel name" for the device (udev: %k)
#
# Used to determine the top directory for the device in sysfs

set ifChk 0if {[string length [lindex $argList 1]] > 0} {
    if {![regexp {(.*?):} [lindex $argList 1] d dev_top]} {
        if {![regexp {([0-9]+-[0-9]+\.?[0-9]*.*)} [lindex $argList 1] d dev_top]} {
            Log "Could not determine device dir from udev values! Exit"
            SafeExit
        }
    }
} else {
    set dev_top [lindex $argList 0]
    regexp {(.*?):} $dev_top d dev_top
}


Essentially, I've changed it to use [lindex $argList 1] if available, and fall back to the busname/id if not. This was on version 2.4.0 but 2.2.6 and 2.3.0 exhibited the same problem, and I expect that the same code will apply on those branches too.

With this change it works for me, having said that the amount of testing is minimal and I suspect someone with a better understanding of the names/values being passed, and why %k might be unusable in some cases (if any) should probably eyeball this before it goes into any kind of distribution.

Looking at the udev man page the question as to whether %p might be useful also arises. My expectation would be that %p will (in my case above) give:

Code:
/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0


The "dev_top" folder thus just becomes %p/.. (ie, one folder up):

Code:
greyscale devices # pwd
/sys/bus/usb/devices
greyscale devices # ls -la 3-1*
lrwxrwxrwx 1 root root 0 Jan  4 14:35 3-1 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-1
lrwxrwxrwx 1 root root 0 Jan  4 14:40 3-1:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0
lrwxrwxrwx 1 root root 0 Jan  4 14:40 3-1:1.1 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.1
lrwxrwxrwx 1 root root 0 Jan  4 14:40 3-1:1.2 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.2
lrwxrwxrwx 1 root root 0 Jan  4 14:40 3-1:1.3 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.3
lrwxrwxrwx 1 root root 0 Jan  4 14:40 3-1:1.4 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.4


Again: This is on MY SYSTEM and as per other threads there are LOTS of historic things that needs to be considered so someone with a better understanding should probably provide some insight here.


Offline
PostPosted: Thu Jan 05, 2017 12:08 am Reply with quote
Site Admin Posts: 6443 Joined: Sat Nov 03, 2007 12:30 am
Thanks for the report!

This problem has been noted by others too (as you've pointed out) and is indeed in the pipeline for the next program update.
The first parameter can be dropped altogether, it's a relic from the beginnings of the usb_modeswitch history, when udev was still young and systemd wasn't wide-spread yet.

I'll take this as a hint to start working on that new release ...


Offline
PostPosted: Thu Jan 05, 2017 8:18 am Reply with quote
Posts: 3 Joined: Wed Jan 04, 2017 1:31 pm
Thanks Josh! Much appreciated.


Offline
PostPosted: Thu May 18, 2017 3:27 pm Reply with quote
Posts: 1 Joined: Thu May 18, 2017 3:09 pm
Hello everyone

I have very similar behaviour, running Ubuntu 16.04.2 server (upgraded from Ubuntu 14.04) and having usb-modeswitch 2.2.5+repack0-1u amd64.

I have tested couple of Huawei sticks to send sms messages. Both Huaweis behave properly in fresh install Ubuntu 16.04.2 server. But in this upgraded server both sticks stay in CD-ROM mode.

I followed Troubleshooting instructions and turned logging on. I didn't get any device specific logging. But in usb_modeswitch.log I found following rows:
Started via systemd
Raw args from udev: 2-5_2-5:1.0
Bus ID for device not given by udev.
Trying to determine it from kernel name (2-5_2-5:1.0) ...
Top device directory not found (/sys/bus/usb/devices/2-5_2-5)! Exit.

When I looked that directory, I had many links but not that one. Closest three where:
/sys/bus/usb/devices/2-5 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2/2-5/
/sys/bus/usb/devices/2-5:1.0 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/
/sys/bus/usb/devices/2-5:1.1 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.1/

Looks to me udev and usb-modeswitch expect something different?

Any tips how to continue?


Offline
PostPosted: Thu May 18, 2017 5:50 pm Reply with quote
Site Admin Posts: 6443 Joined: Sat Nov 03, 2007 12:30 am
It looks like this is a problem of the wrapper component of the Ubuntu fork.

I suggest trying with the original source from this site (or the Debian package of 2.2.5).


Offline

Display posts from previous:  Sort by:

All times are UTC+02:00
Page 1 of 1
5 posts
Users browsing this forum: No registered users and 1 guest
Search for:
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum