On Wed, 13 Jun 2007 09:38:40 am Elmar Hoffmann wrote:
> 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. :)Broken drivers are the acid test. broadcom after suspend and madwifi association brokenness are two things that have burnt either myself or others in the past. > > 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. I agree with the logic. However, I'm not going to risk locking up ifupdown or causing system instability because the wifi interface gets stuck in an infinite loop of re-association. It has happened to me before. Sure, I was using a rather experimental driver (madwifi) but please name one linux wifi kernel driver that _always_ does the right thing these days. This is definitely an area that can be improved in this roaming scheme, I just don't know how far these sh scripts should extend themselves when other more comprehensive network management suites are in development . . . Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
