Re: [PATCH] New functionality for aborting ongoing CAC.
You are right, it is possible to do it as you comment
(NL80211_CMD_STOP_AP and then NL80211_CMD_START_AP). It is therefore
not necessary a specific command to abort the CAC.
Thank you very much for the clarification and the time spent.
PS: If you use OpenWRT you have to control the STOP and the START, the
command "wifi" does not work properly.
El mié., 26 sept. 2018 a las 11:26, Johannes Berg
() escribió:
>
> On Tue, 2018-09-25 at 10:19 +0200, Enrique Giraldo wrote:
> > Add NL80211_CMD_ABORT_CAC to the nl80211 interface.
>
> As Arend pointed out, this really needs a much better commit message.
>
> Please also adjust the subject to have a proper prefix etc. See
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
> for some help with that.
>
> > @@ -3227,6 +3228,7 @@ struct cfg80211_ops {
> > int (*scan)(struct wiphy *wiphy,
> > struct cfg80211_scan_request *request);
> > void(*abort_scan)(struct wiphy *wiphy, struct wireless_dev *wdev);
> > + void(*abort_cac)(struct wiphy *wiphy, struct wireless_dev *wdev);
>
> This is fine, you can add in the middle of the struct.
>
> >
> > @@ -1220,6 +1223,7 @@ enum nl80211_commands {
> > NL80211_CMD_WIPHY_REG_CHANGE,
> >
> > NL80211_CMD_ABORT_SCAN,
> > + NL80211_CMD_ABORT_CAC,
> >
> > NL80211_CMD_START_NAN,
>
> This is *not* OK, as the comments here indicate, we must never add
> anything in the middle of this enum, doing so breaks userspace ABI.
>
> johannes
Re: [PATCH] New functionality for aborting ongoing CAC.
On Tue, 2018-09-25 at 10:19 +0200, Enrique Giraldo wrote:
> Add NL80211_CMD_ABORT_CAC to the nl80211 interface.
As Arend pointed out, this really needs a much better commit message.
Please also adjust the subject to have a proper prefix etc. See
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
for some help with that.
> @@ -3227,6 +3228,7 @@ struct cfg80211_ops {
> int (*scan)(struct wiphy *wiphy,
> struct cfg80211_scan_request *request);
> void(*abort_scan)(struct wiphy *wiphy, struct wireless_dev *wdev);
> + void(*abort_cac)(struct wiphy *wiphy, struct wireless_dev *wdev);
This is fine, you can add in the middle of the struct.
>
> @@ -1220,6 +1223,7 @@ enum nl80211_commands {
> NL80211_CMD_WIPHY_REG_CHANGE,
>
> NL80211_CMD_ABORT_SCAN,
> + NL80211_CMD_ABORT_CAC,
>
> NL80211_CMD_START_NAN,
This is *not* OK, as the comments here indicate, we must never add
anything in the middle of this enum, doing so breaks userspace ABI.
johannes
Re: [PATCH] New functionality for aborting ongoing CAC.
What you commented was the first thing that I tried, but doing it, the radio stays in an inconsistent state and the hostapd is not able to raise an instance again. Attached is the log of what is happening: Tue Sep 25 09:58:10 2018 daemon.notice hostapd: wlan0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=1, seg0=106, seg1=0, cac_time=60s Tue Sep 25 09:58:29 2018 daemon.notice hostapd: wlan0: DFS-CAC-COMPLETED freq=5500 success=0 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0 Tue Sep 25 09:58:29 2018 daemon.notice hostapd: wlan0: INTERFACE-DISABLED Tue Sep 25 09:58:29 2018 kern.info kernel: [ 70.650485] br-lan: port 3(wlan0) entered disabled state Tue Sep 25 09:58:29 2018 kern.info kernel: [ 70.665228] device wlan0 left promiscuous mode Tue Sep 25 09:58:29 2018 kern.info kernel: [ 70.669794] br-lan: port 3(wlan0) entered disabled state Tue Sep 25 09:58:30 2018 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf Tue Sep 25 09:58:31 2018 kern.warn kernel: [ 72.295668] ath10k_pci :00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 Tue Sep 25 09:58:31 2018 kern.info kernel: [ 72.312713] ath10k_pci :00:00.0: wmi print 'P 128 V 8 T 410' Tue Sep 25 09:58:31 2018 kern.info kernel: [ 72.318911] ath10k_pci :00:00.0: wmi print 'msdu-desc: 912 sw-crypt: 0' Tue Sep 25 09:58:31 2018 kern.info kernel: [ 72.326063] ath10k_pci :00:00.0: wmi print 'alloc rem: 38688 iram: 27140' Tue Sep 25 09:58:31 2018 daemon.notice hostapd: wlan0: INTERFACE-ENABLED Tue Sep 25 09:58:31 2018 kern.info kernel: [ 72.402994] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Tue Sep 25 09:58:31 2018 daemon.notice hostapd: wlan0: INTERFACE-DISABLED Tue Sep 25 09:58:31 2018 daemon.err hostapd: nl80211: Could not configure driver mode Tue Sep 25 09:58:31 2018 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0 Tue Sep 25 09:58:31 2018 daemon.err hostapd: nl80211 driver initialization failed. Tue Sep 25 09:58:31 2018 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->DISABLED Tue Sep 25 09:58:31 2018 daemon.notice hostapd: wlan0: AP-DISABLED Tue Sep 25 09:58:31 2018 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING Tue Sep 25 09:58:31 2018 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started Tue Sep 25 09:58:31 2018 daemon.notice netifd: radio0 (1809): WARNING (wireless_add_process): executable path /usr/sbin/hostapd does not match process 1640 path () Tue Sep 25 09:58:31 2018 daemon.notice netifd: radio0 (1809): Device setup failed: HOSTAPD_START_FAILED Regards, EG El mar., 25 sept. 2018 a las 11:53, Arend van Spriel () escribió: > > On 9/25/2018 11:28 AM, Enrique Giraldo wrote: > > The main reason is to be able to stop the CAC when you want to make a > > channel switch and the CAC is ongoing. It's true that the radio would > > not pass to the next phase, the behavior is the same as when during > > the CAC a radar event is detected. In the case of aborting, a later > > action is expected, for example, switch to the desired new channel. > > So for mac80211 the function ieee80211_dfs_cancel_cac() indeed seems to > just abort. So what is the scenario here? If user-space sends > NL80211_CMD_START_AP with DFS channel, a CAC period is started. So you > are saying you want to do a channel switch? Does it not make sense to > issue a NL80211_CMD_STOP_AP and then NL80211_CMD_START_AP for the > desired channel? Maybe the use-case you are looking at is not AP mode, > but there is no context whatsoever in the commit message so I can only > guess. > > Regards, > Arend >
Re: [PATCH] New functionality for aborting ongoing CAC.
On 9/25/2018 11:28 AM, Enrique Giraldo wrote: The main reason is to be able to stop the CAC when you want to make a channel switch and the CAC is ongoing. It's true that the radio would not pass to the next phase, the behavior is the same as when during the CAC a radar event is detected. In the case of aborting, a later action is expected, for example, switch to the desired new channel. So for mac80211 the function ieee80211_dfs_cancel_cac() indeed seems to just abort. So what is the scenario here? If user-space sends NL80211_CMD_START_AP with DFS channel, a CAC period is started. So you are saying you want to do a channel switch? Does it not make sense to issue a NL80211_CMD_STOP_AP and then NL80211_CMD_START_AP for the desired channel? Maybe the use-case you are looking at is not AP mode, but there is no context whatsoever in the commit message so I can only guess. Regards, Arend
Re: [PATCH] New functionality for aborting ongoing CAC.
The main reason is to be able to stop the CAC when you want to make a channel switch and the CAC is ongoing. It's true that the radio would not pass to the next phase, the behavior is the same as when during the CAC a radar event is detected. In the case of aborting, a later action is expected, for example, switch to the desired new channel. Regards, EG El mar., 25 sept. 2018 a las 10:52, Arend van Spriel () escribió: > > On 9/25/2018 10:19 AM, Enrique Giraldo wrote: > > Add NL80211_CMD_ABORT_CAC to the nl80211 interface. > > This one really needs a good motivation. The CAC duration is a hard > requirement so aborting it means that the radio can not proceed to the > next phase. You really need to describe your reasoning for wanting this > in the commit message. > > Regards, > Arend
Re: [PATCH] New functionality for aborting ongoing CAC.
On 9/25/2018 10:19 AM, Enrique Giraldo wrote: Add NL80211_CMD_ABORT_CAC to the nl80211 interface. This one really needs a good motivation. The CAC duration is a hard requirement so aborting it means that the radio can not proceed to the next phase. You really need to describe your reasoning for wanting this in the commit message. Regards, Arend
