[PATCH 1/2] hostapd: add support for unicast beacons

[Raphaël Mélotte]

On 2/1/23 17:48, Jouni Malinen wrote:
> That would be explicitly non-compliant with the standard: IEEE Std
> 802.11-2020, 11.1.3.1: "The Address 1 field of the Beacon or Timing
> Advertisement frame shall be set to the broadcast address."
> 
> In addition to not being allowed, this would sound like a potentially
> quite bad thing to allow on the non-AP STA side since using unicast
> Beacon frames might be sufficient to bypass beacon protection (which is
> defined using BIP that works only with group-addressed frames) and
> because this could be used for targeted attacks against a single non-AP
> STA in the BSS. In other words, I'd recommend non-AP STA implementations
> to discard any received Beacon frame if Address 1 is not broadcast.
> 
> In addition to this, I doubt this would work correctly with most
> existing driver implementations on the transmitter side. In particular,
> power save buffering of group addressed frames or anything else that is
> gated on Beacon frame transmission might get quite interesting if there
> is suddenly an expectation of having to retransmit the Beacon frame due
> not having received an ACK frame for it.

Interesting, thank you for the feedback.

I realize I also didn't provide the context when submitting this
patch: this was also needed for the "Virtualized BSSs" feature
described in an informative appendix of EasyMesh R5 (Appendix B),
which mentions:

"""
Multi-AP Agents target VBSS to individual clients via unicast beacons instead of broadcast beacons. Because the
beacons are unicast, clients will respond with ACKs, thus allowing the Multi-AP Agents to possibly adjust the MCS of the
unicast beacons to make better use of the channel airtime.
"""

I guess this part will be revisited..