On 01/23/2013 01:52 PM, Simon Wunderlich wrote: > On Mon, Jan 21, 2013 at 11:46:20AM +0100, Zefir Kurtisi wrote: > [...] > >> Why then bother with CAC at all, one might think. In fact, exploiting given >> requirements to such extent is mandatory to make operation on DFS channels usable >> (which btw. is not the scope of the patches discussed here). >> > > I would actually like to make operation on DFS channels usable by using the implementation > from these patches. :) Do you imply that we couldn't practically use it? Any suggestions > what can be improved? > > Cheers, > Simon > Hi Simon, I realize that my last statement is misleading, given that there are different levels for being 'usable'. The current DFS master support will allow to certify, but how usable will those devices will operate? I'll try to explain my concerns based on what is needed for the products I am currently working on. It got longish, so here is the short version. tl;dr: we can't integrate DFS support for managed master devices in Linux wireless, since that requires breaking the existing regulatory statement. The long version bases on the fact that in any setup we will face false radar events that are degrading usability. The inevitability of false detections is given by the existence of interferences not distinguishable from radar pulses and the regulatory requirement to detect incomplete patterns with a given probability. Set up as radar monitor, we measured false detections between once a day and several per hour. This is the best case, since in master mode the numbers significantly increase (traffic type dependent). These observations were done with Atheros hardware, but given their general cause, lets deal with regular false events we need to handle. So, who is going to use DFS channels and how? It is maybe not the home user, who will disable them as soon as he looses connectivity for minutes again - he can do just fine with non-DFS channels (that's maybe why there are so few consumer products with working DFS support out there). Industrial applications however depend on using them for their higher tx power allowed and to escape the crowded non-DFS channels. At the same time, they do not tolerate service interruption: our devices are controlling trains over WiFi - and you do not want them to stop on every CAC ;) Obviously, the only way to achieve continuous connectivity on DFS channels is to go the managed approach combining master and sensor nodes. There, on top of what you and Johannes already discussed (re-use wiphy0's CAC results for wiphy1), you need to be able to re-use the channel information of nearby nodes. And that's finally my point: to be able to skip CAC for a DFS channel based on external information, you need to provide means to override your own channel states - which in turn allows to bypass regulatory requirements and therefore breaks the Linux wireless regulatory statement. I don't see an easy way to expose those mechanisms to manufacturers but prevent mis-use by the 'common user'. Are there? Cheers, Zefir -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
