Bug#487585: [pkg-wpa-devel] Bug#487585: Bug#487585: Bug#487585: Doesn't associate with wext driver, consider readding madwifi.
Matthew \mentor\ Bell [EMAIL PROTECTED] writes: On Wed, 2008-06-25 at 22:07 +0800, Glenn Saberton wrote: I think it would be beneficial to all if the people that are experiencing problems with the current debian madwifi package with the current wpasupplicant package, that they would actually supply some debug info to the relevant upstream so it could be fixed there rather than continue down a deprecated path. As a reasonably long time user of both madwifi and wpasupplicant with several atheros chips and no problems using wext, I think it would be more useful to find the cause of the problem than revert to using code that no-one wants to support. Yeah, I'd like this too. Cool, great to hear. you probably already know how the pkg-wpa team works. We have a team svn where we maintain the wpasupplicant and hostap package. I'd suggest that you checkout these branches, work on them and attach 'svn diff's to the relevant bugs in debbugs, which I'll review and apply. If you have further questions, feel free to ask either me directly or on [EMAIL PROTECTED], the mailing list where we are coordinating and discussing things. You should subscribe there as well. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487585: [pkg-wpa-devel] Bug#487585: Bug#487585: Bug#487585: Doesn't associate with wext driver, consider readding madwifi.
On Wed, 2008-06-25 at 22:07 +0800, Glenn Saberton wrote: I think it would be beneficial to all if the people that are experiencing problems with the current debian madwifi package with the current wpasupplicant package, that they would actually supply some debug info to the relevant upstream so it could be fixed there rather than continue down a deprecated path. As a reasonably long time user of both madwifi and wpasupplicant with several atheros chips and no problems using wext, I think it would be more useful to find the cause of the problem than revert to using code that no-one wants to support. Yeah, I'd like this too. Matthew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487585: [pkg-wpa-devel] Bug#487585: Bug#487585: Doesn't associate with wext driver, consider readding madwifi.
tag 487585 help stop kelmo [EMAIL PROTECTED] writes: 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. So let's make the following requirement: In order to get the madwifi headers included back, we need new manpower in the pkg-wpa team. That person should commit to keep the header up-to-date in svn and help with general maintenance of the package. If such a person shows up and does the work, fine. If not, this bug stays openas call for help for someone to fix it. We, the current wpasupplicant maintainers have no interest in maintaining the header copy. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487585: [pkg-wpa-devel] Bug#487585: Bug#487585: Bug#487585: Doesn't associate with wext driver, consider readding madwifi.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Tartler wrote: tag 487585 help stop kelmo [EMAIL PROTECTED] writes: 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. So let's make the following requirement: In order to get the madwifi headers included back, we need new manpower in the pkg-wpa team. That person should commit to keep the header up-to-date in svn and help with general maintenance of the package. If such a person shows up and does the work, fine. If not, this bug stays openas call for help for someone to fix it. We, the current wpasupplicant maintainers have no interest in maintaining the header copy. I think it would be beneficial to all if the people that are experiencing problems with the current debian madwifi package with the current wpasupplicant package, that they would actually supply some debug info to the relevant upstream so it could be fixed there rather than continue down a deprecated path. As a reasonably long time user of both madwifi and wpasupplicant with several atheros chips and no problems using wext, I think it would be more useful to find the cause of the problem than revert to using code that no-one wants to support. /my two cents Cheers Glenn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhiUTAACgkQV8GyuTwyskMqvQCeJZRPEITaMNy9IXMqLgtIix44 AikAnjATwdiMDq6agAUYqw0nFo285WCt =6ux+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487585: [pkg-wpa-devel] Bug#487585: Doesn't associate with wext driver, consider readding madwifi.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487585: Doesn't associate with wext driver, consider readding madwifi.
I have the same problem . So I fully agree with Santiago Garcia Mantinan that madwifi driver should be enabled in wpa_supplicant. Regards Maciek Kaliszewski -- Sprawdz, czy jestes lepszy, niz Leo! kliknij http://link.interia.pl/f1e2f -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487585: Doesn't associate with wext driver, consider readding madwifi.
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. 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 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. Regards... -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25 Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages wpasupplicant depends on: ii adduser 3.108 add and remove users and groups ii libc62.7-10 GNU C Library: Shared libraries ii libdbus-1-3 1.2.1-2 simple interprocess messaging syst ii libpcsclite1 1.4.101-2 Middleware to access a smart card ii libreadline5 5.2-3 GNU readline and history libraries ii libssl0.9.8 0.9.8g-10.1 SSL shared libraries ii lsb-base 3.2-12 Linux Standard Base 3.2 init scrip wpasupplicant recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
