Just in case someone needs them. With injection patch.
Created attachment 188414 [details] svn driver ebuild for madwifi-hal-testing branch I'm not sure about the naming. madwifi-hal or madwifi-ng-hal.
Created attachment 188416 [details] injection patch for madwifi-ng-hal-9999.ebuild
Created attachment 188419 [details] svn tools ebuild for madwifi-hal-testing branch
added to my overlay
madwifi-hal branch is for integration of HAL version 0.10.5.6 into MadWifi. We already have request for this open... And btw, read my comment 18 there. *** This bug has been marked as a duplicate of bug 234126 ***
ah, I see, this is new hal version described here: http://madwifi-project.org/wiki/news/20080829/new-hal-release-for-atheros-hardware Probably I'll add it to the tree... Reopening bug for now.
After 8 months' silence, I hope it's forgiveable for me to enquire about this bug's status. It's still the only driver that works reliably for some newer chipsets, and I'd hope we could see it added to testing, or at least to an official overlay.
Sorry, to correct the above, I know it is in wirelay overlay, but that overlay lacks an up-to-date ebuild for wpa_supplicant and as such seems neglected (apologies to alexxy if this is not the case).
The status is simple: both ath5k and madwifi-ng work here and currently I failed to find reasons to have this driver in the tree. Could anybody tell me why do you need this driver?
Well, I'm honestly surprised by that assessment. I thought that lack of support for AR242x chipsets was a known issue and the main reason for people to use madwifi-ng-hal. If I'm wrong in this, or something has changed that I've missed, apologies for the oversight. Certainly madwifi-ng did not work at all for such a chipset last time I tried it. As for ath5k, its performance last time I tried it was abysmal, not going above 1Mbps unless bullied up to 11Mbps using iwconfig, and dropping very frequently - and this with an Atheros-based AP (Netgear DG835PN). I do use it currently for ad-hoc connections to a 3G phone, but only because it's the only driver that works *at all* with ad-hoc in my experience. Since it has been a while, I'll try both drivers again and see if anything has changed. Will let you know what happens.
Right, findings. in-tree madwifi-ng: Unusable. wlan, ath_pci and ath_hal modules load but no interface is created (neither wifi* nor ath*). ath5k: Better than last attempt, but still unsatisfactory. Rate yoyos between 1-54Mbps. wpa_supplicant initially insists on selecting an ad-hoc essid, even though that essid has no active peers and its priority is below (higher number) that of the desired AP. This is without ap_scan 2 being set in wpa_supplicant.conf, which I'd thought was necessary in order to connect in ad-hoc mode. Also, after then using wpa_cli/wpa_gui to select the appropriate AP, the interface doesn't receive an address. It's necessary to restart wlan0, then re-select the correct AP. (NB - I do acknowledge that some or all of these symptoms may be the fault of wpa_supplicant or the initscripts.) So there you have it: ath5k _can_ work but with a great deal of frustration and variable performance; madwifi-ng doesn't work at all. In considering whether madwifi-ng[-tools]-hal should go in the tree, I think it's similar to the question of whether the existing madwifi-ng should be there, if ath5k works too. The answer, to my mind, is that the madwifi code is much more mature and reliable, with much better support of advanced features such as master and monitor modes. This is equally true of this svn driver in my experience, with the added advantage of supporting newer chipsets like mine (which isn't really even that new). Now there may be factors that preclude this as I don't know much about the codebase or what the upstream masterplan is, but ideally I'd see this as the future of the madwifi driver in the tree.
The ebuilds now fail with gentoo-sources-2.6.33, apparently due to the deprecation of CONFIG_WIRELESS_EXT. I was able to build it per the workaround suggested in Bug #306851 - adding an extraneous driver to the kernel (along with extraneous pcmcia support) - which s hardly ideal. #306851 is solved by an updated ebuild for madwifi-ng apparently, but I'm not clear on how the situation compares with this branch and these ebuilds.
(In reply to comment #3) > Created an attachment (id=188419) [details] I believe ESVN_REPO_URI should be set to something like http://svn.madwifi-project.org/madwifi/branches/madwifi-hal-0.10.5.6/@4128 because madwifi-hal-0.10.5.6 branch was removed from HEAD revision
TBH it doesn't look now like there's much of a future for these ebuilds, as the madwifi-hal-* branches have both been removed and further reading of the -devel mailing list makes it clear they've been abandoned for some time now. It already requires inelegant bodging of kernel config just to persuade them to build. This is a real kick in the nuts for the reasons exhaustively recounted above (for what it was worth), but it looks like this might as well be closed now.
Robin, but what are upstream thoughts on the issues you raised here?
I hadn't given much thought to raising it with upstream, since it became clear they've had nobody interested in carrying on work with this HAL for some time now. If you think there's any mileage in doing so I could mention it, I guess, but I'm doubtful of much coming of it.
Just another thought before I do such a thing: would probably be worth trying with an svn ebuild of trunk madwifi in case it has better results now. I just tried the ones in the arcon overlay, but madwifi-ng-9999 does not build and I suspect these ebuilds may be neglected. If I can get my hands on svn ebuilds that will actually build, I'll be up for giving them a try before bothering madwifi devs about the hal-testing situation.
Per a comment in bug #306851 I edited the madwifi-ng-9999 ebuild from arcon overlay (omitting the defunct patches) and was able to build the package successfully. With it the interface comes up at 12Mbps, can be set to 54Mbps using iwconfig (not sure how much real improvement this confers, but speed seems on a par with madwifi-hal). As of half an hour's use, it seems to work OK. Therefore I don't appear to have any need for the hal-testing branch either. Unless anyone else does, this can probably be closed.
closing. Robin, btw, could you update ebuilds in bug 193549? I'm not sure if this is a good idea, but I think that we could add -9999 ebuilds into the tree that will build madwifi trunk, while keeping 0.9.4 snapshots for general consumption.
Peter, I think (In reply to comment #19) > closing. Robin, btw, could you update ebuilds in bug 193549? I'm not sure if > this is a good idea, but I think that we could add -9999 ebuilds into the tree > that will build madwifi trunk, while keeping 0.9.4 snapshots for general > consumption. > I think the ebuilds in that bug are different from the ones in arcon-overlay - per the latest patches on that bug, there are already no patches applied (apart from optionally an injection patch). Not sure which set is more up-to-date.
Just found following page: http://wiki.debian.org/ath5k it states that known AR242x issue was fixed in kernel starting with 2.6.28.1.
Yes, I tried ath5k again recently and it actually performs better than madwifi svn. I now use it full-time (had already been using it occasionally for ad-hoc connections). Still not that good for my older card, but for the ar2425 it's much more reliable at keeping the connection up under low signal.
