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.. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
