Understood, but we folks in user-land who have many hundreds of installed
embedded (unattended) systems that need maintaining, can't jump to such
bleeding edge code, esp. if it doesn't reliably support commonly-used
modalities such as AP and ad-hoc. Despite some quirks that can be addressed
with properly-constructed scripts and watchdogs, Madwifi has proven itself
to be very reliable in real-world embedded installations like ours. So we
(and many others like us) will likely continue to use madwifi for a long,
I also don't think that narrow channels constitute a "new" feature. There is
code referencing that kind of operation going back several years, it already
works in the WRT flavors, and it seems to be mainly a matter of either (a)
knowing which magic, undocumented incantation to throw at one or more of the
existing cards or code-bases or (b) finishing the remaining 5% of missing or
misconfigured code in e.g. trunk to make this badly-needed function
available. I'm motivated but not qualified to do that work, but I certainly
hope someone out here is!
----- Original Message -----
From: "Pavel Roskin" <proski@...>
To: "Tom Sharples" <tsharples@...>
Sent: Thursday, July 23, 2009 4:57 PM
Subject: Re: [Madwifi-users] Further to Re: half / quarter channel how-to? -
HAL revision confusion?
> On Thu, 2009-07-23 at 16:50 -0700, Tom Sharples wrote:
>> Having just gotten back from a road trip I tried setting regdomain to
>> on a Wistron CM9. This change does take, however thereafter I could not
>> ath_pci (with wifi0 appearing) using any countrycode setting from 840 to
>> 850, or with no countrycode setting at all. Further suggestions are
>> appreciated. Do I need to use a different radio?
> My comment wasn't meant as an instruction. If was based solely on
> reading the code.
> Even though narrow channels may be legal, I would prefer not to touch
> MadWifi HAL. New features belong to ath5k and ath9k, not to MadWifi,
> which is barely maintained and hasn't made a release for over a year.
> The kernel has a regulatory database independent of the drivers, so it
> should be safer to modify the driver code without risking to break some
> Pavel Roskin
> Madwifi-users mailing list