Thread: [Madwifi-users] Survey: What are you using MadWifi for, and why?
Status: Beta
Brought to you by:
otaku
From: Michael R. <mre...@ma...> - 2009-11-15 10:53:08
|
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 |
From: David A. B. <dav...@gm...> - 2009-11-15 15:02:50
|
On Sun, Nov 15, 2009 at 05:52, Michael Renzmann <mre...@ma...> 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? Atheros based mini-pci cards -- as clients and access points in the 5GHz range. > > 2. Did you already evaluate ath5k/ath9k? If no, why not? Yes. But for whatever reason (perhaps not enough time to RTFM) I haven't been able to get them to do what I need -- run the Atheros-based a/b/g cards in A. > > 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? Working in the 5GHz range, including using 4.92, 4.94, 4.96, and 4.98 GHz (two of which I have legally assigned to me in Panama) but for which neither madwifi nor ath5k handles for me at the moment -- so I use a proprietary solution with those cards. I am just about ready to try to hack the sources to get it to do what I want, but will probably first actually try to RTFM if the FM exists. > > Any input is highly welcome, thanks in advance for your time. > > Bye, Mike > > [1] http://thread.gmane.org/gmane.linux.drivers.madwifi.project/165 > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Madwifi-users mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-users > David A. Bandel -- Focus on the dream, not the competition. - Nemesis Air Racing Team motto Visit my blog at: http://www.pananix.com/cgi-bin/blosxom |
From: German C. <ger...@gm...> - 2009-11-16 08:32:17
|
On Sun, Nov 15, 2009 at 4:02 PM, David A. Bandel <dav...@gm...>wrote: > On Sun, Nov 15, 2009 at 05:52, Michael Renzmann > <mre...@ma...> 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? Evaluation of the handover process and its optimization > > > > > > 2. Did you already evaluate ath5k/ath9k? If no, why not? > Not yet. But I'm planning to do that. > > Yes. But for whatever reason (perhaps not enough time to RTFM) I > haven't been able to get them to do what I need -- run the > Atheros-based a/b/g cards in A. > > > > > 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? > I need to be sure that I can make packet capture on the physical layer in order to make cross layer optimisations > > Working in the 5GHz range, including using 4.92, 4.94, 4.96, and 4.98 > GHz (two of which I have legally assigned to me in Panama) but for > which neither madwifi nor ath5k handles for me at the moment -- so I > use a proprietary solution with those cards. I am just about ready to > try to hack the sources to get it to do what I want, but will probably > first actually try to RTFM if the FM exists. > > > > > Any input is highly welcome, thanks in advance for your time. > > > > Bye, Mike > > > > [1] http://thread.gmane.org/gmane.linux.drivers.madwifi.project/165 > > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > > trial. Simplify your report design, integration and deployment - and > focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Madwifi-users mailing list > > Mad...@li... > > https://lists.sourceforge.net/lists/listinfo/madwifi-users > > > > > David A. Bandel > -- > Focus on the dream, not the competition. > - Nemesis Air Racing Team motto > Visit my blog at: http://www.pananix.com/cgi-bin/blosxom > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Madwifi-users mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-users > -- GERMAN CASTIGNANI PhD Candidate Institut TELECOM / TELECOM Bretagne 2, rue de la châtaigneraie 35510 Cesson Sévigné Ph: +33 (0)2 99 12 70 52 |
From: elektra <one...@gm...> - 2009-11-16 11:51:32
|
Hi folks, I'm glad you are asking. Where I use it? Almost everywhere, but 99% of the time in ahdemo or IBSS mode. For the Villagetelco project / Mesh-Potato VOIP mesh nodes that will begin deployment in South Africa soon. Production of the units (beta series) will start now. These are based on a Atheros AR2317 SoC chip and have a FXS port. You can plug your old analog handset into the FXS port and do phone calls over a layer 3 mesh with Asterisk and the B.a.t.m.a.n. mesh routing protocol. Note that we are using Openwrt and Madwifi with numerous patches from Felix Fietkau. Guys from the Freifunk community (Felix Fietkau, Bruno Randolf, Sven Ola-Tücke) have been working on this driver for a long time. Ath5k is not yet an option since it is lacking support for this SoC. Also I'm missing many features - no ahdemo mode, can't set multicast/broadcast rate. However there are a few permanent bugs in Madwifi - fragmentation is still broken, and Madwifi IBSS nodes do send too many beacons. The mechanism that avoids sending redundant beacons is just not implemented AFAIK. Linux wireless development has done a excellent job - with recent kernels IBSS mode works nicely with a multitude of drivers. Actually I have seen problems in ath9k station mode while IBSS mode worked rock solid. :-) The sad days of serious IBSS bugs for Linux are over. Who needs point-to-multipoint mode if you can have multipoint-to-multipoint mode, anyway?! ;-) However there is only a minimum set of features supported by Linux wireless. For VOIP/mesh ahdemo mode and the possibility of setting the broadcast rate are important. (I want to limit the range and airtime consumption of mesh protocol broadcasts. No response to probe requests. Beacons are a bandwidth waste, particularly at basic rate) So I guess for the applications that I'm working on I'll stick to Madwifi until the Atheros 802.11abg chipsets phase out. Cheers, Elektra |
From: Tom S. <tsh...@qo...> - 2009-11-15 23:54:16
|
Mike, thanks for putting forward the effort to gather this input! I think you already know our feelings on this, but for the record my comments are inline below: > 1. What are you using MadWifi for? We have over 2000 shipped instances of madwifi running in unattended embedded x86 devices (Qcode, Qnode, MeshCam) in use at rural ISPs to provide internet connectivity services, and at various outdoor industrial and commercial facilities for backhaul of IP CCTV for surveillance purposes. Also several mixed networks doing ISP & CCTV, plus handheld scanners, voip, etc. > 2. Did you already evaluate ath5k/ath9k? If no, why not? No, because (a) it's too bleeding-edge for use in unattended devices (b) it's missing critical modes/features we need for our applications, and (c) it won't compile or run under a 2.4 kernel. > 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? n/a but see (2) above. Tom Sharples Qorvus Systems, Inc. > > Any input is highly welcome, thanks in advance for your time. > > Bye, Mike > > [1] http://thread.gmane.org/gmane.linux.drivers.madwifi.project/165 > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Madwifi-users mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-users |
From: Julio C. P. <jcp...@gm...> - 2009-11-16 00:26:37
|
2009/11/15 Michael Renzmann : > Hi all. Hi > [...] > > It would be great if you could answer some or - ideally - all of the > following questions: > > 1. What are you using MadWifi for? In LUGRo-Mesh we use it for the firmware that we created for our Wireless Mesh Network. We choose Atheros devices because of the possibility that MadWifi gives of using VAPs. > 2. Did you already evaluate ath5k/ath9k? If no, why not? No, because we use devices with an AHB bus. It's not supported in ath5k, and our devices are not 802.11 N. > [...] > Any input is highly welcome, thanks in advance for your time. > > Bye, Mike Saludos, Julio -- www.lugro-mesh.org.ar/ Wireless Mesh Networks Group www.lugro.org.ar GNU/Linux User Group Rosario, Argentina Slackware rulez :P www.slackware.org NO A LA MATRICULA!!!: http://noalamatricula.wordpress.com/ |
From: Hasan R. <ha...@di...> - 2009-11-16 19:30:09
|
Mike, 1. What are you using MadWifi for? I've customized Madwifi extensively to be used as a standard firmware in our copany. It is primarily used in WDS point-to-point and point-to-multipoint mode in a WISP setup. In our network, Atheros AR5212 are primarily used for 5 GHz backhaul links and 2.4 GHz distribution nodes. 2. Did you already evaluate ath5k/ath9k? If no, why not? Kind of, I looked at the feature set it supports and it doesn't quite have all that is needed in our network. Apart from that, it'll require a lot customization and testing to get to the point where we can consider deploying it. At this time I don't really see the need to switch from the customized Madwifi to ath5k/ath9k as it simply doesn't offer any significant advantages worth the time and effort to get it running stable in our network. 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? N/A Regards, Hasan R. Digital Path, Inc -----Original Message----- From: Michael Renzmann [mailto:mre...@ma...] Sent: Sunday, November 15, 2009 2:53 AM To: mad...@li... Cc: mad...@li... Subject: [Madwifi-devel] Survey: What are you using MadWifi for, and why? 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 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Madwifi-devel mailing list Mad...@li... https://lists.sourceforge.net/lists/listinfo/madwifi-devel |
From: Luis R. R. <mc...@gm...> - 2009-11-17 01:01:41
|
On Sun, Nov 15, 2009 at 2:52 AM, Michael Renzmann <mre...@ma...> 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 |
From: David A. <da...@ro...> - 2009-11-17 18:08:27
|
> On Sun, Nov 15, 2009 at 2:52 AM, Michael Renzmann > <mre...@ma...> 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 |
From: Andrey Y. <an...@co...> - 2009-11-17 21:18:34
|
On Tue, Nov 17, 2009 at 9:40 AM, David Acker <da...@ro...> 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 |
From: Holger S. <hol...@gm...> - 2009-11-17 08:45:02
|
> 1. What are you using MadWifi for? We're using it in STA mode only on fork-lift terminals as well as tablet PCs. > 2. Did you already evaluate ath5k/ath9k? If no, why not? Sure. I'm doing that also try to get changes into mainland kernel for features that are still missing. This "try to get changes" seems to work quite well, the developer community for Linux Wireless is mostly friendly and welcoming. Patches get commented, refused or accepted quite timingly. Generally, from a not-so-involved kernel developer, the linux-wireless community is nicer to work with compared to the madwifi community, where I made some (very small!) contributions two years ago. > 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? I still need to iron out some rought edges. For me, I need have scenarios with 20-70 APs and I need good roaming between them. That's not yet working correctly, current mac80211 is written in Starbucks-Mode (sit on a table, turn WIFI on, search one AP and stay with this AP while you slurp your coffee). -- http://www.holgerschurig.de |
From: John W. L. <lin...@tu...> - 2009-11-17 14:15:48
|
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 lin...@tu... might be all we have. Be ready. |
From: Marcel H. <ma...@ho...> - 2009-11-17 22:33:18
|
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 |
From: Michael R. <mre...@ma...> - 2009-11-17 16:04:53
|
[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 |
From: Luis R. R. <mc...@gm...> - 2009-11-17 16:39:43
|
On Tue, Nov 17, 2009 at 8:04 AM, Michael Renzmann <mre...@ma...> 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 |
From: Michael R. <mre...@ma...> - 2009-11-18 07:24:09
|
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 |
From: Tom S. <tsh...@qo...> - 2009-11-17 17:52:23
|
Comments inline: > > 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). We have way more users than this running just our version. There are probably tens of thousands of "users" (embedded systems) that run some flavor of madwifi. >> >> The development of any software should happen with the user's needs and >> requirements in mind > > Note I didn't say otherwise. Your comments, at best, give short shrift to the many, many embedded users, esp those who run the 2.4.x kernel. Does anyone actually think it would be practical to remotely upgrade tens of thousands of unattended devices, some of which are miles away from the nearest human, to a 2.6 kernel? Even if only 5% fail to come back online, it would be a logistical and customer-relations disaster. These aren't windows desktops where someone can just curse and then powercycle. > > 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 > You also need to add to this list: * Fast-frames * Compression * Half / quarter channels (hopefully done in a sensible fashion like AirOS without the countrycode / regdomain BS) We need to aknowledge that "user" includes not just those surfing on their laptops, but the far larger number of embedded devices running madwifi each and every day, in critical systems, with excellent reliability. Tom S. |
From: Luis R. R. <mc...@gm...> - 2009-11-17 18:06:14
|
On Tue, Nov 17, 2009 at 9:51 AM, Tom Sharples <tsh...@qo...> wrote: > Comments inline: >> >> 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). > > We have way more users than this running just our version. There are > probably tens of thousands of "users" (embedded systems) that run some > flavor of madwifi. Haha are you really trying to out count modern Linux kernel users with MadWifi embedded users? >>> The development of any software should happen with the user's needs and >>> requirements in mind >> >> Note I didn't say otherwise. > > Your comments, at best, give short shrift to the many, many embedded users, > esp those who run the 2.4.x kernel. Does anyone actually think it would be > practical to remotely upgrade tens of thousands of unattended devices, some > of which are miles away from the nearest human, to a 2.6 kernel? What do you expect to get out of MadWifi at this point if not just maintenance mode support for that box you cannot even upgrade a full kernel on that is miles away from any human being? > Even if > only 5% fail to come back online, it would be a logistical and > customer-relations disaster. These aren't windows desktops where someone can > just curse and then powercycle. You can perfectly stick to what you have, like I said no one is forcing you to do anything different, but failing to understand that MadWifi development has come to a stand still maintenance mode would be just as ludicrous as expecting you to upgrade every single box you have out there. >> 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 >> > You also need to add to this list: > > * Fast-frames > * Compression Not sure if the above are vendor extensions, if so and if they require some tweaking on mac8021 chances are you won't get them upstream. > * Half / quarter channels (hopefully done in a sensible fashion like AirOS > without the countrycode / regdomain BS) As far as its supported by IEEE this seems reasonable, you just need motivated developers. > We need to aknowledge that "user" includes not just those surfing on their > laptops, but the far larger number of embedded devices running madwifi each > and every day, in critical systems, with excellent reliability. Sure, but just as with MadWifi if you don't have embedded interested developers on MadWifi you won't get them on ath5k. What should also be realized though is that not every single knob and feature of MadWifi will make it upstream. Anything vendor specific or hackish will simply not make it up -- unless you really have a motivated developer willing to support it. Luis |
From: David G. <dav...@bt...> - 2009-11-17 19:56:10
|
On Tuesday 17 November 2009, Luis R. Rodriguez wrote: > On Tue, Nov 17, 2009 at 9:51 AM, Tom Sharples <tsh...@qo...> wrote: > > Comments inline: > >> 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). > > > > We have way more users than this running just our version. There are > > probably tens of thousands of "users" (embedded systems) that run some > > flavor of madwifi. > > Haha are you really trying to out count modern Linux kernel users with > MadWifi embedded users? > > >>> The development of any software should happen with the user's needs and > >>> requirements in mind > >> > >> Note I didn't say otherwise. > > > > Your comments, at best, give short shrift to the many, many embedded > > users, esp those who run the 2.4.x kernel. Does anyone actually think it > > would be practical to remotely upgrade tens of thousands of unattended > > devices, some of which are miles away from the nearest human, to a 2.6 > > kernel? > > What do you expect to get out of MadWifi at this point if not just > maintenance mode support for that box you cannot even upgrade a full > kernel on that is miles away from any human being? > > > Even if > > only 5% fail to come back online, it would be a logistical and > > customer-relations disaster. These aren't windows desktops where someone > > can just curse and then powercycle. > > You can perfectly stick to what you have, like I said no one is > forcing you to do anything different, but failing to understand that > MadWifi development has come to a stand still maintenance mode would > be just as ludicrous as expecting you to upgrade every single box you > have out there. > > >> 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 > > > > You also need to add to this list: > > > > * Fast-frames > > * Compression > > Not sure if the above are vendor extensions, if so and if they require > some tweaking on mac8021 chances are you won't get them upstream. > > > * Half / quarter channels (hopefully done in a sensible fashion like > > AirOS without the countrycode / regdomain BS) > > As far as its supported by IEEE this seems reasonable, you just need > motivated developers. > > > We need to aknowledge that "user" includes not just those surfing on > > their laptops, but the far larger number of embedded devices running > > madwifi each and every day, in critical systems, with excellent > > reliability. > > Sure, but just as with MadWifi if you don't have embedded interested > developers on MadWifi you won't get them on ath5k. What should also be > realized though is that not every single knob and feature of MadWifi > will make it upstream. Anything vendor specific or hackish will simply > not make it up -- unless you really have a motivated developer willing > to support it. > > Luis > > --------------------------------------------------------------------------- > --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment - > and focus on what you do best, core application coding. Discover what's > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > Luis, I think in this answer you answered the question as to why some people use MadWifi rather than athXk - ignoring people stuck on old kernels. The answer is in large part that they want the bits that are not in the standards and therefore will never make it into the kernel. Why do they want then, because they solve a problem; why are they not part of the standards, because the orgainizing committee did not think of them. My guess is that if enough people work on these extensions and show that they are useful then it is just possible that they will be recognised by said committee and be included. But if course if they do not get the chance because nothing that has not come from the committee is allowed then no progress! In short if athXk (and the common code) allowed extensions, and provided a means for them to be added the future need for madwifi might be minimal. But if the extensions are continually rejected then madwifi will continue and frankly whether it is ever included in the mainline kernel is irrelevant. David |
From: Luis R. R. <mc...@gm...> - 2009-11-17 21:37:32
|
On Tue, Nov 17, 2009 at 12:57 PM, Andrey Yurovsky <an...@co...> wrote: > On Tue, Nov 17, 2009 at 9:40 AM, David Acker <da...@ro...> 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 |
From: David A. <da...@ro...> - 2009-11-17 21:44:47
|
Luis R. Rodriguez wrote: > On Tue, Nov 17, 2009 at 12:57 PM, Andrey Yurovsky <an...@co...> wrote: >> On Tue, Nov 17, 2009 at 9:40 AM, David Acker <da...@ro...> 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 |
From: Luis R. R. <mc...@gm...> - 2009-11-17 21:46:00
|
On Tue, Nov 17, 2009 at 1:44 PM, David Acker <da...@ro...> wrote: > Luis R. Rodriguez wrote: >> >> On Tue, Nov 17, 2009 at 12:57 PM, Andrey Yurovsky <an...@co...> >> wrote: >>> >>> On Tue, Nov 17, 2009 at 9:40 AM, David Acker <da...@ro...> 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 |
From: David A. <da...@ro...> - 2009-11-17 21:53:26
|
Luis R. Rodriguez wrote: > On Tue, Nov 17, 2009 at 1:44 PM, David Acker <da...@ro...> 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 |
From: Luis R. R. <mc...@gm...> - 2009-11-17 22:04:37
|
On Tue, Nov 17, 2009 at 1:53 PM, David Acker <da...@ro...> wrote: > Luis R. Rodriguez wrote: >> >> On Tue, Nov 17, 2009 at 1:44 PM, David Acker <da...@ro...> 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 |
From: David A. <da...@ro...> - 2009-11-17 22:28:48
|
Luis R. Rodriguez wrote: > On Tue, Nov 17, 2009 at 1:53 PM, David Acker <da...@ro...> > wrote: >> Luis R. Rodriguez wrote: >>> On Tue, Nov 17, 2009 at 1:44 PM, David Acker <da...@ro...> >>> 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. |