I have spent a significant amount of time dealing with issues between MadWifi and wext/wpasupplicant/NetworkManager on Debian (etch, lenny, AND sid).  As it stands, there are still significant issues - in factI cannot associate *at all* to my stock, unencrypted WRT54G using NetworkManager+madwifi on my Atheros 5424 card (bundled with MacBook Core Duo). This is about as standard of a configuration as you can get, so it's obviously a widespread bug.
<br><br>I have managed to isolate the issue to a degree.&nbsp; Though I&#39;m somewhat C-impaired, the issue does seem to stem from issues w/wext compliance - and in particular AP scanning and the &quot;preempt_scan&quot; function.&nbsp; This seems to be a long-standing issue, and has existed in every build of madwifi I&#39;ve tried.&nbsp; The upstream bug mentioned earlier in this thread is still open, and there appears to be no progress whatsoever on that front.
<br><br>Anyway, there is currently two workarounds that I&#39;ve tested and know to work.&nbsp; The first, and the one used by Ubuntu, is to change NetworkManager&#39;s source such that the wpasupplicant&#39;s &quot;madwifi&quot; driver is used for cards using madwifi instead of the generic &quot;wext&quot; driver.&nbsp; This seems to work well, though the Debian maintainer for NetworkManager didn&#39;t like the idea of special behavior for madwifi.&nbsp; Secondly, there is the option of totally removing the preempt_scan() function and all calls to it from ieee80211_wireless.c.&nbsp; This seems to work perfectly to me, but may come at the loss of some functionality (namely, wireless scan timeout).&nbsp; This function was only added in the last 6-9 months, though, so the driver is known to work without it.
<br><br>I&#39;ve attached my patch to remove the function in question (preempt_scan) from ieee80211.c. I&#39;ve attached patches to both the release used in unstable and the trunk from <a href="http://madwifi.org">madwifi.org
</a> (which, in my experience, blows away the release in wireless performance - in addition to adding support for the Atheros 802.11n chipsets).<br><br>I hope a workaround such as the one(s) I&#39;ve suggested can be uploaded to the archive - this can be quite a nasty bug for some Atheros users...
<br>