Search Linux Wireless

Re: [PATCH v7 2/3] nl80211: additional processing in NL80211_CMD_SET_BEACON

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/18/2023 7:57 AM, Johannes Berg wrote:
On Wed, 2022-11-09 at 13:47 -0800, Aloka Dixit wrote:
FILS discovery and unsolicited broadcast probe response transmissions
are configured as part of NL80211_CMD_START_AP, however both stop
after userspace uses the NL80211_CMD_SET_BEACON command as these
attributes are not processed in that command.

That seems odd. Why would that *stop*? Nothing in the driver should
actually update it to _remove_ it during change_beacon()?
> Are you sure you didn't mean to "just" say "however both cannot be
updated as these attributes ..."?

johannes

FILS discovery has primary channel, center frequency in the frame format which should be changed depending on why the beacon changed. Hence the current design, at least ath11k, assumes that BSS_CHANGED_FILS_DISCOVERY and BSS_CHANGED_UNSOL_BCAST_PROBE_RESP "not being set", when beacon is changed, means disable these features.
What do you think?

Like you said, we still need this code to update these templates if provided by the userspace, e.g. in case of channel switch.

Should I send a follow-up with a different commit log?

Thanks.



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux