FreeBSD architecture problem

L

loveydovey

On Linux, udevadm issues a trigger on boot so all the "ATTACH" events in rules get triggered on boot.
FreeBSD does not have this.
So you write a devd rule to trigger on USB "ATTACH" event, and it works only if you if you plug something in after you booted. Beautiful.
But if you reboot, the rule is not triggered (USB device attaches before devd is run), so you are forced to add a crontab @reboot to effectuate the rule.
This introduces a several second delay between USB attachment during boot and the rule execution, which is a security issue.
I do not want one of two of a USB device's interface to ever connect to my system, not even for 3 seconds.
Is there a way to mitigate this?
 
You are faster if you put it in /etc/rc.local. To be even faster write a /etc/rc script that is executed earlier.
 
That's almost immediate, thanks. But ideally need it to never connect in the first place. Is this not possible in FreeBSD at all?
 
I don't know enough about devd to answer that.

I am quite sure that Linux leaves it open for a while, too. Linux probes USB devices during kernel load and then again during userland startup. The udev rules are not available during the kernel load, so I estimate that you run the USB device without the desired initialization for the period between the two probes.
 
loveydovey said:
I do not want one of two of a USB device's interface to ever connect to my system, not even for 3 seconds.
Is there a way to mitigate this?
Click to expand...
Are these devices internal/integrated or external? If they are not integrated, have you tried not plugging them in?
 
cracauer@ said:
I don't know enough about devd to answer that.

I am quite sure that Linux leaves it open for a while, too. Linux probes USB devices during kernel load and then again during userland startup. The udev rules are not available during the kernel load, so I estimate that you run the USB device without the desired initialization for the period between the two probes.
Click to expand...
That's actually a possibility, I don't know when Linux hooks those USB devices to a driver during the boot.
 
I've never encountered this problem. I use a MIDIMAN interface that requires a firmware upload on attach:
oOiOo said:
Re: Stuck with devd

I finally found a solution with the notify keyword:
Code: 
# $Id$
# /usr/local/etc/devd/m-audio.conf
options {
        set LOADER "/usr/local/sbin/fxload -I";
        set MAUDIO "/usr/local/share/fxload/m-audio";
};

notify 0 {
        match "system" "USB";
        match "subsystem" "INTERFACE";
        match "type" "ATTACH";
        match "vendor" "0x0763";
        match "product" "0x1010";
        match "release" "0x0001";
        action "$LOADER $MAUDIO/ezusbmidi1x1.ihx -D vid=$vendor,pid=$product";
};
 
notify 0 {
        match "system" "USB";
        match "subsystem" "INTERFACE";
        match "type" "ATTACH";
        match "vendor" "0x0763";
        match "product" "0x1001";
        match "release" "0x0001";
        action "$LOADER $MAUDIO/ezusbmidi2x2.ihx -D vid=$vendor,pid=$product";
};
But it looks strange to me that the first solution doesn't work.
Click to expand...
It works perfectly with this setup without needing to reconnect the interface after startup.
 
oOiOo said:
I've never encountered this problem. I use a MIDIMAN interface that requires a firmware upload on attach:

It works perfectly with this setup without needing to reconnect the interface after startup.
Click to expand...
Well, this is weird now. I used
Rich (BB code): 
notify 100
, but that should make it even higher priority. Again, the rule works when I unplug/plug it back in, but it doesn't work during boot. Can someone with more expertise chime in please?
 
oOiOo said:
Please, post your complete boot log and devd configuration file
Click to expand...
That's okay, thanks, I think we sort of figured it out. And the case with a MIDI device that works with just a devd rule might be due to that device attaching after devd already started.
 
You must log in or register to reply here.
Back
Top