From: David Goodenough <david.goodenough@bt...> - 2008-09-17 08:49:25
On Wednesday 17 September 2008, Nick Kossifidis wrote:
> 2008/9/17 Michael Renzmann <mrenzmann@...>:
> >> I believe that ath5k will be much better and that by Christmas with
> >> help from Atheros (we are looking fw for that) it 'll be much better
> >> than current MadWiFi (without support for special stuff like
> >> turbo/dturbo/fastframes/compression for now).
> > What's the status of monitor mode support? AP and IBSS mode? Are there
> > any plans yet to add multi-vap support to mac80211 (I think this is one
> > of the killer features of MadWifi)?
> 1) Monitor mode works, kismet works, no problem there. You can create
> a separate monitor interface just like with MadWiFi (check out iw
> tool, it's like our wlanconfig
> 2) AP mode works but it's under review/testing (Jiri provided a patch
> some time ago that worked -check this out
> http://forum.openwrt.org/viewtopic.php?id=16244 - but it needs to be
> updated due to mac80211 changes, then we need to test it on all hw
> just to be sure). Have in mind that AP mode is mostly handled by
> hostapd so you have wpa/acl etc out of the box.
> 3) I haven't tested IBSS mode for a while but in mac80211 we have
> 802.11s support so no need to worry about IBSS anymore (mac80211
> supports IBSS, ath5k supports it, even if it's broken right now it
> shouldn't be hard to fix -at least not harder than MadWiFi-).
> 4) VAPs (multiple SSIDs on the same BSSID) are also handled by hostapd
> as part of AP support (unfortunately open-source version of hostapd
> doesn't support that feature yet), mac80211 is ready for this as far
> as i know (check out AP VLANs) so consider this as work in progress.
> >> You can't make MadWiFi better but you CAN make ath5k better...
> > Remember: we are not talking of making MadWifi better. The idea instead
> > was (at least back in autumn 2007) to *stabilize* MadWifi in a way that
> > it would work for most users and thus helps to bridge the time until
> > ath5k is more or less up to par.
> > Did we really change this objective? I don't think so, but maybe I'm
> > wrong. However, it seems that we failed to reach this goal so far. And
> > from your description of the status quo of ath5k, we probably should
> > reconsider whether it's worth to continue sticking to this objective.
> > Comments?
> > Bye, Mike
> I think we are wasting resources on trying to stabilize MadWiFi, if
> team spends more time on ath5k then we 'll have a better solution out
> there faster. If team keeps trying to stabilize MadWiFi then ath5k
> will stall and MadWiFi *might* get a little better. I think that if
> MadWiFi doesn't get any better until December, we should just drop it
> and focus on ath5k completely. I 'll try to make ath5k much better on
> the hw part until then so you won't have to worry about this (we 'll
> have Atheros support also).
> In general it's much easier to debug a fully open source driver than a
> semi-open-source driver, problems on ath5k can be fixed much faster
> than on MadWiFi. Just think about it...
As a matter of interest, what is the status of DFS on ath5k and ath9k?