Short beaconing is a feature within S1G that allows beacons to contain a limited set of elements, significantly decreasing beacon size. This set of patches adds support for short beaconing within mac80211 and cfg80211 aswell as mac80211_hwsim. Preface: Previously, some work was done ~2 years ago to get short beaconing in the kernel but it was never successful. The patches can be found here: 1/2: https://patchwork.kernel.org/project/linux-wireless/patch/20230810093556.33800-1-bassem@xxxxxxxxxxxxxx/ 2/2: https://patchwork.kernel.org/project/linux-wireless/patch/20230810093556.33800-2-bassem@xxxxxxxxxxxxxx/ As a result of this, we have independently rewritten the patchset based on feedback from the last attempt. Implementation: Note that all standards exerts reference below are from IEEE80211-2024. (1) S1G long beacons: What makes S1G long beacons "weird" is that functionally, they are the same as regular beacons - however they are defined as a type of extension frame in the standard. While they do slightly differ in terms of how they are parsed due to variable length optional elements, as of now the way they are treated by mac80211 is equivalent to regular beacons. This leads to a decision whether we build out some new infrastructure to parse and store S1G long beacons separately or use the existing beacon path (from cfg80211 all the way to beacon retrieval). We have opted to use the existing code paths as there is already support for parsing S1G beacons in the validate_beacon_head path and no changes are required for S1G long beacons as functionally they are equivalent to regular beacons. There is something to say regarding whether this is "correct" as after all they are extension frames and while we feel this is the best approach when all factors are taken into account - ultimately it is up to maintainers to decide. (2) S1G short beacons: Short beacons on the other hand are indeed functionally different to long beacons alongside being optional. Primarily related to the fact that the set of elements available to them is different to long beacons and thus separate validation is required. We have based the implementation on Alokas FILS Discovery patchset: https://lore.kernel.org/linux-wireless/1912863dcd17aa50b09d1ddfc889478eb323f901.camel@xxxxxxxxxxxxxxxx/T/#m86511f184d40ab36221f4ceae066900233ceb84e We have created a new nested attribute specifically for the short beacon data alongside the various BSS parameters needed. This comes with new validation policies for both the beacon elements and the beacon head to ensure only elements permitted in a short beacon are used. In addition, we also prevent short beacons from being sent down the regular beacon path and vice versa. We then introduce cfg80211_s1g_short_beacon and s1g_short_beacon_data which store the related short beacon data, where the former is used on AP bring up and to initialise the BSS related information and the latter used when retrieving a beacon. This keeps the optional short beacon related data separate from the beacon_data type which makes sense as it is optional, aswell as introduces it into the cfg80211_ap_update structure for beacon updates such as an SSID change which may change the short beacon template if it contains a CSSID field. (3) S1G BSS: When an S1G BSS is initialised with short beaconing enabled, the standard dictates a few things: 9.4.2.5.1: "If dot11ShortBeaconInterval is equal to true, the DTIM Period field is set to dot11ShortBeaconDTIMPeriod. If dot11ShortBeaconInterval is equal to false, the DTIM Period field is set to dot11DTIMPeriod" 11.1.2.1: "In an S1G BSS, the S1G AP shall generate S1G Beacon frames every dot11BeaconPeriod TUs; and if dot11ShortBeaconInterval is true, it shall additionally generate S1G Beacon frames every dot11ShortBeaconPeriod TUs" Its important to note that dot11ShortBeaconInterval is a boolean that states whether short beaconing is enabled or not, and dot11ShortBeaconPeriod is the interval between each short beacon transmission (TSBTT). We have opted to use the notion of "short beacon interval" to represent the time in TUs between each TSBTT as the kernel currently uses beacon_int to determine the time between each TBTT, so using s1g_short_beacon_int seems appropriate here.
