Re: NM and ipw3945 once again

[Dan Williams <dcbw redhat com>]

On Tue, 2007-03-13 at 10:28 -0400, Derek Atkins wrote:
> Quoting Dan Williams <dcbw redhat com>:
> 
> > Likely, yes.  Why _is_ the driver sending disconnect events?  Can
> > somebody figure out with plain wpa_supplicant what config options make
> > the driver _not_ send a disconnect event?  If you tell the card to do
> > something, and then it tries and tells you it can't do it, that's an
> > error.
> 
> For the record I've noticed similar issues with Madwifi, so I don't
> think it's SPECIFICALLY a driver bug (although I suppose it could be).
> It seems to happen more often in a multi-AP (roaming) environment.
> I periodically see an "ADDRCONF" link down and then link up message
> in my logs, and NM tears down the connection and then rebuilds it.
> 
> My personal feeling is that these types of messages should just get
> debounced; but I dont know where the debouncing should occur.
> 
> I'll also note that when I just use ifup directly (after I shutdown
> NM) then I don't see these log messages and I don't have disconnect
> events.  But obviously this only works with unsecured networks.  But
> this certainly leads me to believe it's a problem in wpa_supplicant
> and/or NM and NOT a driver bug.

Well, if the driver is sending a disassociation event, then clearly the
driver cannot proceed with the options it's been given.  In the plain
wpa_supplicant case that was noted above, even wpa_supplicant tries once
and doesn't get it, then retries and does get it.  I'm very curious what
causes the driver to think it got disconnected, especially since it
apparently can connect with a second association request with the exact
same options.

If there's driver debugging that can be enabled, that would be quite
helpful.  Or frame capture between the AP and the STA.

Dan