Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#11206 - Madwifi revision 3844 not working

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Wednesday, 13 August 2008, 21:15 GMT
Last edited by Hugo Doria (hdoria) - Saturday, 21 March 2009, 22:43 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Alexander Baldeck (kth5)
Architecture All
Severity High
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Revision 3382 worked fine. The new one has the usual problem again:
http://madwifi.org/wiki/StuckBeacon

With the new version, average uptime is no more than a few hours. Then either a kernel panic occurs, or the interface stops working and all modules need to be re-modprobed.

Of course, hundreds of stuck beacons appear in kernel.log, just as described in the wiki.

Additional info:
* package version(s)
0.9.4.3844-5

* config and/or log files etc.
Not interesting, stuck beacons everywhere.

Steps to reproduce:
Create an access point using hostapd and WPA-PSK. Connect to the access point and wait... Stuck beacons appear approximately every hour. They always appear in groups. A hard failure occurs about twice a day. :-(

This has already been reported many times (in madwifi mailing lists) with no result at all.

Perhaps some older revisions could work, but choosing one is always a shot in the dark.
This task depends upon

Closed by  Hugo Doria (hdoria)
Saturday, 21 March 2009, 22:43 GMT
Reason for closing:  Won't fix
Comment by Erwin Van de Velde (evdvelde) - Thursday, 14 August 2008, 10:41 GMT
iwpriv ath0 bgscan 0

This command fixes the issue for me
Comment by Andrej Podzimek (andrej) - Thursday, 14 August 2008, 13:10 GMT
I tried that one already, together with protmode 0, doth 0, pureg 1 and some other options that seem to reduce the probability of failure. Despite all my attempts to avoid the stuck beacons, the new revision failed to work properly. (Furthermore, Windows suffered from long network blackouts and my VoIP phone could not associate at all.)
Comment by Michal Witkowski (Neuro) - Friday, 15 August 2008, 16:48 GMT
Well, I got a Atheros wifi card myself but I'm running debian. Since they moved past 0.9.4 codebase, my card started to hang.
They reverted to 0.9.4 as it is the last known release which doesn't have my problems.
See the debian madwifi package SVN:
http://svn.debian.org/wsvn/pkg-madwifi/unstable/madwifi/?rev=0&sc=1
Comment by Andrej Podzimek (andrej) - Friday, 15 August 2008, 22:22 GMT
Yes, exactly. The last working version is 0.9.4.3382. When you apply all the strange iwpriv hacks and turn off many of the „advanced“ (in fact non-standard and useless) features of Atheros, it seems to work fine.

Revision 3844 fails, regardless iwpriv settings. Sometimes the connection „only“ hangs and a manual reassociation can help. In many cases, however, server-side maintenance is necessary. Re-modprobing the modules and restarting hostapd every couple of hours is the kind of problem that can kill your productivity.
Comment by Tobias Powalowski (tpowa) - Tuesday, 26 August 2008, 21:15 GMT
does a rebuild of 3844 package help?
Comment by Andrej Podzimek (andrej) - Wednesday, 27 August 2008, 14:07 GMT
I wouldn't report this as a bug if the solution was that simple. ;-) Rebuilding the 3844 package doesn't help. Tested with at least three different versions of hostapd.
Comment by Tobias Powalowski (tpowa) - Thursday, 28 August 2008, 06:56 GMT
does building the latest svn version fix the issue, i tend to step forward then downgrade something.

thanks for reporting, i don't have the hardware
Comment by Andrej Podzimek (andrej) - Sunday, 31 August 2008, 15:29 GMT
Yes, newer versions are better in most cases, but Madwifi is something unusual. I think they spend most of their time and effort working on ath5k and ath_pci is more or less deprecated now. When new bugs emerge, they may never get fixed. Unfortunately, the blackbox-free ath5k driver does *not* have AP mode yet...

Back to your question: AFAIK, the head revision did not work properly about two weeks ago. (Truth to be said, it was even worse than the packaged version.) I did not try it since then. Having subscribed to their mailing list, I can still see some desperate stuck beacon reports.

Perhaps there is no solution at all. Even with the old version, my WiFi AP crashed after abut 15 days of uptime. Nothing serious, but I had to reload all the Madwifi modules to make it work again. Looking forward to AP-enabled ath5k...
Comment by Andrej Podzimek (andrej) - Monday, 01 September 2008, 03:20 GMT
This looks interesting: http://madwifi.org/wiki/news/20080829/new-hal-release-for-atheros-hardware
It is not clear whether it has already been merged with the SVN version.
Comment by Andrej Podzimek (andrej) - Tuesday, 02 September 2008, 18:31 GMT
This is where the new HAL is integrated: http://madwifi.org/browser/madwifi/branches/madwifi-hal-2008-08-15

It might be worth trying. However, the madwifi wiki says it will be merged with trunk sooner or later. AFAIK, the stuck beacon problem should be gone in that branch. Unfortunately, I don't have time and patience to test it.
Comment by Glenn Matthys (RedShift) - Friday, 05 December 2008, 21:16 GMT
What's the status of this issue?
Comment by Andrej Podzimek (andrej) - Friday, 12 December 2008, 21:20 GMT
Gave up and switched to a standalone access point.

Madwifi driver is the worst thing I have ever seen on Linux. It causes memory corruption all the time. Unfortunately, kernel panics occur quite rarely. In most cases, this memory corruption leads either to a total system hang or to an inconsistent state with many zombie processes and blocked filesystems.

The newer the revision, the worse. Tried at least five different revisions compiled against multiple kernel versions, but no luck. (Expecting that a bad software will start to work fine just by accident was too optimistic anyway...)

As you may have noticed, the HAL source code has already been made available. (http://madwifi-project.org/wiki/news/20081129/sam-leffler-releases-hal-source) This happened about one week after I gave up. However, I do not believe that ath_pci will ever become usable.

Will retry all that stuff as soon as ath5k has AP mode. Binary modules (ath_hal) are not even worth trying.

Loading...