Hi Kel, on Mon, Jun 11, 2007 at 12:27:43 +1000, you wrote:
> Could the patch use the return value of ifup rather than grep'ing the ifstate
> file?
I'm quite sure my first attempt at this did do the former, but that
did not work, IIRC (its been at 1.5 months since I did this). I'm
going check whether this is true and were the problem lies, if so.
> 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
--
.'"`. /"\
| :' : Elmar Hoffmann <[EMAIL PROTECTED]> ASCII Ribbon Campaign \ /
`. `' GPG key available via pgp.net against HTML email X
`- & vCards / \
signature.asc
Description: Digital signature
