Mysterious DEVD doesn't want to do anything

ogogon

ogogon

Colleagues, unfortunately, I do not have friendly relations with DEVD and I am forced to turn to the community.

This is the second time I have encountered a typical problem - the attached USB dongle receives the wrong owner for the terminal special file that has arisen. It would seem that for DEDV this is a familiar, trivial task. But either he doesn’t want to work, or I’m not persuading him well.

For example, I am connected a 3G modem Huawei E1550.
From it, as many as twelve special files sprout into the /dev directory, of which I really need two - cuaU0.1 and cuaU0.2. All these files are owned by uucp:dialer, but I need it to be asterisk:asterisk.
Bus /dev/usb Device /dev/ugen3.6: ID 12d1:1001 Huawei Technologies Co., Ltd. E161/E169/E620/E800 HSDPA Modem
Click to expand...
I create a configuration file and put it in /etc/devd.
attach 100 {
match "vendor" "0x12d1";
match "product" "0x1001";
action "chown asterisk:asterisk /dev/$cdev";
};
Click to expand...
Of course, I restart DEVD.

After I remove and reinsert the dongle, no changes in the logic of the process occur. Newly created special files still belong to uucp:dialer.

I uncommented the devd line in syslog.conf and changed the metric to *.* - it doesn’t write anything there.
I couldn't figure out if it was possible to change its log verbosity or enable debugging.
How can one learn about the events of his rich spiritual life? He is mysteriously silent and does nothing.

Tell me, please, colleagues, what am I doing wrong?

Ogogon.
 
ogogon said:
I create a configuration file and put it in /etc/devd
Click to expand...
The right place for such a file is /usr/local/etc/devd. For debugging, start devd manually as root from the command line with /sbin/devd -d, it will give additional info.
Use an action like action "/usr/bin/logger $*"; , so you can see the parms that you're receiving in /var/log/messages.
 
Tieks said:
Use an action like action "/usr/bin/logger $*"; , so you can see the parms that you're receiving in /var/log/messages.
Click to expand...
Thank you. I took your advice and got something interesting.
Mar 31 18:42:15 devel kernel: ugen3.6: <HUAWEI Technology HUAWEI Mobile> at usbus3
Mar 31 18:42:15 devel kernel: u3g0 on uhub10
Mar 31 18:42:15 devel kernel: u3g0: <HUAWEI Technology HUAWEI Mobile, class 0/0, rev 2.00/0.00, addr 6> on usbus3
Mar 31 18:42:15 devel kernel: u3g0: Found 3 ports.
Mar 31 18:42:15 devel ogogon[3495]: !system=USB subsystem=DEVICE type=ATTACH ugen=ugen3.6 cdev=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 sernum="" release=0x0000 mode=host port=4 parent
=ugen3.4
Mar 31 18:42:15 devel ogogon[3500]: !system=USB subsystem=INTERFACE type=ATTACH ugen=ugen3.6 cdev=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 sernum="" release=0x0000 mode=host interface=
0 endpoints=3 intclass=0xff intsubclass=0xff intprotocol=0xff
Mar 31 18:42:15 devel ogogon[3505]: !system=USB subsystem=INTERFACE type=ATTACH ugen=ugen3.6 cdev=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 sernum="" release=0x0000 mode=host interface=
1 endpoints=2 intclass=0xff intsubclass=0xff intprotocol=0xff
Mar 31 18:42:15 devel ogogon[3510]: !system=USB subsystem=INTERFACE type=ATTACH ugen=ugen3.6 cdev=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 sernum="" release=0x0000 mode=host interface=
2 endpoints=2 intclass=0xff intsubclass=0xff intprotocol=0xff
Click to expand...
By the way, how did he understand that it was Ogogon who took out and inserted the dongle into the hub? Is he clairvoyant?
Unfortunately, after that his talents dried up, he showed the name of the device ugen3.6, but the chown either did not do it or it did not bring results.
When I did chown manually, the file in /dev/usb, to which the symlink named /dev/ugen3.6 pointed, changed the owner to asterisk:asterisk. The cuaU0* and ttyU0* special files pretended that what was happening did not concern them at all.

How can I achieve the required result?
 
ogogon said:
How can I achieve the required result?
Click to expand...
It looks like you're still using to match vendor-id and product-id. Both are variables that are part of a USB system event. You are trying to change owner and group of the device files, these will be created by DEVFS, not USB. What goes wrong is that the chown action is executed before DEVFS created the device files. Try again with something like this:
Code: 
attach 100 {
   match "vendor"          "0x12d1";
   match "product"         "0x1001";
   action "/usr/bin/logger By USB $*";
};

notify 100 {
    match "system"<---->"DEVFS";
    action "/usr/bin/logger By DEVFS $*";
};

See devd.conf() for system, subsystem and variable names that can be used.
 
tingo said:
Also, don't forget to check devfs.rules(5), you might have statements in there that "overrides" your devd script.
Click to expand...
Thank you.
As far as I understand, this solution could solve my problems if I only had voice modem serial ports. But the server also expects other serial ports, for example, an UPS device interface, the owner of which must be nut:nut.
In addition, I want to learn how to give devices individual fixed names so that connecting something else doesn’t destroy the existing naming system.

I currently have no devfs rules declared and this does not seem to affect the situation described above.
 
Tieks said:
Try again with something like this:
Click to expand...
Thank you. It turned out like this:
Mar 31 21:58:33 devel ogogon[4996]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=usb/3.6.0
Mar 31 21:58:33 devel ogogon[5001]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ugen3.6
Mar 31 21:58:33 devel kernel: ugen3.6: <HUAWEI Technology HUAWEI Mobile> at usbus3
Mar 31 21:58:33 devel kernel: u3g0 on uhub10
Mar 31 21:58:33 devel kernel: u3g0: <HUAWEI Technology HUAWEI Mobile, class 0/0, rev 2.00/0.00, addr 6> on usbus3
Mar 31 21:58:33 devel kernel: u3g0: Found 3 ports.
Mar 31 21:58:33 devel ogogon[5006]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=usb/3.6.1
Mar 31 21:58:33 devel ogogon[5011]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=usb/3.6.2
Mar 31 21:58:33 devel ogogon[5016]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=usb/3.6.3
Mar 31 21:58:33 devel ogogon[5021]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=usb/3.6.4
Mar 31 21:58:33 devel ogogon[5026]: !system=USB subsystem=DEVICE type=ATTACH ugen=ugen3.6 cdev=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 sernum="" release=0x0000 mode=host port=4 parent=ugen3.4
Mar 31 21:58:34 devel ogogon[5031]: !system=USB subsystem=INTERFACE type=ATTACH ugen=ugen3.6 cdev=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 sernum="" release=0x0000 mode=host interface=0 endpoints=3 intclass=0xff intsubclass=0xff intprotocol=0xff
Mar 31 21:58:34 devel ogogon[5036]: !system=USB subsystem=INTERFACE type=ATTACH ugen=ugen3.6 cdev=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 sernum="" release=0x0000 mode=host interface=1 endpoints=2 intclass=0xff intsubclass=0xff intprotocol=0xff
Mar 31 21:58:34 devel ogogon[5041]: !system=USB subsystem=INTERFACE type=ATTACH ugen=ugen3.6 cdev=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 sernum="" release=0x0000 mode=host interface=2 endpoints=2 intclass=0xff intsubclass=0xff intprotocol=0xff
Mar 31 21:58:34 devel ogogon[5046]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.0
Mar 31 21:58:34 devel ogogon[5051]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.0.init
Mar 31 21:58:34 devel ogogon[5056]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.0.lock
Mar 31 21:58:34 devel ogogon[5061]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.0
Mar 31 21:58:34 devel ogogon[5066]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.0.init
Mar 31 21:58:34 devel ogogon[5071]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.0.lock
Mar 31 21:58:34 devel ogogon[5076]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.1
Mar 31 21:58:34 devel ogogon[5081]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.1.init
Mar 31 21:58:34 devel ogogon[5086]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.1.lock
Mar 31 21:58:34 devel ogogon[5091]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.1
Mar 31 21:58:34 devel ogogon[5096]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.1.init
Mar 31 21:58:34 devel ogogon[5101]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.1.lock
Mar 31 21:58:34 devel ogogon[5106]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.2
Mar 31 21:58:34 devel ogogon[5111]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.2.init
Mar 31 21:58:34 devel ogogon[5116]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=ttyU0.2.lock
Mar 31 21:58:34 devel ogogon[5121]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.2
Mar 31 21:58:34 devel ogogon[5126]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.2.init
Mar 31 21:58:34 devel ogogon[5131]: By DEVFS !system=DEVFS subsystem=CDEV type=CREATE cdev=cuaU0.2.lock
Mar 31 21:58:34 devel ogogon[5136]: By USB +u3g0 at bus=3 hubaddr=4 port=4 devaddr=6 interface=0 ugen=ugen3.6 vendor=0x12d1 product=0x1001 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0000 mode=host intclass=0xff intsubclass=0xff intprotocol=0xff ttyname=U0 ttyports=3 on uhub10
Click to expand...
Even the owners asterisk:asterisk are setted correctly.

notify 100 {
match "system" "DEVFS";
match "subsystem" "CDEV";
match "type" "CREATE";
action "/usr/bin/logger By DEVFS $*";
action "chown asterisk:asterisk /dev/$cdev";
};
Click to expand...
But now it will process all devices this way. How can this also be tied to the vendor and product?
I tried entering the lines
match "vendor" "0x12d1";
match "product" "0x1001";
Click to expand...
but it stopped working.
 
Does it help if you try to match on usb instead?
Something like this
Code: 
root@kg-core2:~ # cat /usr/local/etc/devd/dirtyjtag.conf
# allow group (operator) to access the usb connection of dirtyjtag

notify 100 {
        match "system"          "USB";
        match "subsystem"       "INTERFACE";
        match "type"            "ATTACH";
        match "vendor" "0x1209";
        match "product" "0xc0ca";
        action "usb_devaddr=`echo $cdev | sed 's#^ugen##'` && chmod g+rw /dev/usb/${usb_devaddr}.*";
};
(don't copy everything - the details here are for a different device, adjust to your device).
 
ogogon said:
But now it will process all devices this way. How can this also be tied to the vendor and product?
Click to expand...
Matching vendor and product won't work with DEVFS events, these vars only show up in USB system events.

If you need to distinguish between different USB devices that produce similar device files, you can use shell scripts as an action. For instance, in a system=USB, type=ATTACH event you could use action "echo $vendor $product > /tmp/new_usbdev". In the following system=DEVFS, type=CREATE events you enter the name of a shell script as the action, e.g. action "myscript $cdev";. That shell script reads /tmp/new_usbdev and then sets user and group accordingly.
 
Tieks said:
If you need to distinguish between different USB devices that produce similar device files, you can use shell scripts as an action.
Click to expand...
Does the operating system really not have enough data to get the parameters of the peripheral device that creates it using the name of the special file?
If I understand correctly, then I need to write some kind of application that will remember the necessary parameters at the previous stage and, at the stage of creating a special file, use this information to adjust actions?

Is this information not available in any other way? Are there really no kernel data structures where all this can be found out in a more logical and reliable way?

By the way, if I understood correctly, first the ugen*.* device will be created, and then, from it, all the special files of the cua* and tty*. What is the point of such a two-step system?
 
ogogon said:
Is this information not available in any other way? Are there really no kernel data structures where all this can be found out in a more logical and reliable way?
Click to expand...
Oh yes, I gave just a simple example. If you have a device unit/address (like ugenN.N, see dmesg), you can use usbconfig to get to vendor and product id's. But that requires a script as well.

Are you sure you need different rights for similar device nodes? I can hardly imagine a valid use case for that.

ogogon said:
What is the point of such a two-step system?
Click to expand...
These are different subsystems meant for different tasks. USB handles hardware. It tries to enumerate a newly plugged in device and tries to read what kind of device it is. It then stops and leaves further handling to another specialized subsystem. You don't need GEOM for a USB mouse or a Playstation controller.
 
Tieks said:
Are you sure you need different rights for similar device nodes? I can hardly imagine a valid use case for that.
Click to expand...
Above I gave an example of such a need. Many devices connected via USB bus form a serial port through which they exchange commands with their software.
But the software is run by different users. A problematic task arises - each such interface must belong to exactly the user from whom the control daemon is running.
I have already given a real example - a number of com ports belong to voice devices and their owner is an Asterisk. And another com port belongs to UPS, and its owner must be NUT.
The most convenient way to differentiate them is by vendor/product combination. So I want to figure out how to do this.
 
That can easily be handled by a common group instead, it doesn't have to be an owner. Here is an example
Code: 
root@kg-core2:~ # cat /usr/local/etc/devd/solaar.conf
# Allows non-root users to have raw access to Logitech Unifying USB
# Receiver devices.

notify 100 {
    match "system" "USB";
    match "subsystem" "DEVICE";
    match "type" "ATTACH";
    match "vendor" "0x046d";
    match "product" "(0xc52b|0xc532|0xc52f|0xc526|0xc52e|0xc51b|0xc531|0xc517|0xc518|0xc51a|0xc521|0xc525|0xc534|0xc539|0xc53a|0xc53f)";
# Please uncomment the line below and change the group name to suit
# your own needs.
    action "chgrp operator /dev/$cdev && chmod 660 /dev/$cdev";
};

notify 100 {
    match "system" "USB";
    match "subsystem" "DEVICE";
    match "type" "ATTACH";
    match "vendor" "0x17ef";
    match "product" "0x6042";
# Please uncomment the line below and change the group name to suit
# your own needs.
    action "chgrp operator /dev/$cdev && chmod 660 /dev/$cdev";
};
As long as the group has read and write permission on the device in question, it works.
 
You probably can change to one of the existing groups (asterisk or nut) in both programs.

The two most common scenarios for unix / FreeBSD / Linux software that needs access to a physical device are:
1) the software just needs access, it doesn't care how it gets access
2) the user and / or group for access is configurable via a config file, command line parameter or similar method

very rarely have I come across software where user name and / or group is hardcoded.
How do you find out? Well both asterisk and nut have documentation, you can read it or search on the internet for answers.
 
I don't think cdev I'd generally defined. Where is that documented? As the author of devd, I'd be surprised if that worked reliably.

Ideally tthese would be in devfs.conf... but the ties between device nodes in /dev and hardware attributes that can be used to influence things is lacking...
 
You must log in or register to reply here.
Back
Top