NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/38341: ifwatchd misses pppoe0 up event in -current after changes on March 26/27th
>Number: 38341
>Category: kern
>Synopsis: ifwatchd misses pppoe0 up event in -current after changes on
>March 26/27th
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Mar 30 09:15:00 +0000 2008
>Originator: Markus W Kilbinger
>Release: NetBSD 4.99.58
>Organization:
net
>Environment:
System: NetBSD qube 4.99.58 NetBSD 4.99.58 (QUBE) #86: Sun Mar 30 08:00:57 MEST
2008
Architecture: mipsel
Machine: cobalt
>Description:
After -current changes on March 26/27th kernels timing/signal
behavior of my cobalt qube2's pppoe0 interface for ifwatchd
changed.
Formerly a simple/final
inet 0.0.0.0 0.0.0.1 up
in /etc/ifconfig.pppoe0 produced a
/usr/sbin/ifwatchd[131]: calling: /etc/ppp/ip-up pppoe0 ...
call later on.
Now, with the same config, pppoe0's associating with my isp no
longer produces an ifwatchd calling if ifwatchd is started
before this association successfully happened.
I can workaround this problem by appending
!/bin/sleep 4
at the end of/etc/ifconfig.pppoe0, so that the event
pppoe0: connected to XXXXXX
happens _before_ /etc/rc.d/ifwatchd is started.
Otherwise, ifwatchd is missing / not receiving pppoe0's up
event.
>How-To-Repeat:
Problem now seems that ifwatchd no longer receives an up event
signal if pppoe (and other?) devices are not already
'associated/connected' on their lower layer.
-> Start ifwatchd _before_ e. g. pppoe0 associates and observe
that it is not receving an up event when pppoe0 associates
afterwards.
>Fix:
Unknown
Workaround: Delay starting of ifwatchd until the relevant
devices are already sucessfully associated/connected.
Home |
Main Index |
Thread Index |
Old Index