On Tue, 2007-03-13 at 10:28 -0400, Derek Atkins wrote: > Quoting Dan Williams <[EMAIL PROTECTED]>: > > > 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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
