On Wed, 2013-10-02 at 14:40 +0200, Simon Wunderlich wrote: > > > NL80211_ATTR_CONTROL_PORT_DFS attribute when joining the IBSS. > > > > I don't like that name, it makes no sense. This has nothing to do with > > the port control (802.1X-style) at all. > > How about NL80211_ATTR_DFS_CAPABLE instead? That seems also confusing, like a hardware capability or something... Maybe rather "NL80211_ATTR_HANDLE_DFS" or something? > Yeah, I should document this a little more: Userspace should react to > radar events and apprioately switch the channel when this happens. As > non-capable tools (like wpa_supplicant in it's current state) do not > react on radar events but might select DFS channels when available, there > might be non-conforming behaviour. Therefore I'm introducing this flag. > > Userspace programs are supposed to set this flag when they have channel > management and radar avoidance/channel change functionality is implemented > to unlock DFS channels. I think we may we want some safeguard, e.g. only give the userspace a second or so to react and tear down the IBSS otherwise? Even with userspace that is capable of handling it, it could have crashed and the IBSS will continue operating in that case since we don't tear down the IBSS when it crashes. Or we could do that, require userspace to keep the nl80211 socket open, but the timing seems easier? > I can resend the patchset with some more documentation on this. Thanks. johannes -- 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
