On Tue, Apr 18, 2006 at 08:34:09PM +0200, Felix Homann wrote:
> After further investigaion I found that the described behaviour has a
> major effect on ifup and zeroconf as well. I therefore rename the bug
> and increase its severity.
Thanks for trying to clarify, but please provide the requested
information I asked you before.
> Here's what happens.
>
> 1. Effect on ifup
> =========
>
> Bring the interface up once, then ifdown it.
With or without successful association?
> Subsequent ifups will be successful even if they should fail (if e.g.
> the AP is unreachable or you turned your radio off). ifconfig will
> show the interface as configured with the old IP.
This is due to design limitations of ifupdown and the Linux kernel.
ifupdown will bring the interface up regardless if it was able to
configure the interface or not. I don't know of any concept in ifupdown
to detect if 'bringing the interface up' has failed.
In (at least recent) linux kernels, the interface does not loose the
associated ip. If you want to get all ip's off, you have to do a
`ip addr flush dev wlan` (or reload the device driver module).
Whats the exact problem with this behavior?
> 2. Effect on zeroconf
> =============
>
> If you configure zeroconf to be used as fallback only it will only allocate a
> Link Local address
> if there isn't already an IP address in the global scope:
>
> ---------------------------------------------
> # From /etc/network/if-up.d/zeroconf:
> # should we only allocate an address if we do not already have one?
> if [ -n "$FALLBACK" ]; then
> /bin/ip addr show $IFACE scope global | grep -q "inet"
> IP=$?
> if [ $IP -eq 0 ]; then
> /bin/ip route add 169.254.0.0/16 dev $IFACE
> exit 0
> fi
> fi
> ---------------------------------------------
>
> If the interface isn't brought down correctly zeroconf will never allocate a
> LL address.
This sounds to me that ifupdown should always do a
'ip addr flush dev $IFACE' on ifup. Would this fix your problem?
As a workaround, I'd suggest adding this command to
/etc/wpa_supplicant/ifupdown.sh. Could you please try that and tell me
if this fixes your problems?
Thinking about this longer (you bring me on great ideas ;), I think that
we could/should do a run-parts on /etc/network/if-{up,down}.d/ in the
example action script. Consider that you run openvpn from there. When
you roam from one location to another, you probably want to have it
restarted. I suspect that there are other services expecting to be
restarted on connection to a new location.
There are 2 problems with this approach however. First, ifupdown calls
scripts from there itself, and I'm not aware of any way to make it stop
that. The script would have to check if ifupdown will call those
scripts, and then don't call it at this point. Ugly, but possible.
The other problem is that those scripts expect evironment
variables from ifupdown. Therefore the action script would have to
restore the environment from the initial ifup run. Again, somewhat ugly,
but possible.
Gruesse,
Reinhard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
