Date: Fri, 20 Jul 2007 23:52:35 +0000 From: Maxim Vetrov <muxas@mail.ru> To: =?UTF-8?B?QmFydMWCb21pZWogUnV0a293c2tp?= <brutkowski@lerkins.com> Cc: freebsd-stable@freebsd.org Subject: Re: Possible devd bug Message-ID: <46A14AC3.4080509@mail.ru> In-Reply-To: <20070720111951.522738441C@stasis01.lerkins.com> References: <20070720093449.630B98441D@stasis01.lerkins.com> <46A127FF.7040507@mail.ru> <20070720111951.522738441C@stasis01.lerkins.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bartłomiej Rutkowski wrote:
> On Fri, 20 Jul 2007 21:24:15 +0000
> Maxim Vetrov <muxas@mail.ru> wrote:
>
>
>> Bart?omiej Rutkowski wrote:
>>
>>> Hi all,
>>>
>>> I have been playing with OpenOspf lately, and I came to a place, when I needed to ensure that an ethernet interface should always go into DOWN state when it loses its link (physically, for example the switch becames turned off). I have tried to hire the devd daemon to do the job with such small definitions:
>>>
>>> notify 100 {
>>> match "system" "IFNET";
>>> match "type" "LINK_DOWN";
>>> media-type "ethernet";
>>> action "/sbin/ifconfig $subsystem down";
>>> };
>>>
>>> notify 200 {
>>> match "system" "IFNET";
>>> match "type" "LINK_UP";
>>> media-type "ethernet";
>>> action "/sbin/ifconfig $subsystem up";
>>> };
>>>
>>> And what is happening? Well, basically, when the interface detects that eth cable has been detached, devd triggers and makes it DOWN, which is ok. But, when the card got the cable attached once again (and interface detects the media type and gets ACTIVE state) devd never triggers the second rule, which should get the interface UP again.
>>> I have tried that with replacing action statements with ones with proper logging actions, and when interface is UP devd gets the proper state changes information.
>>>
>>> Now the question is: why devd doesent receive any information from interfaces in DOWN state? Is that proper behaviour, or a bug? Thanks for any reply, and for your attention.
>>>
>>> P.S. I am resending this message to freebsd-stable list, as I am not sure if freebsd-questions was a proper choice.
>>>
>>>
>>>
>> Probably, there is another notify which action is executed before yours
>> :-) Devd stops scanning sections on the _first_ matched one. Run devd in
>> debug mode and watch
>>
>> Regards,
>> Muxas
>>
>
> I did my tests with debugging and logger in action directives and now I can confirm that
> devd does not trigger, when you put eth interface into DOWN state by "#ifconfig ifnameX down".
> Now, is that intentional behaviour or a bug? This makes those LINK_UP devd triggers
> totally unusable.
> You can test this behaviour with such example ruleset: http://rafb.net/p/gTm9CW93.html
>
>
>
First of all, I can confirm that plugging and unplugging lan cable fires
corresponding devd trigger actions. I checked this by plugging and
unplugging cable :-) Look at /etc/devd.conf; this section is responsible
for bringing link up:
>># Try to start dhclient on Ethernet like interfaces when the link comes
>># up. Only devices that are configured to support DHCP will actually
>># run it. No link down rule exists because dhclient automaticly exits
>># when the link goes down.
>>#
>>notify 0 {
>> match "system" "IFNET";
>> match "type" "LINK_UP";
>> media-type "ethernet";
>> action "/etc/rc.d/dhclient start $subsystem";
>>};
And, IMHO, second, because "...devctl hooks in at such a low level of
FreeBSD's NEWBUS system..." [exerpt from "devd - A device confguration
daemon" by W. Losh] it does not react to "soft" actions. In other
words, I think, ifconfig commands do not generate hardware events. The
article is acessible via
http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/losh.html.
And about http://rafb.net/p/gTm9CW93.html.
1. There is no system mentioned
2. Read the above article about section weights
Regards,
Muxas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46A14AC3.4080509>