On Tue, Oct 01, 2013 at 01:09:17PM +0200, Johannes Berg wrote: > On Tue, 2013-09-03 at 19:43 +0200, Simon Wunderlich wrote: > > To use DFS in IBSS mode, userspace is required to react to radar events. > > It can inform nl80211 that it is capable of doing so by adding a > > 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? > > If this attribute is supplied, DFS channels may be used if the driver > > supports it. Support will be checked even if a channel without DFS will > > be joined, as the channel might change later due to scan activity or > > channel switch announcements. > > You also really should document *what* is required of userspace here. > You're kinda saying this needs to be implemented, but not saying what > needs to be done. I can't even tell - what does it really have to do? 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. > Don't you implement most of it in patches 3 and 4 anyway in the kernel? Nope, I don't. I can resend the patchset with some more documentation on this. Thanks, Simon
Attachment:
signature.asc
Description: Digital signature
