[msi]

Hi there

I've used usb_modeswitch on FreeBSD for a Huawei dongle where I realized that things were not as plug and play as they are on Linux. I ended up learning way more about udev, the usb-modeswitch-data package, udev rules etc. than initially wanted, but now I'm (trying) to hack a port of the missing pieces. FreeBSD has has devd, so making devd(8) rules out of the -data package might once day become possible, but first I saw most of the "magic" was happening in usb_modeswitch.tcl aka usb_modeswitch_dispatcher.

I've tried to understand all what this script does - which is definitely specific to Linux - but since it does quite a lot of things (1205 LoC) and there aren't that many comments inside, I wanted to ask whether there is a document somewhere that would explain what it all does. Maybe someone is willing to point out the major tasks this script does - I see things like detecting the device ID etc but also an awful lot more.

The current idea is to stay with Tcl since that is what usb_modeswitch uses there and make a FreeBSD port of that script that might be invoked by devd rules. Since DragonflyBSD has devd too (inherited & shared mostly with FreeBSD) it may even be portable to this OS as well (just maybe). Actually getting things like the USB bus numbers, device id and product id are pretty easy with devd since they are available through variables in devd rules so they can be passed out to a BSD-ish usb_modedeswitch_dispatcher. Apparently udev gives way less information (on my Ubuntu laptop) to the dispatcher script so it has to figure out quite a bit on its own (true?).

Don't expect quick advances though, but I've come this far as to understand a bit more about the mechanics behind the scenes have started bastardizing one line after the usb_modeswitch.tcl for a possible BSD port.
Looking forward for some feedback, so I don't forget/missunderstand the Linux version. Maybe there is documentation around that I haven't yet catched

[Josh]

Unfortunately, the comments in the file are all there is with respect to documentation.
However, I'll gladly try to answer all specific questions about the things the script does. I'm sticking with Tcl because it makes string handling very easy and readable compared to sh, perl or C.

Here is an overview of the tasks (from memory, I'm travelling right now). You wil have guessed by now that the script relies heavily on the USB part of the Linux system filesystem (sysfs) where device attributes and driver information is available.

• Most important: sort out ambiguous switch configurations (same USB ID, different switch commands). Call the binary with the contents of the correct config file. See README of data package for some more details.
• Check for successful mode-switch. Probably optional for BSD
• Bind serial driver if there are interfaces with class 255 and no other driver grabs them automatically. Probably optional for BSD
• Create a symbolic link pointing to the likely serial interface for connection. Helps to avoid picking diagnostic and command ports. Probably optional for BSD
• New in the last version: unbind driver via sysfs before the binary tries that via libusb. Avoids some USB error messages.

I'd really start with the first bullet point which is the only essential one. In earlier versions, only the USB ID was used to identify a modem, but this doesn't work well if several identical modems are attached. So a device is now referenced through the bus and device number. That is a Linux-specific bit, as are the ways to determine USB and SCSI attributes for matching with config file names.

[msi]

Hi Josh

First: Thank you very much for your reply, that was exactly what I was looking for.

Unfortunately, the comments in the file are all there is with respect to documentation.

Not a problem at all, yes I'll likely become more specific. So my initial hope was to get pointed and reminded about the most important points the script does since I might overlook things.

[...] You wil have guessed by now that the script relies heavily on the USB part of the Linux system filesystem (sysfs) where device attributes and driver information is available.

Definitely the first thing to get sorted out. That's the part I'll have to figure out ways to get the equivalent data on FreeBSD. So far devd is able to pass out the device and vendor ID, the device class and something called cdev or device node path. Thankfully cdev (i.e. ugen2.4) contains the usb bus (2) and the device number (4).

Thus I started to implement switches that allow passing them to the BSD port of usb_modeswitch.tcl

• Most important: sort out ambiguous switch configurations (same USB ID, different switch commands). Call the binary with the contents of the correct config file. See README of data package for some more details.

This is definitely and interesting heads-up, do you mean by example the generic entry for Huawei ones?

• Check for successful mode-switch. Probably optional for BSD

At first stage likely yes, but later adding (back) this functionality might improve stability. This is also likely going to be specific to FreeBSD.

• Bind serial driver if there are interfaces with class 255 and no other driver grabs them automatically. Probably optional for BSD
• Create a symbolic link pointing to the likely serial interface for connection. Helps to avoid picking diagnostic and command ports. Probably optional for BSD

Yes, I've seen something about both things, maybe not a first priority.

• New in the last version: unbind driver via sysfs before the binary tries that via libusb. Avoids some USB error messages.

[...]

Interesting as well ... if possible I'd like to avoid the requirement to mount "linsysfs" since that's not part of a default install and maybe doesn't even contain what it does on Linux itself.

That was very helpful in adding details to the picture - I already ended up learning way more about Linux udev and FreeBSD devd than I initially intended back when buying this USB dongle

[Josh]

This is definitely and interesting heads-up, do you mean by example the generic entry for Huawei ones?

No, these are quite the contrary, general matches for whole vendor ID ranges. Can be replaced by individual configs.

Rather look at the various files for USB ID 05c6:1000. Again, see the description in the README.
This issue was the original reason to create a wrapper script in the first place