Hey Zefir, On Thu, Jan 31, 2013 at 09:52:33AM +0100, Zefir Kurtisi wrote: > On 01/30/2013 05:25 PM, Simon Wunderlich wrote: > Hey Simon, > > all my comments were based on a centralized frequency manager I implemented for > our system (in user-space) and my assumption that its functionality should be > portable to mac80211, i.e. channel states being managed by reg.c and wdevs being > continuously notified on state changes. > > Take a setup where you have two cards running, one as master and the other as > monitor doing off-channel-CAC. If the monitor detects radar on the master's > operating channel (and the master doesn't), with the current implementation the > master can't be notified to switch. I understand that supporting this very > specific use-case would add unjustifiable complexity, while at the same time, with > the updates you made this can be achieved at higher layers - so it is good enough > as it is. OK ... yeah I guess there are some things which can be handled in userspace. Interaction between userspace programs will be a topic later anyways, think of say wpa_supplicant and hostapd to handle IBSS and AP interface, one of them (or both?) receive a radar event and now have to negotiate the next channel ... :) > > > Looking forward your patches to get integrated soon, to allow people actually > testing DFS. I'm eagerly waiting for more active testers to share some ugly > problems I am observing with ath9k's pulse detector. Therefore: full ACK. Thanks a lot! I've got quite a few mails of people offering their help to check and verify this implementation or test it in their country. :) If you want to help in the integration for ath9k, I'd be glad ... the interface should be rather simple so maybe we don't have too much hassle? I have a little patch for ath9k to add dummy radar support and simulate events etc as baseline, if you (or anyone else) is interested ... Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
