Bug 42504 and 46136 are the same bug. (but not marked as duplicate for historical / versioning reasons) Since you keep making casual reads as opposed to understand the problem, let me describe it here in detail to resolve your curiousity:
In dapper, the version of ndiswrapper is only partially compatible with wpasupplicant. Therefore, only _some_ ndiswrapper setups work well with the ndiswrapper-specific wpasupplicant work-around that is actually selected by NM. The remaining setups continue breaking. Therefore, using ndiswrapper with NM (and wpasupplicant) in dapper is a inconsistent situation and a lot of people solved the issue by either rolling back, or reverting the workaround. In edgy, the version of ndiswrapper is much newer. It is fully compatible with wpasupplicant running in its normal mode of using wireless extensions. However, the dapper workaround patch to NM that calls wpasupplicant with the alternate driver is still in the package. Therefore, out of the box, NM (not wpasupplicant) is broken on edgy with ndiswrapper. wpasupplicant works fine, but NM is instructing it to run in a historical method. Perhaps that helps explains the issue? This bug is, of course, totally different than the ones occurring in this bug. In this situation, the drivers themselves simply do not work with wpasupplicant in wireless extensions mode at all. My plain is to start a hardware database on the wiki for working NetworkManager configurations once the ndiswrapper patch removal is approved by main sponsors. (Thereby being able to close out several bugs.) -- Some drivers do not work with wpasupplicant, and therefore NM. https://launchpad.net/bugs/48473 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
