On Wed, 13 Jun 2007 09:38:40 am Elmar Hoffmann wrote:
> > Also, this patch has the potential to bing back the "re-association
> > storm" phenomenon that the wpa_hysteresis_{event,check} functions were
> > designed to prevent. This could lead to an uncontrollable loop of failed
> > re-association and failed ifup events.
>
> Hmm yes, this might be an issue with cases other than DHCP (which
> takes a while before it gives up) that fail immediately.
> OTOH in my experience wpasupplicant also takes a while to react to an
> reassociate request (and any normal disconnect and connect events
> inbetween would be covered by the hysteresis), so that loop should not
> be too fast and may not be a problem. I should be able to simulate and
> test that with a broken interface stanza or sth. :)
>
> Still it is (unlike the hysteresis case) quite logical to not stay
> associated to an AP that is not usable as your interface did not
> configure. And while trying over and over again arguably does not help
> in a "one AP with broken DHCP" situation, it sure helps when there are
> more APs wpasupplicant can connect to or when the wireless connection
> is bad enough for DHCP to fail sometimes due to loss of DHCP packets
> but another attempt could work. The latter is the case that made me do
> these changes.
>
> elmar
Is it safe to assume that if wpa_cli reports we have *not* an ip address, that
we would like to reassociate?
If yes, please try this:
Index: wpa_action.sh
===================================================================
--- wpa_action.sh (revision 854)
+++ wpa_action.sh (working copy)
@@ -46,7 +46,12 @@
ifup
fi
wpa_hysteresis_event
- wpa_cli status
+ if wpa_cli status | grep -q '^ip_address='; then
+ wpa_cli status
+ else
+ echo "Status reports no ip_address, asking for
reassociation."
+ wpa_cli reassociate
+ fi
;;
"DISCONNECTED")
Thanks, Kel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
