Patch for AR2425 (AR5007EG) chipset

Attachment viewing is slow due to size of the patch. Use following link to save patch directly on your disk.

madwifi.org/attachment/ticket/1679/madwifi-ng-0933.ar2425.20071130.i386.patch?format=raw

Note, if you use the snapshot instead of .9.3.3 the patch will apply cleanly.

snapshots.madwifi.org/madwifi-ng/madwifi-ng-r2756-20071018.tar.gz

This is working beautifully on a ASUS EEE. Thank you atheros and madwifi :).

Unfortunately this patch cannot be committed to madwifi, since it breaks the ABI for all non-i386 HAL binaries.

Replying to madwifi@atheros.com:

Attachment viewing is slow due to size of the patch. Use following link to save patch directly on your disk. madwifi.org/attachment/ticket/1679/madwifi-ng-0933.ar2425.20071130.i386.patch?format=raw

can you give us patch for non i386 system ?

sec_ from #madwifi@irc.freenode.net confirmed that this patch can be used on i686 so, if you feel brave enough you can try and patch the madwifi source code.

i386 mean - all 32bit Intel and AMD x86 systems - from pentium 386 to core duo etc.

I don't give a fuck if the patch submitter has @atheros contained in name, is this the kind of patch we should be providing on our ticket system? A patch to a uuencoded binary?

I own a Samsung R-20 X-002 machine with

05:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01)

wifi device.

Using this patch and latest SVN code (snapshot taken on 20071201 ~23.00 GMT+2) didn't help to get it working.

Still no wifi0 and ath0 device after modprobing all the necessary ath_* modules.

Abit Airpace has the exact same PCI ID and chipset, so this patch might help it also (ref ticket #1255). But I'd still appreciate a patch for all platforms. I have airpace in an AMD64 machine.

This patch is for 32-bits x86 platforms including i686 and AMD CPUs (Thanks strasak!). This patch does not work for 64-bits x86 platforms.

This patch is for the Madwifi driver snapshot r2756 only. Sorry about the wrong information in the original posting.

To apply the patch

1. Download the Madwifi driver snapshot r2756 using the following link and save the file.

snapshots.madwifi.org/madwifi-ng/madwifi-ng-r2756-20071018.tar.gz

2. Extract this driver source and change into the driver directory.

prompt> tar -xvzf madwifi-ng-r2756-20071018.tar.gz
prompt> cd madwifi-ng-r2756-20071018/

3. Download the patch using the following link and save the file.

madwifi.org/attachment/ticket/1679/madwifi-ng-0933.ar2425.20071130.i386.patch?format=raw

4. Patch the Madwifi driver.

prompt> patch -p0 < madwifi-ng-0933.ar2425.20071130.i386.patch

5. Make and install this updated driver according the instructions in the "INSTALL" file from the madwifi package.

I tested the patch file with svn version r2992 in Fedora 8. It work, but just want to inform that I have to blacklist ath5k module.

Hi,

Sorry to be the party pooper, but I am removing the patch from this ticket until we know the origin of it, and the patch submitter has contacted the developers of this project to co-ordinate the availability of this new code for public consumption.

Scott Raynel has attempted to contact the two mail addresses from Atheros on this ticket in order to receive more information about the situation.

It is, in our opinion, not very responsible to allow an unknown blob to be made available like this. We have no way of knowing what this blob does, and we never will, because its not transparent. But we do _need_ to be informed by the blob vendor what changes it brings.

Hope for understanding.

Replying to kelmo:

It is, in our opinion, not very responsible to allow an unknown blob to be made available like this. We have no way of knowing what this blob does, and we never will, because its not transparent. But we do _need_ to be informed by the blob vendor what changes it brings.

Not only that. If we apply patches to the HAL blob we got from our original HAL upstream, we divert from it and make it harder (if not impossible) to incorporate future updates from upstream (read: Sam). It's a similar issue as with the question of whether or not we should try to incorporate the HAL that comes with Asus' variant of MadWifi.

Bottom line: I second the objections to this practice. The only way to get AR5007 support into MadWifi is to make sure that our HAL upstream implements support for these chipsets in his sources and provides us with a updated binary.

It seems unnecessary to actually remove the patch -- especially since it's known to help in certain cases. Could the patch not stay up, but have a gigantic warning across it? Those of us who can legally use it and able too would appreciate a working system in the meantime until the proper fix surfaces.

Replying to genneth _at_ gmail.com:

It seems unnecessary to actually remove the patch... Could the patch not stay up...

The origin of the patch in question was doubtful, it didn't came through the channels we usually receive HAL updates from. The fact that the patch removes Sam's copyright notices from the patched files didn't help to make it look less suspicious.

In the past we had several incidents where users attached leaked HAL sources or other work that made use of illegally distributed files. Since we are responsible for stuff that is offered for download from our server and thus could probably be called to account for the distribution of "illegal files" it was necessary to remove the file. A big fat warning across the file obviously wouldn't have helped us if it turned out that the stuff was not kosher.

We have received feedback from other users stating that the removal of the file seems to them like an over-reaction. I hope the above helps to understand our rationales. We certainly would love to see AR5007 support in MadWifi rather sooner than later, but we have to make sure that this is done "the right way", without exposing ourselves to yet another series of claims about copyright infringements and thelike (even more now that we are working hard on ath5k). This should also be in the best interest of the users of our drivers, even if it means that AR5007 support gets delayed.

Last but not least: meanwhile it was approved that the patch was contributed by Atheros. We are currently talking to them about how to proceed in order to get AR5007 support into MadWifi properly (means: not just for i386, but for all platforms, to prevent ABI breakage). Please stay tuned, we will keep you updated.

The patch works for me =) Thanks a lot madwifi team.

The only "problem" is in injection. In injection test works great, but when i try to send packets i got no luck :(

Any suggestion?

This ticket isn't about injection.

After discussion with Madwifi team (Scott Raynel), the 32-bits x86 HAL attachment has been resubmitted. The attachment now has the appropriate copyright notice included.

Please follow instructions according to the comment:11

Please note that support issues are handled through our regular support channels.

And: yay!

don't work in backtrack2, originally the device is unknown and after patching madwifi..idem:(

Replying to anakin:

don't work in backtrack2, originally the device is unknown and after patching madwifi..idem:( hal status 3

Well, I tried the r2756 with the patch above cleanly applied. Followed the INSTALL instructions. Checked that the lspci -d 168c:001c indeed gives the correct device. uname -i reports GenuineIntel? This is with the official 2.6.23-gentoo-r3 kernel on 32bit Gentoo running on Core2 Duo.

Alas - same result as anakin (hal status 3).

hal status 3 here also.

Are we better off waiting for support in ath5k? Would this be far away?

Replying to anonymous:

hal status 3 here also. Are we better off waiting for support in ath5k? Would this be far away?

yes we would, but this patch is a helpful in terms of reverse engineering ...

Replying to anonymous:

Well, I tried the r2756 with the patch above cleanly applied. Followed the INSTALL instructions. Checked that the lspci -d 168c:001c indeed gives the correct device. uname -i reports GenuineIntel? This is with the official 2.6.23-gentoo-r3 kernel on 32bit Gentoo running on Core2 Duo. Alas - same result as anakin (hal status 3).

Update: got it working after thoroughly cleaning up previous modules and rebooting.

I tried installing by downloading (1) and applying patch (2) to the source as specified in the description of the bug.

The driver loads up (by calling "modprobe ath_pci"), and then an interface 'wlan0' and an interface 'wifi0' are created. However, no AP are discovered.

Any idea how can I find out what's wrong? Do you want me to send the log.

One interesting fact is that this is the second laptop I have with this wireless card, both laptops are of the same model. The first one I configured wireless with ndiswrapper, this one I cannot get it to work neither with ndiswrapper nor with madwifi.

(1) snapshots.madwifi.org/madwifi-ng/madwifi-ng-r2756-20071018.tar.gz

(2) madwifi.org/attachment/ticket/1679/madwifi-ng-0933.ar2425.20071130.i386.patch?format=raw

I'm trying to use kismet, but no AP discovers. running on Atheros AR5BXB63 + suse 10.3

has anybody any idea why?

Since it is official, is there any hope for us 64-bit users to ditch ndiswrapper?

the patch does some manual hex patching of the files so maybe you should use the r2756 release as instructed.

I tested with that release and it works!

It should not matter, binary part of patch is for HAL and it is the same in 2756 and all more recent revisions at least. Here it works for example on madwifi-dfs branch.

A readily patched snapshot (means: a snapshot of r2756 plus the patch that adds AR5007 support to the i386 HAL) is now available for download.

Please, help to reduce the noise in this ticket and move all your support questions to our regular support channels. Thanks.

Right, I've had to clear out the ticket. Again. Some of you clearly have issues following instructions, which does not bode well for your ability to use this patch, but it definitely does not bode well for your continued use of the ticket.

This is not a general support forum for the use of this patch, and it is definitely not a soap box. This ticket should be used for concise, general, and non-redundant information, not discussion. If in doubt, DO NOT POST.

For clarity, as I sometimes doubt there is, MadWiFi is an entirely separate entity to Atheros, which is none of: the owner, beneficial owner, nominee, trustee or any related or unrelated concept of ownership.

The wifi works great on my computer (Toshiba U305 - Gutsy Gibbon). However, it seems to have a bad interaction with the suspend to ram system. As the kernel in gutsy doesn't suspend properly on the toshiba, I am using the 2.6.24-2.4 kernel from Hardy which does suspend properly when the modules are not loaded. When they are loaded, attempting to suspend the computer kills the wifi connection and the computer is never suspended. The computer also fails to shutdown properly after a failed attempt to suspend it.

I believe the suspend to ram issues are related to the ATI drivers memory leak. Fixed in the latest release of the drivers from last Thursday.

When will/has this patch been incorporated into the version of MadWifi I can download from madwifi.org? I know I can get the patch and apply it myself (and get the kindly provided prepatched version!) but I'm just curious as to when I won't have to do that on a fresh install. Thanks.

Replying to anonymous:

When will/has this patch been incorporated into the version of MadWifi I can download from madwifi.org?

You obviously missed comment 55. However, if you are asking about when a new HAL version with AR5007 support will be available in a MadWifi release, the answer is: as soon as it's ready. Negotiations with Atheros in this regard are still in progress.

Replying to mrenzmann:

However, if you are asking about when a new HAL version with AR5007 support will be available in a MadWifi release, the answer is: as soon as it's ready. Negotiations with Atheros in this regard are still in progress.

Can you say by your experience how much time may it take? Will be a 64-bit version of the hal available during one-two monthes or it is better to me to sell my laptop?

Replying to anonymous:

Can you say by your experience how much time may it take?

Unfortunately not, sorry.

NB: rather than selling your laptop you could also replace your AR5007EG card by one that is based on the AR5006EG chipset.

madwifi-trace trace on Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c]

the trace was taken on :

02:00.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01)

Subsystem: AMBIT Microsystem Corp. Unknown device [1468:0428] Flags: fast devsel, IRQ 17 Memory at 8c000000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint IRQ 0 Capabilities: [90] MSI-X: Enable- Mask- TabSize?=1 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel

I wouldn't mind using a limited feature temporary fix, if it could be done in a short timeframe, as long as it has support for 64bit OSes which some people must use. Seing as this bug has been going on for months I must ask, should I buy a new card, or should we wait?

Replying to Need64bitSupport:

should I buy a new card, or should we wait?

See comment 60 and comment 62.

this patched driver does not work with IEEE 802.1X with Dynamic WEP Keys using EAP-PEAP/MSCHAPv2

using a recompiled wpa_supplicant v0.6.2 against this patched driver?

The hardware is

mini-pci AR5007EG eee asus pc

Any Ideas?

DMESG dump from kernel 2.6.24.

Compiled this against 2.6.24 (not expecting it to work) however it does! Have attached a dmesg dump - just finding out if Atheros are being vocal about 5007 details - so that in an ideal work the 0.9.4 release would have support.

Please stop posting support requests to this already crowded ticket. They are expected to be carried to our regular support channels! All off-topic comments will be deleted from now on without further notice.

After some trouble initially manually patching a newer release, I uninstalled all madwifi builds and used the prepatched snapshot in the ticket description which worked perfectly with no issues (bye bye old cisco PCMCIA card :D :D). Please note that as explained in the ticket the ath5k module (if installed - it is on Fedora 8 and newer kernels I believe) needs to be blacklisted. Simply add blacklist ath5k to /etc/modprobe.conf

I do however have a question which I hope is classed as being in scope for this ticket (as per mrenzmann's coment above!) - can this patch be used with the latest snapshot and would there be any point in doing so? If so, would someone be able to create a prepatched version? I'd try it but after the trouble I have had I don't want to risk killing my config unless its worked for other people first!

Thanks.

Added a new patch to remove dmesg errors in kernels 2.6.24+ - just copied the relevant changes from your existing changesets (searched for 2.6.24 in changesets). NOTE: Changesets 2814/5 add a trailing comma to the last parameter which causes and issue when you run patch-kernel/install.sh - the kernel fails to compile (using an ASUS eee with their Xandros 4 derivitive and GCC 4.1.2). Now to try the same with the power saving patches - keep up the good work!

From our IRC support channel:

12:45:52 < Tyczek> Just wanted to report that patch for atheros 5007 EG works with toshiba satellite a210-16f (it was reported as 5006 EG) :)

It works in a Toshiba A200 1NH with 2.6.23 kernel (Debian SID) with a 2.6.24-2 it doesn't compile (Debian SID)

Migatxu - I've successfully compiled and used this (with the 2.6.24 patch) on kernel version 2.6.24.2.

Omit the madwifi/ath/if_ath.c file from the patch as it is the packet injection part from aireplay-ng's patchset (my bad).

Sorry, I had to remove the patch, since it deleted the copyright notice from the patched HAL binary. We've been through that before.

It work great in my toshiba u305. I was downloading the stable version, but get "HAL error 13".

But this patch work very nice. Just download this patch, then run make, make install. And restart ubuntu. That's it. It should be able to detect any AP.

Thanks!

Note that neither the patch nor the prepatched snapshot tarball compile against kernel 2.6.24. This is a known issue, so no need to report this here. As soon as an update is available, it will be announced here.

Hi, mine is asus eeepc. I've seen weird thing with atheros by using madwifi version here. My pci id for atheros showed in 'lspci -n' is 168c:ff1b, which seems obviously wrong. And only once, when I boot up, r2756 ath_pci load correctly and my wifi got working, then pci id is 168c:001c, which is correct. I tried to reboot again, wifi failed to work again with weird ff1b ids. I also reset bios and enable wlan option, no help.

Is this issue known? any clue? thanks.

Replying to mrenzmann:

Note that neither the patch nor the prepatched snapshot tarball compile against kernel 2.6.24. This is a known issue, so no need to report this here. As soon as an update is available, it will be announced here.

I haven't found this to be the case. It's compiled and installed without problem for me in in Fedora's Rawhide, running various versions of 2.6.24 and 2.6.25. (However, an update tonight, to their kernel 2.6.25-0.54.rc2.fc9 doesn't work with it. It compiles and installs, but doing modprobe ath_pci hangs the system.)

The one I had before that, 2.25-0.48.rc1.git2.fc9 worked without problem.

It's also worked without issue in the Ubuntu alphas, 2.6.24.5-generic and 2.6.24-8.generic.

Lastly, it's worked without issue in Arch, kernel 2.6.24-ARCH.

Replying to anonymous:

Replying to mrenzmann:

Note that neither the patch nor the prepatched snapshot tarball compile against kernel 2.6.24. This is a known issue, so no need to report this here. As soon as an update is available, it will be announced here.

I haven't found this to be the case. It's compiled and installed without problem for me in in Fedora's Rawhide, running various versions of 2.6.24 and 2.6.25. (However, an update tonight, to their kernel 2.6.25-0.54.rc2.fc9 doesn't work with it. It compiles and installs, but doing modprobe ath_pci hangs the system.) The one I had before that, 2.25-0.48.rc1.git2.fc9 worked without problem. It's also worked without issue in the Ubuntu alphas, 2.6.24.5-generic and 2.6.24-8.generic. Lastly, it's worked without issue in Arch, kernel 2.6.24-ARCH.

To add to this, the next day's Fedora update, to 2.6.25-0.64.rc2.git5.fc9 works again.

The patch couldn't be cleanly applied to 0.9.4, however the tarball compiled and worked fine. I'm using an acer 5050-3785 with the AR5BXB63 card. I'm using the linux 2.6.24 kernel, and have 64-bit support enabled (Processor type and features -> 64 bit Memory and IO resources). Also, this tarball seems to include injection support (which is awesome) for those who were wondering.

I did, however, get a lot of stacktraces in the logs from dmesg.

sysctl table check failed: /net/ath0/monitor_phy_errors .3.-2.-2 Unknown sysctl binary path
...
sysctl table check failed: /net/ath0/monitor_crc_errors .3.-2.-2 Missing strategy
...
sysctl table check failed: /net/ath0/monitor_crc_errors .3.-2.-2 Unknown sysctl binary path
...
sysctl table check failed: /net/ath0/%parent .3.-2.-2 Missing strategy
...
sysctl table check failed: /net/ath0/%parent .3.-2.-2 Unknown sysctl binary path
...
ath0: failed to register sysctls!
wifi0: Atheros 5424/2424: mem=0xb0200000, irq=11
sysctl table check failed: /dev/ath .7.9 Unknown sysctl binary path
...

If anyone is concerned with the above error message, you'll probably was to know this: grep -i sysctl /usr/src/linux-2.6.24/.config

CONFIG_SYSVIPC_SYSCTL=y
CONFIG_SYSCTL=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_PROC_SYSCTL=y

Personally, I'm not worried about the error messages; the card works, and that's what's most important to me. Thanks for your hard work guys! If you think the errors are worth tracking down, e-mail me and I'll get you whatever information you need.

thank you

Does this work for the Atheros AR5007-AP edition? (using an asus M3A32-MVP Deluxe/+Wifi)

I'm not really sure where this goes, but after a lot of trial and error with other posts, I got the patched version working with my Compaq Presario f750US, Fedora Core 7-i386. As mentioned before lspci listed my card as AR5006EG.

Replying to anonymous:

I'm not really sure where this goes, but after a lot of trial and error with other posts, I got the patched version working with my Compaq Presario f750US, Fedora Core 7-i386. As mentioned before lspci listed my card as AR5006EG.

Sorry as a followup: This worked before I installed the nvidia driver, but failed after words. I think it had to do with the new kernel. I had to make a symlink for the new /build file for the new kernel as I was getting a KERNELPATH error:

ln -s /usr/src/kernels/`uname -r`-i686 /lib/modules/`uname -r`/build

This allowed me to make / make install the patched source again. My module still didn't show up so I blacklisted the ath5k module:

echo "blacklist ath5k" >> /etc/modprobe.d/blacklist

Then I rebooted and iwconfig recognized it. Woohoo!

Has anyone verified the latest patch? I'm unable to try it at the moment but would like to know how much success others have had with it.

Have just tried the latest r3365 patch and I get a HAL Status 13 message.

I've got a similar problem (laptop ASUS F3Ka ap031). Wifi module is detected as AR5006EG, rev 1. So far, I've tried several ways (ndiswrapper, madwifi, ath5k). However, best I was able to do was this status 13.

P.S. Sorry for my terrible english

New prepatched tarball based on r3366 now available (see ticket description). This new tarball also compiles against kernel 2.6.24.

Still getting HAL 13 with this r3365/6 - latest version I can get working is r3348 - something must of changed HAL wise between r3348 and r3365.

The only differences I can see (beyond formatting/text) between r3348 and r3366 is in ath/if_ath.c and Minstrel (which I use).

Posting from a F8 machine running 2.6.24.2-7 VIA wireless!

Thankyou!

beechhorn@gmail.com: Did you try

echo "blacklist ath5k" >> /etc/modprobe.d/blacklist

anonymous: I've alredy tried this before. It's not the issue. dmesg: ath_hal: module license 'Proprietary' taints kernel. ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133) ... wlan: svn r3365 ath_pci: svn r3365 ... MadWifi: unable to attach hardware: 'Hardware revision not supported' (HAL status 13)

(x86_64 machine)

I don't even have the ath5k module. Unless the binary blob is different - then the problem lies either in minstrel or ath/if_ath.c...

Replying to lukassoftwares a t gmail.com:

anonymous: I've alredy tried this before. It's not the issue. dmesg: ath_hal: module license 'Proprietary' taints kernel. ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133) ... wlan: svn r3365 ath_pci: svn r3365 ... MadWifi: unable to attach hardware: 'Hardware revision not supported' (HAL status 13) (x86_64 machine)

The HAL has only been patched for 32-bit x86 (i.e. i386) machines at the moment; x86_64 will not work.

Replying to FxChiP at Gmail dot com:

The HAL has only been patched for 32-bit x86 (i.e. i386) machines at the moment; x86_64 will not work.

Why only 32-bit? What is wrong with x86_64?

I second the thoughts expressed by FxChiP. What about 64 bit? Keep in mind this card is usually sold with Athlon 64 based laptops. Is there a mailing list I can subscribe to for updates on this?

For the record, the patch tarball I downloaded on 2/24 worked on my Acer, which has an AMD 64 in it. Model: AMD Turion(tm) 64 Mobile Technology MK-38. I get a ton of errors, as I mentioned above, but the driver functions properly. I'm using Slackware 12, custom kernel, and hal-0.5.9.1 (according to pkgtool). If you need tech support on this, please check the check regular support channels first (see link above). If you have a specific question about my system, you can e-mail me with a subject that is obviously not spam and I'll get back to you.

Replying to NutZ:

What about 64 bit?

It has all been said: only experimental support so far for 32bit, the usual platform support is work in progress. As soon as the current situation changes we will notify folks here in this ticket and elsewhere.

Once again: refrain from asking for updates here, and move all support requests (including thins like "help, that stuff doesn't compile!!1") to our regular support channels.

Is there a mailing list I can subscribe to for updates on this?

Resources

For those with x86_64 machines: you guys can run x86 32-bit Linux distributions and apply this patch. That will work, and there won't be a significant (if any) performance hit for this. Everything will work pretty much the same, you just won't have the true 64-bitness -- and that essentially just means your numbers don't go quite as high. It also means you're susceptible to the Year 2038 problem, but hopefully the chipset support will be fixed for 64-bit by then. ;)

Hello,

I get a Segmentation fault when removing the module 'ath_pci', by using either 'rmmod' or 'modprobe -r'. The interface ath0 is first brought down before unloading 'ath_pci'.

Then the system hangs on shutdown after the following messages:

'Killing all remaining processes...Failed.' 'Deconfiguring network interfaces...'

The OS is Debian sid with kernel 2.6.24 running on Asus EEE PC, and r2756 patched with madwifi-ng-0933.ar2425.20071130.i386.patch.

I'd like to post the segfault log (which only shows when 'modprobe -r ath_pci' is done in the "root terminal" before starting X, not in terminal emulators) but I can't record it (even with /usr/bin/script). I didn't find anything in /var/log/* neither.

Here's a testcase which leads to the segfault:

1) boot with wifi led turned of ('echo 0 > /proc/acpi/asus/wlan' before reboot) 2) login root without starting X 3) load pciehp module with option pciehp_force=1 ('modprobe pcihep pciehp_force=1') 4) turn on wifi: 'echo 1 > /proc/acpi/asus/wlan' 5) load ath_pci module: 'modprobe ath_pci' 6) remove ath_pci module: 'modprobe -r ath_pci' (Segmentation fault)

I can provide more if needed, thanks in advance for any help

Replying to ilredil@yahoo.com:

For the record, the patch tarball I downloaded on 2/24 worked on my Acer, which has an AMD 64 in it. Model: AMD Turion(tm) 64 Mobile Technology MK-38. I get a ton of errors, as I mentioned above, but the driver functions properly. I'm using Slackware 12, custom kernel, and hal-0.5.9.1 (according to pkgtool). If you need tech support on this, please check the check regular support channels first (see link above). If you have a specific question about my system, you can e-mail me with a subject that is obviously not spam and I'll get back to you.

So are you using a 64-bit kernel or just a 64-bit processor with a i386 kernel?

Replying to FxChiP at Gmail dot com:

For those with x86_64 machines: you guys can run x86 32-bit Linux distributions and apply this patch. That will work, and there won't be a significant (if any) performance hit for this. Everything will work pretty much the same, you just won't have the true 64-bitness -- and that essentially just means your numbers don't go quite as high. It also means you're susceptible to the Year 2038 problem, but hopefully the chipset support will be fixed for 64-bit by then. ;)

Anybody have testing ? I'm tired to use my wifi dongle !

Replying to anonymous:

Anybody have testing ? I'm tired to use my wifi dongle !

I'm running a 32-bit Linux on a 64-bit machine and my AR5007EG works perfectly.

Replying to anonymous:

Replying to anonymous:

Anybody have testing ? I'm tired to use my wifi dongle !

I'm running a 32-bit Linux on a 64-bit machine and my AR5007EG works perfectly.

All the other software works perfectly ? No danger ?

I'm having issues with Suspend once the machine comes back from suspend my dmesg gets flooded with (slows down the machine) Unable to reset channel (HAL status 3222547558) and (HAL status 4148523360)

I'm running Gentoo 2.6.24-gentoo-r3 x86 on Asus Z99le (A8Le) and my AR5006EG (168c:001c) works perfectly with last patch (r3366).

Patch works here, too, on my HP G6000 laptop mounting an AR5006EG. I run Ubuntu 7.10 x86 (the laptop is an AMD 64). I used the patched source directly.

Unfortunately the network does not come back after suspend/hibernate. Is it normal?

Giacecco

No good with 2.6.24.3-34.fc8

Getting various invalid module errors when running modprobe :(

Upgraded to 2.6.24.3-50.fc8 and recompiled. Its all sweet again.

So is it or isn't it running on 64bit os?

32-bit Intel x86 only; this can only run on 64-bit machines if the machine is running a 32-bit operating system. 64-bit operating systems are not supported

Worked like a charm with the latest kernel also

uname -a Linux localhost.localdomain 2.6.25-0.150.rc6.git7.fc9 #1 SMP Mon Mar 24 19:42:03 EDT 2008 i686 athlon i386 GNU/Linux

Can't wait til ath5k supports this. I heard that it will be in the final 2.6.25 - can anyone confirm?

This on a 4G asus eeepc. This is using the ath5k driver, not madwifi, HAL, OpenHAL, etc. I hope this info helps you in your development.

2.6.24 kernel as a base (along with a number of other unrelated patches)

(spam prevents urls below...)

Updated wireless:

2008-04-02
linuxwireless dot org download compat-wireless-2.6 compat-wireless-2.6.tar.bz2

Then built ath5k from Nick Kossifidis tarball:

kernel dot org pub linux kernel people mickflemm ath5k-2425-test2.tar.bz2

I had to disable PM in kernel:

CONFIG_PM=no 

With the driver loaded dmesg

ath5k phy0: Atheros AR5418 chip found (MAC: 0xe2, PHY: 0x70)

More info with module loaded.

# lspci -d 168c:001c
01:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01)

# lspci -vvv
01:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01)
        Subsystem: Unknown device 1a3b:1026
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at fbef0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
                Address: 00000000  Data: 0000
        Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
                Vector table: BAR=0 offset=00000000
                PBA: BAR=0 offset=00000000
        Kernel driver in use: ath5k_pci
        Kernel modules: ath5k

# `lspci -vvv -d 168c:001c | grep Memory`
"Region 0: Memory at fbef0000"
# setpci -s 01:00.0 command=0x41f cache_line_size=0x10

From madwifi-nr-r3366+ar5007/tools/ath_info

# ath_info 0xfbef0000

Warning: Invalid EEPROM Magic number!
 -==Device Information==-
MAC Version:  2425  (0xe0)
MAC Revision: 2425  (0xe2)
PHY Revision: 5110  (0x00)
 -==EEPROM Information==-
EEPROM Version:     5.3
EEPROM Size:        4K
Regulatory Domain:  0x60
 -==== Capabilities ====-
|  802.11a Support: no   |
|  802.11b Support: no   |
|  802.11g Support: yes  |
|  RFKill  Support: yes  |
|  32KHz   Crystal: no   |
 ========================
GPIO registers: CR 00000000 DO 00000000 DI 00000003

I can see the device with iwconfig fine:

# iwconfig ath0
ath0      IEEE 802.11  ESSID:""  
          Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated   
          Tx-Power=0 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Encryption key:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

I can change the ESSID:

# iwconfig ath0 essid foo && iwconfig ath0 | grep ESSID && iwconfig ath0 essid bar && iwconfig ath0 | grep ESSID
ath0      IEEE 802.11  ESSID:"foo"  
ath0      IEEE 802.11  ESSID:"bar"  

I can change the channel:

# iwconfig ath0 channel 1 && iwconfig ath0 | grep Frequency && iwconfig ath0 channel 6 && iwconfig ath0 | grep Frequency
          Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated   
          Mode:Managed  Frequency:2.437 GHz  Access Point: Not-Associated   

I can NOT change the mode, garr garr garr:

# iwconfig ath0 mode ad-hoc
Error for wireless request "Set Mode" (8B06) :
    SET failed on device ath0 ; Device or resource busy.

Scanning doesn't see anything (there is an open/advertised network here):

# iwlist ath0 scan
ath0      No scan results

Mode could be changed only by wlanconfig - by wlanconfig athX destroy ; wlanconfig ath create wlandev wifiX wlanmode adhoc - and/or by module parameter - aka autocreate=adhoc . Iwconfig is not able to change VAP mode.

Brilliant that there is ath5k support.

However the code could do with some code modularisation (the MVG complexity goes up to 64 for some functions). Looking at the bottom of ath5k_hw_reset for instance there is a duplicate "if (ah->ah_version == AR5K_AR5212)" - combining the two reduced code complexity to 63. Is it worth me trying to modularise the code and if so where should patches be sent?

sorry, been confused by name of interface and have't read whole post - ath0 is typical for VAP, last time i tried ath5k it created wlanX devices - what i have written about wlanconfig is only true if you use madwifi

Replying to strasak@bubakov.net:

sorry, been confused by name of interface and have't read whole post - ath0 is typical for VAP, last time i tried ath5k it created wlanX devices - what i have written about wlanconfig is only true if you use madwifi

In Fedora, udev changes the name of the device. From dmesg:

ath5k phy0: Atheros AR5418 chip found (MAC: 0xe2, PHY: 0x70)
udev: renamed network interface wlan0 to ath0

mickflemm reported in ath5k-devel that the radio isn't being turned on and he's working at it.

I can confirm it works, my laptop is an acer aspire 4520, turion x2 1.6ghz, atheros 5007eg The older patches didnt work, but the current one, the 3366 works like a charm, much better than ndiswrapper which was giving me major headaches. Distro: ubuntu 804 beta

Works perfectly on Samsung R60+ running Hardy on latest official kernel 2.6.24-15, it used to give me some error messages on bootup and segfault when trying to manually unload the module, but the patch solved everything. Great work!

There are some reports that this doesn't "work perfectly" (thats what the hardware compatability page says :-). forum.eeeuser.com/viewtopic.php?id=18158

Apparently the patch here doesn't work as well on the ASUS EEEPC as either the binary driver from ASUS (included with the installed OS), or the windows driver (which can be run using ndiswrapper). Signal strength is reduced and the connection drops out.

My experience is also that the driver from the installed OS seemed to have better range; I have to stay closer to the router now I've reinstalled using r3366+ar5007.

Is this plausible, expected, known?

Looking forward to a working ath5k driver. Thanks for everything.

Working on an Acer AL5100, the small form factor desktop.
Atheros 5007
AMD Athlon 64 X2 4200+
Fedora Core 6
Linux 2.6.18-1.2798.fc6

r3366+ar5007 is NOT working on my MSI VR610 notebook with the following 'lspci -v' output:

02:00.0 Ethernet Controller: Atheros Communications, Inc. Unknown device 001c (rev 01)

Subsystem: Unknown device 1a3b:1026 ...

Inserting the module gives the well-known 'Hardware didn't respond as expected' HAL status 3. Though not difficult, I just don't want to switch to ndiswrapper. :) Anyone got an idea?

Replying to wolleric:

r3366+ar5007 is NOT working on my MSI VR610 notebook with the following 'lspci -v' output: 02:00.0 Ethernet Controller: Atheros Communications, Inc. Unknown device 001c (rev 01)

I'm no dev, but you should probably try running ath_info (madwifi.org/wiki/UserDocs/AthInfo). If it works, the first few lines will help identify your chipset more reliably than lspci does.

Oops, bad link. Try this: UserDocs/AthInfo, or look it up manually.

Replying to madwifi@atheros.com:

I would like to report that this patch works perfectly on an Acer Aspire 3680-2682 marked as having a AR5BXB63 chip. Perhaps someone should redirect people in the compatibility page to this ticket?

Thanks a lot Madwifi crew!

Ok, this is the ouput of ath_info:

 -==Device Information==-
MAC Version:  2425  (0xe0)
MAC Revision: 2425  (0xe2)
Warning: Invalid EEPROM Magic number!
Device type:  3

/============== EEPROM Information =============\
| EEPROM Version:   5.3 | EEPROM Size:   4 kbit |
| EEMAP:              2 | Reg. Domain:     0x60 |
|================= Capabilities ================|
| 802.11a Support:  no  | Turbo-A disabled: yes |
| 802.11b Support:  no  | Turbo-G disabled: yes |
| 802.11g Support:  yes | 2GHz XR disabled: yes |
| RFKill  Support:  yes | 5GHz XR disabled: yes |
| 32KHz   Crystal:  no  |                       |
\===============================================/

The latest patched snapshot, r3366+ar5007 doesn't work as well for me as did the earlier one r2756+ar5007. On Fedora rawhide, the 3366 version kept losing connectivity. Going back to r2756 fixed the problem. This is an Acer Aspire 4720z.

Mandriva's "one" CD and probably the other non-free ones, now offer out of the box support for this card.

success on: Acer Aspire 5715z (Dual Pentium T2310 @ 1.46GHz, chipset PM965 + ICH8)

distro: Ubuntu Hardy 8.04 latest beta kernel: 2.6.24-16

device id: 168c:001c (rev 01) used version: r2756 + patch

Replying to wocis:

success on: Acer Aspire 5715z (Dual Pentium T2310 @ 1.46GHz, chipset PM965 + ICH8) distro: Ubuntu Hardy 8.04 latest beta kernel: 2.6.24-16 device id: 168c:001c (rev 01) used version: r2756 + patch

have the same laptop and applied the same version + patch

did you have some freeze ? sometimes i have like a kernel panic, nothing respond and the caps lock led blink

some other times, when using amule a long time, network freeze, no more connection, no ping possible ... the solution : need to click on the network monitor applet and tell the wifi to reconnect to the Acces point

well i don't know if this is normal, but lspci -v give me this

06:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
	Subsystem: AMBIT Microsystem Corp. Unknown device 0428
	Flags: bus master, fast devsel, latency 0, IRQ 19
	Memory at d4100000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] Power Management version 2
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [60] Express Legacy Endpoint IRQ 0
	Capabilities: [90] MSI-X: Enable- Mask- TabSize=1

and ath_info 0x4100000 this

Warning: Invalid EEPROM Magic number !
 -==Device Information==-
MAC Version:  5311A(0x20) 
MAC Revision: 5311A(0xe12b) 
PHY Revision: 5110 (0x0) 
 -==EEPROM Information==-
EEPROM Version:     9.6c8 
EEPROM Size:        8K
Regulatory Domain:  0x96C8 
 -==== Capabilities ====-
|  802.11a Support: no   |
|  802.11b Support: no   |
|  802.11g Support: no   |
|  RFKill  Support: no   |
|  32KHz   Crystal: no   |
 ========================
GPIO registers: CR f3fd2aa8 DO 4078376f DI f08e87f3

strange... there are "no" on each lines, but i currently use my wifi with r2756 + patch on ubuntu hardy

ps: last comment in reply to wocis was me too

I tried to download the snapshot snapshots.madwifi.org/madwifi-ng/madwifi-ng-r2756-20071018.tar.gz but unfortunately the link is broker So I tried with the readily-patched snapshot (which link works), I tried with "make", at the beginning the program was unable to detect kernel version, so I replaced line

KERNELRELEASE := $(shell $(CC) -I $(KERNELPATH)/include -E $(TOP)/kernelversion.c | grep uts_release | cut -f2 -d'"') with KERNELRELEASE := /usr/src/linux-2.6.22.17-0.1 at that point exucuting again the program with "make" command I am having the following message:

Checking requirements... ok. Checking kernel configuration... FAILED Only kernel versions 2.4.x and above are supported. You have /usr/src/linux-2.6.22.17-0.1. make: *** [configcheck] Error 1

What can I do?

Replying to Martin:

I tried to download the snapshot ... but unfortunately the link is broker

The snapshot archive has been restructured yesterday, see here.

at the beginning the program was unable to detect kernel version, so I replaced line

You should not edit the Makefile until you know exactly what you do. The issue you describe is one that is not related to this ticket, so I have opened a new ticket (#1901) for it. Please follow up there.

Loaded the pre-compiled patch for ar5007eg on 8.04 rc1, This is on an Acer Extensa 5420 laptop. Works great! my wife is very happy!

thanks!

Works under slamd64 (64 bit) with ndiswrapper 1.52 and the net5211 windows driver you can found at http: //www.freefilehosting.net/files/3blea (url obfuscated)

Does anyone know if the driver and the patch, can put the card in monitor mode, or is this a problem. I have tried with no sucess.

using Ubuntu Hardy, applied patch "madwifi-nr-r3366+ar5007" => it works -- BUT!!! I can't connect WPA-wise. Without security works flawless.

Any idea?

openSuse 10.3 32 bit AMBIT Microsystem (by Atheros Communications) / AR5006EG

I downloaded snapshots.madwifi.org/madwifi-ng/madwifi-ng-r2756-20071018.tar.gz execute the comand make returned program execution that I get http: //madwifi.org/attachment/ticket/1679/terminal.pdf?format=raw

when executing the comand modprobe ath_pci a new blank command line is presented in the terminal running iwconfig I have l0 no wireless extensions. eth0 no wireless extensions.

nothing appears in the network devices apart from the wired lan card

Snapshot r3366+ar5007 worked fine for me on my Sony Vaio VGN-NR21J (with the AR5007EG chipset). Thanks very much for this!

here's the snapshot from the broken link... I think..

snapshots.madwifi.org/special/madwifi-ng-r2756+ar5007.tar.gz

Worked, I had to insert modules wlan_ccmp, ath_pci, ath_hal, wlan, wlan_scan_ap. wpa_supplicant wouldn't connect, killed everything, rmmod ath_pci, modprobe ath_pci, now I'm up. It connected much faster than ndiswrapper allowed.

This patch works perfect. My hardware is a fujitsu-siemens Amilo P2540. I am using Fedora 8 and had two different kernels in the meantime and it works just great.

Just upgraded to ubuntu hardy was using gutsy with 2.6.22-14-generic, which worked perfectly and like usual after a kernel upgrade i have to reinstall the patched madwifi but now when every time i install it gnome has issues (freezes for a couple mins with an error about gnome settings manager, desktop hasn't loaded yet, then after a while everything starts up fine and works) Using 2.6.24-17-generic i believe this became available about 2 days ago and as far as i understand 2.6.24-16-generic didn't have any issues though haven't tested. Any ideas as to whats happening?

I just installed the latest Debian unstable kernel (2.6.25-1) and did my usual "make/make install" ritual with the prepatched "r3366" driver above (which has worked for me on every kernel since 2.6.22). Unfortunately, it's met it's match with .25, which threw up errors during the make process. I double-checked that I was using the correct version of build-essential and the appropriate kernel headers, was sure to "make clean" beforehand, but still no dice.

OK, the kernel I used is in the unstable Debian branch, so I'm hoping whatever's wrong will be fixed before it percolates through to the testing branch, but I just thought I'd add my two cents here.

I run rawhide.... 2.6.25 has been working fine for me since the RC versions.