Quote:
Originally Posted by hanzer
This method seems to work quite well.
|
Well, not quite. After the first
wpi0.link.down event, the state hangs in
if_offline. The latest variation of my
/etc/ifstated.conf is:
Code:
state alive {
if wpi0.link.down || wpi0.link.unknown {
set-state dead
}
}
state dead {
init {
run "ifconfig wpi0 down"
run "ifconfig wpi0 up"
run "sleep 6"
}
if wpi0.link.up {
set-state alive
}
if wpi0.link.down || wpi0.link.unknown {
set-state purgatory
}
}
state purgatory {
init {
run "sh /etc/netstart wpi0"
run "sleep 66"
}
set-state alive
}
If tested with
$ sudo ifstated -dvv
then in a separate terminal
$ sudo ifconfig wpi0 down
, the results are:
Code:
initial state: alive
changing state to alive
started
changing state to dead
running ifconfig wpi0 down
running ifconfig wpi0 up
running sleep 6
changing state to purgatory
running sh /etc/netstart wpi0
DHCPREQUEST on wpi0 to 255.255.255.255
DHCPACK from 192.168.48.1 (00:90:fb:43:57:51)
bound to 192.168.49.63 -- renewal in 21600 seconds.
running sleep 66
changing state to alive
changing state to dead
running ifconfig wpi0 down
running ifconfig wpi0 up
running sleep 6
changing state to purgatory
running sh /etc/netstart wpi0
DHCPREQUEST on wpi0 to 255.255.255.255
DHCPACK from 192.168.48.1 (00:90:fb:43:57:51)
bound to 192.168.49.63 -- renewal in 21600 seconds.
running sleep 66
And that oscillation continues. During all of this,
$ ifconfig wpi0
indicates that the interface is
UP,
RUNNING and
active.
My current speculation is that the way
ifstated monitors link state (e.g.,
wpi0.link.up) isn't really working for this hinky interface (driver/firmware/hardware).