[pkg-wpa-devel] Bug#487585: Bug#487585: Doesn't associate with wext driver, consider readding madwifi.

[kelmo]

Hi Santiago,

On Monday 23 June 2008 06:39:26 Santiago Garcia Mantinan wrote:
> Package: wpasupplicant
> Version: 0.6.3-2
> Severity: wishlist
> 
> Hi!
> 
> The short story seems to be that an atheros card running madwifi sometimes
> fails to authenticate when using wpasupplicant -D wext, while it always
> works if run with -D madwifi.

My short story is located here:
http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2008-May/001692.html

> 
> The long story is this:
> 
> I have two computers, one runs an old atheros card with an old setup that
> uses -D madwifi, and has been working perfectly doing WPA2 psk
> authentications against my madwifi based AP, that was till I upgraded to
> wpasupplicant 0.6.3-2, when I had to switch it from -D madwifi to -D wext,
> when it started to fail from time to time. When it fails it fails all the
> time and then it is blacklisted for a time on the madwifi AP, so it won't
> authenticate under whatever driver, OS or whatever.
> 
> It was seing this computer fail when using -D wext that I realised that the
> problems I was seing on the other computer (a new computer which has just
> received support from madwifi) which I was thinking were caused by a still
> not good support on madifi, could be caused by the -D wext that I was using
> on this computer.
> 
> So, after changing this new computer from -D wext to -D madwifi (using
> 0.6.3-1) it started working perfectly, like the old computer used to do when
> it was running -D madwifi.
> 
> So... I believe that the -D wext is not working well with the madifi
> drivers, at least on a setup like mine (WPA2 psk which is not weird at all).
> 
> Of course this should be fixed on the madwifi driver, but I was wondering
> how long will it take for the madwifi drivers to address this, and if it is
> the right time at a short time for the release to drop all this
> wpasupplicant drivers, maybe there aren't any problems, but where may be
> problems like this that are found after the release, so... is this a risk we
> want to take with an important package like wpasupplicant?

I've put forward my opinion already, and I'll stand by it. If enough convincing
arguments are put forward by people that the madwifi driver interface (private,
non-standard WPA interface, requiring a copy of source code that must be
synchonised with non-free madwifi source package periodically, without
backwards compatibility guarentee) should be reactivated in the Debian
wpasupplicant package, then another member of pkg-wpa group, or NMU by a
Debian Developer will have to take care of it.

> 
> I can do whatever tests you want on both the computers, but it is quite
> difficult to extract info from just a couple of tests as it only fails
> sometimes, and also because of the blacklisting.
> 
> I'm Ccing the madwifi maintainers to see if they know of similar
> experiences.

I am the incumbent madwifi package maintainer. With that hat on, I can only be
glad to be rid of the burden of ensuring a private WPA interface is in sync and
functional with wpasupplicant and madwifi packages.

Activating and relying on private WPA interface is not going to help fix the
madwifi driver to respect Linux IEEE 802.11 standards in the future. What
happens when the private interface starts to be buggy in future versions of
Madwifi driver, who fixes the bugs and answers the questions then? Nobody.

Another person will be taking over active Madwifi package maintenance
(hopefully) soon.

Thanks, Kel.