23.02.2018 14:32, Johannes Berg wrote:
On Thu, 2018-02-22 at 12:15 +0300, Sergey Matyukevich wrote:
+ * @NL80211_EXT_FEATURE_DFS_OFFLOAD: HW/driver will offload DFS actions.
+ * Device or driver will do all DFS-related actions by itself,
+ * informing user-space about CAC progress, radar detection event,
+ * channel change triggered by radar detection event.
+ * No need to start CAC from user-space, no need to react to
+ * "radar detected" event.
The "channel change" part bothers me a bit - isn't normally hostapd
very much in control of the channel? How does it even get notified of
the new channel? How can you configure the parameters like how many
beacons to include the (E)CSA IE for, and whether to add ECSA or not
etc?
johannes
hostapd will be notified with NL80211_CMD_CH_SWITCH_NOTIFY event
and it already has a handler for this event and looks like it works as
expected.
In case of radar detection, userspace (hostapd) should receive two
events (with DFS offload enabled):
1. RADAR_DETECT - and in case of DFS_OFFLOAD flag turned on don't do any CSA
2. CH_SWITCH_NOTIFY - at the moment when HW will switch channel as a
reaction
to radar event
Currently, all CSA will be sent with default parameters. If it's crucial
to tune e.g. TBTT
count, then let's add it with a separate commit later, when DFS offload
will be
implemented in the whole SW stack (driver/kernel/userspace).
DFS offload should be quite useful and should fix some issues in a
repeater configuration.
There are a number of issues which are hard to fix without DFS offload
feature:
e.g. if repeater has detected a radar and sent radar report frame to
master AP,
master AP will reply with CSA, but hostapd will try to change channel to
different channel.
Regards,
Dmitry
