On Sun, Nov 15, 2009 at 2:52 AM, Michael Renzmann
<[email protected]> wrote:
> Hi all.
>
> As you might have noticed, there currently is a discussion [1] going on
> about the future directions of the MadWifi project, including a decision
> how to deal with MadWifi driver. It turns out that there are pretty
> contrary positions in this regard: some would like to see MadWifi being
> dumped completely as soon as possible, others would prefer to continue
> development and even implement new features.
>
> What do others think? It appears to me that we know too little about what
> MadWifi is actually used for today and why. Thus I'd like to start a quick
> survey.
>
> It would be great if you could answer some or - ideally - all of the
> following questions:
>
> 1. What are you using MadWifi for?
>
> 2. Did you already evaluate ath5k/ath9k? If no, why not?
>
> 3. In case you evaluated ath5k/ath9k but did not yet switch: what is the
> reason for your decision, and what is required before you could switch?
>
> Any input is highly welcome, thanks in advance for your time.
>
> Bye, Mike
>
> [1] http://thread.gmane.org/gmane.linux.drivers.madwifi.project/165
>
Everyone on kernels >= 2.6.25 would have tried ath5k, granted with
probably a horrible experience as it was still early development.
Everyone on >= 2.6.27 would have tried ath9k.
So some sort of survey on this on madwifi-devel is not fair or just to
ath5k/ath9k as the only thing it would bring out is those romantics
still reading madwifi-devel due to some sort of attachment to it. I'm
not saying those attachments are bad I'm just saying MadWifi is long
dead to many and those still reading to madwifi lists are obviously
still trying to use it for one reason or another.
Madwifi's future as a Linux driver does not depend on what users wish
would happen on a legacy driver due to romantic experiences with it
with extensive features and its history. From a development
perspective the future of any Linux driver is just to go upstream. Its
very simple. Any company developing a driver out-of-tree is just not
doing Linux driver development the right way.
Linux distributions won't go around carrying legacy drivers unless
they serve a purpose and what you'll see is Linux distributions prefer
upstream drivers for an obvious reason -- its where Linux drivers
should go.
If a few developers still exist who are committed to helping maintain
madwifi until ath5k gets feature-parred the easiest solution now
(since the HAL is open) is to just throw it into staging and hopefully
that'll attract more developers to help keep it up to date with actual
current kernels. No -- you won't get 2.4 kernel support though -- if
you're on 2.4 you should just upgrade. But really best thing as a user
or motivated developer is to just annotate a missing feature and add
it upstream through mac80211/cfg80211 as ath5k really should be in a
decent condition by current kernel standards and Madwifi as a codebase
can probably just remain in maintenance mode outside of the kernel.
Anything else is just wasting time and electrons.
Luis
On Wed, 2009-11-18 at 14:08 -0800, Luis R. Rodriguez wrote:
> So for now countries either take the FCC, are part of a larger group
> like in Europe or are a head ache to deal with due to historical
> changes on regulatory rules (Japan). So far I've seen rules set for
> bands and with max EIRP and antenna gain. Sometimes you have quirky
> rules for antenna gain like in the US for the 3:1 rule (but we don't
> yet allow you to modify your antenna on linux and specific your new
> dbi antenna gain, and this actually is assumed won't change on the
> client side).
>
> For width I'm told some countries do not allow HT40 and that this
> should change in the future.
>
> I haven't seen rules for finer level of control which is why I said I
> we should not need to change anything. Right now I've only have heard
> of countries sometimes disallowing HT40, but that's it.
>
> Are you aware of any regulatory rules which prohibit narrower
> channels? It just seems odd.
No, I'm not aware of such limitations. OK, you are not aware of such
limitations either, then perhaps we can go ahead with the narrow
channels.
--
Regards,
Pavel Roskin
On Wed, Nov 18, 2009 at 3:05 PM, Jouni Malinen <[email protected]> wrote:
> On Wed, Nov 18, 2009 at 02:08:16PM -0800, Luis R. Rodriguez wrote:
>> Are you aware of any regulatory rules which prohibit narrower
>> channels? It just seems odd.
>
> I don't remember any rules that would explicitly do that, but there may
> be some implicit limitations due to the slower TX rate. I don't know
> whether this would hit anywhere, but at least quarter width channel with
> 1 Mbps TX rate and maximum frame length might get pretty close to some
> maximum TX-without-sensing limits. Though, that is less likely to be an
> issue on 5 GHz band due to 6 Mbps minimum TX rate even at quarter
> channels could be fast enough. There could also be some rules that state
> the minimum TX rate, so there could potentially be need to change
> supported rate sets and/or fragmentation threshold in some corner cases.
>
> Actually, even with 6/4 Mbps TX rate, the channel sensing rule in Japan
> (carrier sense every 4 ms) (if that rule is still valid.. haven't
> really checked), we could hit the limit with maximum frame length.
Thanks for the details, we'll poke our regulatory guys just to confirm.
Luis
Luis R. Rodriguez wrote:
> On Tue, Nov 17, 2009 at 12:57 PM, Andrey Yurovsky <[email protected]> wrote:
>> On Tue, Nov 17, 2009 at 9:40 AM, David Acker <[email protected]> wrote:
>>>>> 1. What are you using MadWifi for?
>>> Wireless mesh on embedded systems.
>
> I'm curious -- what type of Mesh were you talking about David? I
> didn't know MadWifi supported 802.11s so don't know if that is what
> you mean.
It is a non-802.11s protocol that predates 802.11s development by quite
awhile. It runs over WDS links. In theory it could run over anything
that supports dynamic creation and destruction of WDS links.
>> FWIW ath5k has working draft-802.11s mesh mode, in fact it's one of
>> the better-supported drivers.
>
> Thanks for pointing that out Andrey.
Yes, that is good to hear.
-ack
Luis R. Rodriguez wrote:
> On Tue, Nov 17, 2009 at 1:53 PM, David Acker <[email protected]>
> wrote:
>> Luis R. Rodriguez wrote:
>>> On Tue, Nov 17, 2009 at 1:44 PM, David Acker <[email protected]>
>>> wrote:
>>>> It is a non-802.11s protocol that predates 802.11s development
>>>> by quite awhile. It runs over WDS links. In theory it could
>>>> run over anything that supports dynamic creation and
>>>> destruction of WDS links.
>>> So its a some sort of MadWifi-only hack?
>> Not at all. The algorithm runs in user space
>
> OK so not relevant.
True, but I was answering Michael's original question, "What are you
using MadWifi for?" I was trying to describe the system. Sorry for the
confusion.
>> The problem with switching to ath5k would be the loss of
>> performance related features (compression, fast frames, turbo),
>
> These are different than "mesh".
Yes, but it would be good if these features were supported over WDS
links (and on AP to STA links where both support the features).
>> and some required features (half/quarter rates are required for
>> some channels on some radios).
>
> How does "mesh" relate to this?
It doesn't. That is what the product I work on does.
>
>> Also, I don't know if ath5k will work on products based on Atheros
>> WiSOCs like Ubiquiti's PicoStation and Bullet.
>
> ath5k does not *yet* have SoC support but it may get it at later
> point.
That would be great.
>
> So let me get this straight.
>
> You have SoC Atheros solutions that use some userspace custom (not
> 802.11s) solution that use fast frames, compression and turbo, oh and
> half/quarter rates? WTF are you doing?
Lol, it isn't as crazy as it sounds. I have meshing running on various
platforms. Some use miniPCI atheros based radios, some are SoC based. I
believe I misspoke when I said half/quarter rates. It is better to say
half width (10 MHz) or quarter width (5 MHz) channels. There are
several miniPCI based radios that require half or quarter width channels
on some channels. For example, the Ubiquiti XR7 requires quarter width
channels on two of its four available channels. The XR9 requires half
width channels on two if its four available channels. Sorry for any
confusion I created.
> For backporting we have compat-wireless, it should allow you to use
> even today's bleeding edge even on 2.6.25. It should be possible to
> bring this down to 2.6.21 even but not many people are interested in
> that it seems. Patches are welcomed though.
Thanks. I am trying to decide which is more painful: porting a recent
kernel to the hardware or porting compat-wireless down to 2.6.18.
On Mon, Nov 16, 2009 at 05:01:09PM -0800, Luis R. Rodriguez wrote:
> If a few developers still exist who are committed to helping maintain
> madwifi until ath5k gets feature-parred the easiest solution now
> (since the HAL is open) is to just throw it into staging and hopefully
> that'll attract more developers to help keep it up to date with actual
> current kernels.
For the record, I would be generally opposed to adding madwifi to
drivers/staging. We already have enough trouble with duplication of
hardware support between drivers/staging and drivers/net/wireless.
If madwifi has features that people need/want and that ath5k/mac80211
still lacks, lets talk about how to get them (or reasonabe replacements
for them) into the mainline kernel. I'm sure some ideas will meet
some resistance, but if someone is motivated to continue pursuing
maintenance of madwifi than they should be motivated enough to at
least try to convince the rest of us why those features are worth
having in net/wireless, net/mac80211, and/or drivers/net/wireless.
Even if the solution is some quirky thing that "normal" people will
ignore, it is bound to be better to have mainline support than to
continue working out-of-tree.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
[Removed linux-kernel from CC, having this discussion on three mailing
lists is more than enough]
Hi Luis.
Luis R. Rodriguez wrote:
> So some sort of survey on this on madwifi-devel is not fair or just
> to ath5k/ath9k as the only thing it would bring out is those romantics
> still reading madwifi-devel due to some sort of attachment to it.
I did ask on madwifi-devel and madwifi-users because these are the lists
where we can reach those who still stick to MadWifi. The whole idea of the
survey is to learn about their reasons, to find out what exactly prevents
them from switching to ath[59]k. Thus it was a natural and intentional
choice - where else would you have asked these questions?
I disagree about your point on fairness. The survey will hopefully result
in information that we don't seem to have so far, helping those who
actively work on ath[59]k to determine which features the users are
missing in both drivers. This survey is working *towards* ath[59]k, not
against them.
> Madwifi's future as a Linux driver does not depend on what users wish
> would happen on a legacy driver due to romantic experiences with it
> with extensive features and its history.
The development of any software should happen with the user's needs and
requirements in mind, since otherwise that software won't have users and
all effort spent on the development is a waste. Just doing development
"the right way" does not guarantee that the result of such development is
what users actually need and can work with. That's probably especially
true if one intends to replace an established software by another one.
Again: there must be reasons why a significant amount of MadWifi users
didn't switch to ath[59]k yet, and we don't seem to have exact ideas what
these reasons are. Listening to these user to see what can be done to make
them *want* to switch appears like a good idea to me. At least it's better
than plainly putting them off with the "take it or leave it,
romantics!"-like approach you (being an Atheros employee) promote despite
the fact that those who "leave it" may reconsider their decision for
Atheros-based equipment.
Bye, Mike
On Tue, Nov 17, 2009 at 9:40 AM, David Acker <[email protected]> wrote:
>>> ?1. What are you using MadWifi for?
>
> Wireless mesh on embedded systems.
FWIW ath5k has working draft-802.11s mesh mode, in fact it's one of
the better-supported drivers.
-Andrey
On Tue, Nov 17, 2009 at 8:04 AM, Michael Renzmann
<[email protected]> wrote:
> [Removed linux-kernel from CC, having this discussion on three mailing
> lists is more than enough]
>
> Hi Luis.
>
> Luis R. Rodriguez wrote:
>> So some sort of survey on this on madwifi-devel is not fair or just
>> to ath5k/ath9k as the only thing it would bring out is those romantics
>> still reading madwifi-devel due to some sort of attachment to it.
>
> I did ask on madwifi-devel and madwifi-users because these are the lists
> where we can reach those who still stick to MadWifi. The whole idea of the
> survey is to learn about their reasons, to find out what exactly prevents
> them from switching to ath[59]k. Thus it was a natural and intentional
> choice - where else would you have asked these questions?
My point was that there are already hundreds of users already on ath5k
and ath9k and that obviously you will get a biased view of MadWifi /
ath5k situation (I don't consider MadWifi any type of alternative to
ath9k).
You started with:
"As you might have noticed, there currently is a discussion [1] going on
about the future directions of the MadWifi project, including a decision
how to deal with MadWifi driver. It turns out that there are pretty
contrary positions in this regard: some would like to see MadWifi being
dumped completely as soon as possible, others would prefer to continue
development and even implement new features.
What do others think?
"
This alone is an invitation for discussion between MadWifi and ath5k
as supported drivers. Keeping this conversation to madwifi-* lists is
not doing justice to the enhancements made to ath5k so far -- or
ath9k.
That was my point.
> I disagree about your point on fairness. The survey will hopefully result
> in information that we don't seem to have so far, helping those who
> actively work on ath[59]k to determine which features the users are
> missing in both drivers. This survey is working *towards* ath[59]k, not
> against them.
That's not what the above read to me as.
>> Madwifi's future as a Linux driver does not depend on what users wish
>> would happen on a legacy driver due to romantic experiences with it
>> with extensive features and its history.
>
> The development of any software should happen with the user's needs and
> requirements in mind
Note I didn't say otherwise.
>, since otherwise that software won't have users and
> all effort spent on the development is a waste. Just doing development
> "the right way" does not guarantee that the result of such development is
> what users actually need and can work with. That's probably especially
> true if one intends to replace an established software by another one.
This is missing the point I was trying to make which is that MadWifi
future will not depend on what knobs or how much fun users would have
had with MadWifi. Madwifi's future is simply abandonment and
maintenance mode. I don't need a crystal ball for this, its just
trying to illustrate the point that a driver not upstream is a waste
of time.
> Again: there must be reasons why a significant amount of MadWifi users
> didn't switch to ath[59]k yet
MadWifi is in no way any type of replacement for ath9k. If anything
its an alternative legacy driver and base model driver for ath5k.
> and we don't seem to have exact ideas what
> these reasons are.
Well to me they are clear and I don't need a survey to understand
this. ath5k currently lacks:
* DFS
* Multi-BSS AP functionality
* Roaming
* ANI
Anyone needing these features are out of luck right now with ath5k,
and those that would be out of luck probably would end up using
openwrt anyway and that driver is maintained.
> Listening to these user to see what can be done to make
> them *want* to switch appears like a good idea to me.
My goal is not to force anyone's arm to switch -- I want to focus on
getting things done so that a question does not have to be asked,
instead the answer would be implicit.
> At least it's better than plainly putting them off with the "take it or leave it,
> romantics!"-like approach
But that's the truth. Users of a MadWifi driver for AP mode support
would likely use openwrt, and that has proper support, users who don't
want to deal with out-of-kernel drivers simply won't even touch
MadWifi. Madwifi-devel lacks proper attention and its no surprise, it
was bound to happen, so someone hoping for something else is a
romantic in my mind.
> you (being an Atheros employee) promote despite the fact that those who
> "leave it" may reconsider their decision for Atheros-based equipment.
ath5k is for those who wanted to leave it ages ago and didn't need an
explanation why that was a better path, all I can do is try to create
awareness and speak bluntly about the reality of the situation.
MadWifi development is not going to be kicked up, you won't get better
support, the sooner users realize that the better.
Luis
On Tue, Nov 17, 2009 at 1:44 PM, David Acker <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>>
>> On Tue, Nov 17, 2009 at 12:57 PM, Andrey Yurovsky <[email protected]>
>> wrote:
>>>
>>> On Tue, Nov 17, 2009 at 9:40 AM, David Acker <[email protected]> wrote:
>>>>>>
>>>>>> 1. What are you using MadWifi for?
>>>>
>>>> Wireless mesh on embedded systems.
>>
>> I'm curious -- what type of Mesh were you talking about David? I
>> didn't know MadWifi supported 802.11s so don't know if that is what
>> you mean.
>
> It is a non-802.11s protocol that predates 802.11s development by quite
> awhile. It runs over WDS links. In theory it could run over anything that
> supports dynamic creation and destruction of WDS links.
So its a some sort of MadWifi-only hack?
Luis
Felix Fietkau wrote:
> David Acker wrote:
>> Also, I don't know if ath5k will work on products based on
>> Atheros WiSOCs like Ubiquiti's PicoStation and Bullet.
> I have some work in progress patches for that. They won't work yet (in
> fact I just ported them to a newer version of compat-wireless without
> testing, so they probably won't even compile yet *g*), but according to
> my rough estimation, they contain about 70-80% of what's necessary to
> support this hw. You can find them at http://nbd.name/ath5k-wisoc.tar.gz
> If anybody is seriously interested in hacking on this stuff, please take
> a look at this patch series and contact me afterwards...
Interesting. Time permitting, I will try to take a look at this a bit
this week.
>
>> A lesser issue
>> (more of a pain for me than an ath5k issue) is that I have some
>> platforms that use an older kernel and moving up to a newer kernel will
>> have to be done without hardware vendor support.
> What platforms with old kernels are you using? Maybe some of them are
> being worked on in OpenWrt already ;)
Perhaps. I have a CM-X255
http://www.compulab.co.il/x255/html/x255-cm-datasheet.htm combined with
a custom board for PCI with an intel pro 100 and a miniPCI slot holding
a ubiquiti card.
-ack
On Tue, Nov 17, 2009 at 11:38 AM, Luis R. Rodriguez <[email protected]> wrote:
> ?* DFS
> ?* Multi-BSS AP functionality
> ?* Roaming
> ?* ANI
Also antenna selection has been requested -- this is dead simple
if anyone wants to write appropriate hooks into the stack for it.
The code is already in the driver, it just needs some configuration
glue.
--
Bob Copeland %% http://www.bobcopeland.com
Marcel Holtmann wrote:
> Hi David,
>
>> The problem with switching to ath5k would be the loss of performance
>> related features (compression, fast frames, turbo), and some required
>> features (half/quarter rates are required for some channels on some
>> radios). Also, I don't know if ath5k will work on products based on
>> Atheros WiSOCs like Ubiquiti's PicoStation and Bullet. A lesser issue
>> (more of a pain for me than an ath5k issue) is that I have some
>> platforms that use an older kernel and moving up to a newer kernel will
>> have to be done without hardware vendor support.
>
> and that is exactly not a valid point to include MadWifi into the
> staging tree. If you are running older kernels, the staging tree doesn't
> help you at all.
True. I happen to agree that Madwifi shouldn't go into staging. I
would rather see the features I noted ported into ath5k. Thanks!
-ack
Hi John,
> > If a few developers still exist who are committed to helping maintain
> > madwifi until ath5k gets feature-parred the easiest solution now
> > (since the HAL is open) is to just throw it into staging and hopefully
> > that'll attract more developers to help keep it up to date with actual
> > current kernels.
>
> For the record, I would be generally opposed to adding madwifi to
> drivers/staging. We already have enough trouble with duplication of
> hardware support between drivers/staging and drivers/net/wireless.
>
> If madwifi has features that people need/want and that ath5k/mac80211
> still lacks, lets talk about how to get them (or reasonabe replacements
> for them) into the mainline kernel. I'm sure some ideas will meet
> some resistance, but if someone is motivated to continue pursuing
> maintenance of madwifi than they should be motivated enough to at
> least try to convince the rest of us why those features are worth
> having in net/wireless, net/mac80211, and/or drivers/net/wireless.
> Even if the solution is some quirky thing that "normal" people will
> ignore, it is bound to be better to have mainline support than to
> continue working out-of-tree.
I 100% agree with you. The MadWifi driver should NOT be included into
the staging tree. We have an upstream driver for this hardware and if
people are not happy with it, then they should start fixing or extending
it. A second driver for the same hardware just causes confusion.
Regards
Marcel
Hi David,
> The problem with switching to ath5k would be the loss of performance
> related features (compression, fast frames, turbo), and some required
> features (half/quarter rates are required for some channels on some
> radios). Also, I don't know if ath5k will work on products based on
> Atheros WiSOCs like Ubiquiti's PicoStation and Bullet. A lesser issue
> (more of a pain for me than an ath5k issue) is that I have some
> platforms that use an older kernel and moving up to a newer kernel will
> have to be done without hardware vendor support.
and that is exactly not a valid point to include MadWifi into the
staging tree. If you are running older kernels, the staging tree doesn't
help you at all.
Regards
Marcel
Hi Luis.
Luis R. Rodriguez wrote:
> You started with: [...] This alone is an invitation for discussion
> between MadWifi and ath5k as supported drivers.
My original motivation is explained on [1]. In a few words: I wonder
whether the MadWifi project has a future, and if yes, what this future
could look like. This includes stuff like "what can the project (as an
entity) do to contribute to bringing ath[59]k forward" and "what can we do
to allow users for a smooth transition from MadWifi to ath[59]k".
I did start the survey in the hope that it helps to identify fields for
improvements, which could also be possible future tasks for the project.
The introduction to the survey is a description of the positions I saw as
answers on my "future of the project" post on the madwifi-project mailing
list. Not more, not less.
Although I have my own opinion an all this I've tried to keep a neutral
position. But to put it straight: I'm not trying to discredit the efforts
and advancements that have been made on ath[59]k. I do not intend to
question whether ath[59]k is the future. I do not intend to revive the
MadWifi (the driver) development in some way or the other, nor am I
promoting to add new features to MadWifi (the driver). And I do not intend
to play off ath5k against MadWifi. So please, stop to allege me of such
BS.
Bye, Mike
[1] http://article.gmane.org/gmane.linux.drivers.madwifi.project/165
Luis R. Rodriguez wrote:
> On Tue, Nov 17, 2009 at 1:44 PM, David Acker <[email protected]> wrote:
>> It is a non-802.11s protocol that predates 802.11s development by quite
>> awhile. It runs over WDS links. In theory it could run over anything that
>> supports dynamic creation and destruction of WDS links.
>
> So its a some sort of MadWifi-only hack?
Not at all. The algorithm runs in user space and has run over other
radio/driver combinations and even in networks of mixed radio types. I
don't see a problem with running it over ath5k. Basic functionality
should work fine.
The problem with switching to ath5k would be the loss of performance
related features (compression, fast frames, turbo), and some required
features (half/quarter rates are required for some channels on some
radios). Also, I don't know if ath5k will work on products based on
Atheros WiSOCs like Ubiquiti's PicoStation and Bullet. A lesser issue
(more of a pain for me than an ath5k issue) is that I have some
platforms that use an older kernel and moving up to a newer kernel will
have to be done without hardware vendor support.
-ack
On Tue, Nov 17, 2009 at 2:28 PM, David Acker <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>>
>> On Tue, Nov 17, 2009 at 1:53 PM, David Acker <[email protected]>
>> wrote:
>>> The problem with switching to ath5k would be the loss of
>>> performance related features (compression, fast frames, turbo),
>>
>> These are different than "mesh".
>
> Yes, but it would be good if these features were supported over WDS
> links (and on AP to STA links where both support the features).
Someone would just have to step up to:
1) implement these features
2) support them
>> So let me get this straight.
>>
>> You have SoC Atheros solutions that use some userspace custom (not
>> 802.11s) solution that use fast frames, compression and turbo, oh and
>> half/quarter rates? WTF are you doing?
>
> Lol, it isn't as crazy as it sounds. I have meshing running on various
> platforms. Some use miniPCI atheros based radios, some are SoC based. I
> believe I misspoke when I said half/quarter rates. It is better to say half
> width (10 MHz) or quarter width (5 MHz) channels.
OK well this could be supported, and welcomed someone just needs to work on it.
> There are several miniPCI
> based radios that require half or quarter width channels on some channels.
That *require* this?
> For example, the Ubiquiti XR7 requires quarter width channels on two of its
> four available channels.
Regulatory wise? What's the restriction based on?
> The XR9 requires half width channels on two if its
> four available channels.
Same here, what's the restriction based on?
I'll note that CRDA is channel agnostic, it just is cognizant of max
allowed regulatory width, whether you use smaller width channels is
left up to cfg80211 then. So supporting custom channel settings would
just be a matter of listing the supported hardware configurations of
list of channels and target widths.
>> For backporting we have compat-wireless, it should allow you to use even
>> today's bleeding edge even on 2.6.25. It should be possible to bring this
>> down to 2.6.21 even but not many people are interested in that it seems.
>> Patches are welcomed though.
>
> Thanks. I am trying to decide which is more painful: porting a recent
> kernel to the hardware or porting compat-wireless down to 2.6.18.
FWIW there are patches/code for 2.6.21..2.6.24 there is just a small
gap of code needed based on changes since circa 2.6.31 to add backport
support for 2.6.21..2.6.24. In other words -- it shouldn't be too bad
to get at least to 2.6.21. Not sure about 2.6.19 and 2.6.18 for PCI.
Luis
No reason to be more "pure" about this than the major manufacturers with FCC
/ CE certification (e.g. Motorola, Proxim, Trango, Tranzio, Ubiquiti, etc ).
Besides any liability lies with the manufacturer / installer, certainly not
Ath5k / Madwifi developers.
Tom S.
>>
>> Are you aware of any regulatory rules which prohibit narrower
>> channels? It just seems odd.
>
> No, I'm not aware of such limitations. OK, you are not aware of such
> limitations either, then perhaps we can go ahead with the narrow
> channels.
>
> --
> Regards,
> Pavel Roskin
>
On Tue, Nov 17, 2009 at 2:54 PM, Jouni Malinen <[email protected]> wrote:
> Supporting half/quarter width channels sounds reasonable in general. The
> main problem with this one seems to have been in getting someone
> dedicated enough to go through the effort in a way that would cleanly
> extend the regulatory framework in use with cfg80211.
I'll elaborate on this part.
There actually is no requirement to extend the regulatory framework to
get this done. What would need to be done is to extend cfg80211 to get
support for declaring varying channel width support and for a way to
tell cfg80211 which channels we want enabled for these settings -- or
figuring out a generic formula on cfg80211. The regulatory rules would
already be present on cfg80211 -- these would just be used to apply
the channe flags accordingly. I think there was also the theoretical
issues with regulatory bands which might overlap but we haven't yet
faced this issue yet AFAICT.
Luis
On Wed, Nov 18, 2009 at 02:08:16PM -0800, Luis R. Rodriguez wrote:
> Are you aware of any regulatory rules which prohibit narrower
> channels? It just seems odd.
I don't remember any rules that would explicitly do that, but there may
be some implicit limitations due to the slower TX rate. I don't know
whether this would hit anywhere, but at least quarter width channel with
1 Mbps TX rate and maximum frame length might get pretty close to some
maximum TX-without-sensing limits. Though, that is less likely to be an
issue on 5 GHz band due to 6 Mbps minimum TX rate even at quarter
channels could be fast enough. There could also be some rules that state
the minimum TX rate, so there could potentially be need to change
supported rate sets and/or fragmentation threshold in some corner cases.
Actually, even with 6/4 Mbps TX rate, the channel sensing rule in Japan
(carrier sense every 4 ms) (if that rule is still valid.. haven't
really checked), we could hit the limit with maximum frame length.
--
Jouni Malinen PGP id EFC895FA
On Tue, Nov 17, 2009 at 12:57 PM, Andrey Yurovsky <[email protected]> wrote:
> On Tue, Nov 17, 2009 at 9:40 AM, David Acker <[email protected]> wrote:
>>>> 1. What are you using MadWifi for?
>>
>> Wireless mesh on embedded systems.
I'm curious -- what type of Mesh were you talking about David? I
didn't know MadWifi supported 802.11s so don't know if that is what
you mean.
> FWIW ath5k has working draft-802.11s mesh mode, in fact it's one of
> the better-supported drivers.
Thanks for pointing that out Andrey.
Luis
On Tue, 2009-11-17 at 15:12 -0800, Luis R. Rodriguez wrote:
> On Tue, Nov 17, 2009 at 2:54 PM, Jouni Malinen <[email protected]> wrote:
>
> > Supporting half/quarter width channels sounds reasonable in general. The
> > main problem with this one seems to have been in getting someone
> > dedicated enough to go through the effort in a way that would cleanly
> > extend the regulatory framework in use with cfg80211.
>
> I'll elaborate on this part.
>
> There actually is no requirement to extend the regulatory framework to
> get this done.
I think we should try to err on the safe side when dealing with
regulations.
CRDA regulates the frequencies allocated for 802.11 protocol. Part of
the protocol is collision avoidance using RTS/CTS.
Stations using half and quarter channels won't see standard width
control frames. Likewise, standard stations won't be able to interpret
any narrow channel traffic. Thus, the stations using different channel
width affect each other as dumb noise emitters, somewhat like bluetooth
and even microwave ovens.
My impression is that many new bands are allocated for 802.11 under
strict conditions, such as power limits, DFS and TPC. TPC in particular
is designed to reduce interference between networks.
Is it true that no country limits transmissions in any band to the
standard channel width? Can we reasonably rely on things staying that
way?
--
Regards,
Pavel Roskin
On Tue, Nov 17, 2009 at 1:53 PM, David Acker <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>>
>> On Tue, Nov 17, 2009 at 1:44 PM, David Acker <[email protected]> wrote:
>>>
>>> It is a non-802.11s protocol that predates 802.11s development by quite
>>> awhile. It runs over WDS links. In theory it could run over anything
>>> that
>>> supports dynamic creation and destruction of WDS links.
>>
>> So its a some sort of MadWifi-only hack?
>
> Not at all. The algorithm runs in user space
OK so not relevant.
> The problem with switching to ath5k would be the loss of performance related
> features (compression, fast frames, turbo),
These are different than "mesh".
> and some required features
> (half/quarter rates are required for some channels on some radios).
How does "mesh" relate to this?
> Also, I
> don't know if ath5k will work on products based on Atheros WiSOCs like
> Ubiquiti's PicoStation and Bullet.
ath5k does not *yet* have SoC support but it may get it at later point.
So let me get this straight.
You have SoC Atheros solutions that use some userspace custom (not
802.11s) solution that use fast frames, compression and turbo, oh and
half/quarter rates? WTF are you doing?
> A lesser issue (more of a pain for me
> than an ath5k issue) is that I have some platforms that use an older kernel
> and moving up to a newer kernel will have to be done without hardware vendor
> support.
For backporting we have compat-wireless, it should allow you to use
even today's bleeding edge even on 2.6.25. It should be possible to
bring this down to 2.6.21 even but not many people are interested in
that it seems. Patches are welcomed though.
Luis
On Tue, Nov 17, 2009 at 05:28:32PM -0500, David Acker wrote:
> Luis R. Rodriguez wrote:
> >On Tue, Nov 17, 2009 at 1:53 PM, David Acker <[email protected]>
> >wrote:
> >>The problem with switching to ath5k would be the loss of
> >>performance related features (compression, fast frames, turbo),
> Yes, but it would be good if these features were supported over WDS
> links (and on AP to STA links where both support the features).
This type of vendor-specific extensions are somewhat difficult to get an
acceptable, clean implementation in mac80211; or well, at least it will
take major effort to convince the developers in why these should be
added. These Super A/G features have been discussed in the past and
there has not really been very enthusiastic support for adding them into
upstream mac80211/cfg80211..
Compression could, at least in theory, be done as a driver specific hack
(with somewhat ugly hack needed to handle negotiation for it in case of
AP/STA mode; could by statically configured for WDS links using the test
command, I think).
I don't see feasible path to get a clean implementation for fast frames
in mac80211. If you do not care about backwards compatibility with the
vendor-specific fast frames design, it would probably be much easier to
get A-MSDU aggregation (from 802.11n) implemented in mac80211 and then
as an additional option enable that with non-802.11n devices (that would
be the only part that is outside the context of the IEEE standard). This
would bring you something similar to fast frames that would potentially
be available with any mac80211-based driver.
I could see static turbo mode as a potential mode that could be
supported with ath5k if there is enough desire to do so. I would not go
with dynamic turbo mode, though.
> based. I believe I misspoke when I said half/quarter rates. It is
> better to say half width (10 MHz) or quarter width (5 MHz) channels.
> There are several miniPCI based radios that require half or quarter
> width channels on some channels. For example, the Ubiquiti XR7
> requires quarter width channels on two of its four available
> channels. The XR9 requires half width channels on two if its four
> available channels. Sorry for any confusion I created.
Supporting half/quarter width channels sounds reasonable in general. The
main problem with this one seems to have been in getting someone
dedicated enough to go through the effort in a way that would cleanly
extend the regulatory framework in use with cfg80211. The additional
complexity of not so common frequency range for 802.11 devices is going
to make this somewhat more difficult to get accepted, though, at least
in the case of these couple of examples, but just getting 10 MHz
channels working with the more standard frequency bands would sounds
like a reasonable step towards being able to support something like
this.
--
Jouni Malinen PGP id EFC895FA
On Wed, Nov 18, 2009 at 1:58 PM, Pavel Roskin <[email protected]> wrote:
> On Tue, 2009-11-17 at 15:12 -0800, Luis R. Rodriguez wrote:
>> On Tue, Nov 17, 2009 at 2:54 PM, Jouni Malinen <[email protected]> wrote:
>>
>> > Supporting half/quarter width channels sounds reasonable in general. The
>> > main problem with this one seems to have been in getting someone
>> > dedicated enough to go through the effort in a way that would cleanly
>> > extend the regulatory framework in use with cfg80211.
>>
>> I'll elaborate on this part.
>>
>> There actually is no requirement to extend the regulatory framework to
>> get this done.
>
> I think we should try to err on the safe side when dealing with
> regulations.
>
> CRDA regulates the frequencies allocated for 802.11 protocol.
Well we are only listing frequency ranges which the kernel can make
use of for 802.11 as that is what we use it for on the kernel. But if
wimax/bluetooth want to add some frequency range they can perfectly do
so.
> Part of the protocol is collision avoidance using RTS/CTS.
Don't see how this relates to regulatory rules.
> Stations using half and quarter channels won't see standard width
> control frames. Likewise, standard stations won't be able to interpret
> any narrow channel traffic. Thus, the stations using different channel
> width affect each other as dumb noise emitters, somewhat like bluetooth
> and even microwave ovens.
>
> My impression is that many new bands are allocated for 802.11 under
> strict conditions, such as power limits, DFS and TPC. TPC in particular
> is designed to reduce interference between networks.
>
> Is it true that no country limits transmissions in any band to the
> standard channel width? Can we reasonably rely on things staying that
> way?
So for now countries either take the FCC, are part of a larger group
like in Europe or are a head ache to deal with due to historical
changes on regulatory rules (Japan). So far I've seen rules set for
bands and with max EIRP and antenna gain. Sometimes you have quirky
rules for antenna gain like in the US for the 3:1 rule (but we don't
yet allow you to modify your antenna on linux and specific your new
dbi antenna gain, and this actually is assumed won't change on the
client side).
For width I'm told some countries do not allow HT40 and that this
should change in the future.
I haven't seen rules for finer level of control which is why I said I
we should not need to change anything. Right now I've only have heard
of countries sometimes disallowing HT40, but that's it.
Are you aware of any regulatory rules which prohibit narrower
channels? It just seems odd.
Luis
Bob Copeland wrote:
> On Tue, Nov 17, 2009 at 11:38 AM, Luis R. Rodriguez <[email protected]> wrote:
>
>> * DFS
>> * Multi-BSS AP functionality
>> * Roaming
>> * ANI
>
> Also antenna selection has been requested -- this is dead simple
> if anyone wants to write appropriate hooks into the stack for it.
> The code is already in the driver, it just needs some configuration
> glue.
>
I'm more than willing to attack adding the funtionality to ath5k, if someone else
is willing to design and implement the mac80211/nl80211 layer stuff. I tried
doing the half/quarter rate stuff, but got hung up in the higher level, eventually
giving up (with, I believe, working ath5k code for it). I'd code and test with
/debug options to get ath5k supporting the features, and then using the mac80211
hooks once they're provided.
Pat Erley
> On Sun, Nov 15, 2009 at 2:52 AM, Michael Renzmann
> <[email protected]> wrote:
>> Hi all.
>>
>> As you might have noticed, there currently is a discussion [1] going on
>> about the future directions of the MadWifi project, including a decision
>> how to deal with MadWifi driver. It turns out that there are pretty
>> contrary positions in this regard: some would like to see MadWifi being
>> dumped completely as soon as possible, others would prefer to continue
>> development and even implement new features.
>>
>> What do others think? It appears to me that we know too little about what
>> MadWifi is actually used for today and why. Thus I'd like to start a quick
>> survey.
>>
>> It would be great if you could answer some or - ideally - all of the
>> following questions:
>>
Personally, I would love to switch to ath5k but I am stuck using madwifi
due to a need for features that are missing on ath5k. I think the
issues I have are pretty common for the wireless router community. See
below for more details.
>> 1. What are you using MadWifi for?
Wireless mesh on embedded systems.
>>
>> 2. Did you already evaluate ath5k/ath9k? If no, why not?
I have monitored the list and saw significant issues with ath5k in AP
mode early on. AP mode and WDS mode are the main modes we use. We
rarely need client mode. Also, folks seemed resistant to adding all the
features of madwifi to ath5k/mac80211.
>>
>> 3. In case you evaluated ath5k/ath9k but did not yet switch: what is the
>> reason for your decision, and what is required before you could switch?
ath5k has been missing features that madwifi has and was reported as
very unstable in AP mode in the past. In some platforms I must use
older kernels (2.6.18) due to limited kernel support from an embedded
hardware vendor. In some setups I need DFS support. I need multiple
SSID support with each SSID supporting different crypto settings and I
need hardware crypto support. These were all issues at different times.
Some of them may be resolved at this point but they all existed (or
seemed to exist to me) at one point and convinced me to avoid working on
switching from madwifi to ath5k.
There was a thread not too long ago (
http://marc.info/?l=linux-wireless&m=125152150203308&w=2 ) that
discussed some features that are in madwifi but not in ath5k. I would
love to see dynamic and static turbo modes supported in ath5k. Half and
quarter rates are required to use certain channels on devices from
Ubiquiti (XR7 and XR9 for example). Fast frames and hardware
compression can also improve performance in certain situations.
Also, support for WiSOCs like the PicoStation and Bullet from Ubiquiti
would be required to switch from madwifi on those platforms.
-ack
David Acker wrote:
> Luis R. Rodriguez wrote:
>> On Tue, Nov 17, 2009 at 1:44 PM, David Acker <[email protected]> wrote:
>>> It is a non-802.11s protocol that predates 802.11s development by quite
>>> awhile. It runs over WDS links. In theory it could run over anything that
>>> supports dynamic creation and destruction of WDS links.
>>
>> So its a some sort of MadWifi-only hack?
>
> Not at all. The algorithm runs in user space and has run over other
> radio/driver combinations and even in networks of mixed radio types. I
> don't see a problem with running it over ath5k. Basic functionality
> should work fine.
>
> The problem with switching to ath5k would be the loss of performance
> related features (compression, fast frames, turbo), and some required
> features (half/quarter rates are required for some channels on some
> radios). Also, I don't know if ath5k will work on products based on
> Atheros WiSOCs like Ubiquiti's PicoStation and Bullet.
I have some work in progress patches for that. They won't work yet (in
fact I just ported them to a newer version of compat-wireless without
testing, so they probably won't even compile yet *g*), but according to
my rough estimation, they contain about 70-80% of what's necessary to
support this hw. You can find them at http://nbd.name/ath5k-wisoc.tar.gz
If anybody is seriously interested in hacking on this stuff, please take
a look at this patch series and contact me afterwards...
> A lesser issue
> (more of a pain for me than an ath5k issue) is that I have some
> platforms that use an older kernel and moving up to a newer kernel will
> have to be done without hardware vendor support.
What platforms with old kernels are you using? Maybe some of them are
being worked on in OpenWrt already ;)
- Felix