> For the complete documentation index, see [llms.txt](https://docs.morsemicro.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.morsemicro.com/application-notes/appnote-25-centralized-authentication-control.md).

# APPNOTE-25 Centralized Authentication Control

[Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-25_Centralized_Authentication_Control.pdf)

## 1 Scope

Centralised Authentication Control (CAC) can be used to reduce the time taken for a large number of stations to associate, by throttling the number of stations that attempt to associate simultaneously, and thereby minimizing contention of time-sensitive association and authentication frame exchanges.

CAC is recommended for use in moderate (more than 40 stations) to large HaLow networks, particularly when operating in low capacity environments, for example in regulatory domains that only allow 1 MHz or 2 MHz bandwidth, or that have duty cycle limitations.

## 2 Theory of Operation

The following explanation is taken from Wi-Fi HaLow for the Internet of Things: An Up-to-date Survey on 802.11ah.

In Centralized Authentication Control (CAC), the AP dynamically changes the portion of stations that are allowed to send AuthReq messages. Specifically, the AP sets a threshold and broadcasts it to all stations by sending beacon frames. The beacon frame is a management frame and contains the information about the network, it is transmitted periodically by the AP to announce the presence of a wireless network and to synchronize all the stations of the network. When a station is initialized, it generates a random value from the interval \[0, 1022], and tries to send an AuthReq to the AP if the random value is smaller than the threshold obtained from the received beacon.

Otherwise, it postpones authentication/association until the next beacon arrives. The threshold should be adjusted dynamically by the AP to limit the number of stations accessing the channel in one beacon interval, and make sure all stations can associate as fast as possible.

## 3 How to Configure

### Enabling CAC on an AP

Centralised Authentication Control can reduce the time taken for a large number of stations to associate, by throttling the number of stations that attempt to associate simultaneously, and thereby minimizing contention of time-sensitive association and authentication frame exchanges.

To enable CAC, add cac ‘1’ to the wifi-iface section.

### Enabling CAC on stations

CAC is enabled on stations by adding cac=1 to the network block in wpa\_supplicant\_s1g.conf.

...

network={

&#x20;       ssid=

...

&#x20;       cac=1

}

Any stations that do not have CAC configured will be able to associate with an AP that has CAC enabled, and will not be constrained by CAC restrictions imposed by the AP.

### Further CAC configuration (AP)

If over-the-air capacity is limited, such as when using 1MHz bandwidth and/or a low duty cycle (for example, in JP, EU and IN regulatory domains), it may also be necessary to modify the CAC thresholds, by using the morse\_cli cac command.

***

$ morse\_cli cac --help

cac \[-v] \[{get|set|enable|disable}] \[-d ,]...

&#x20;              \[-i ,]...

&#x20;   Configure Centralized Authentication Control

&#x20;   {get|set|enable|disable}    Subcommand

&#x20;       get - get configured rules

&#x20;       set - set rules (default)

&#x20;       enable|disable - for internal use by wpa\_supplicant only

&#x20;   -d, --decrease=,

&#x20;       Auth Req Frames per Sec above which to decrease threshold by

&#x20;       Decrease rules must be specified in descending ARFS order

&#x20;           (match highest first)

&#x20;   -i, --increase=,

&#x20;       Auth Req Frames per Sec below which to increase threshold by

&#x20;       Increase rules must be specified in ascending ARFS order

&#x20;           (match lowest first)

&#x20;       Up to 8 decrease or increase rules can be configured

&#x20;   -v, --verbose                Verbose output

#### Default configuration

Use the morse\_cli cac get command to see the current configuration. These are the default settings.

root\@mazda1:\~$ morse\_cli cac get

When ARFS is greater than 16, decrease threshold by 25%

When ARFS is greater than 12, decrease threshold by 12%

When ARFS is greater than 10, decrease threshold by 6%

When ARFS is less than 4, increase threshold by 25%

When ARFS is less than 6, increase threshold by 12%

When ARFS is less than 8, increase threshold by 6%

#### Sample configuration for a bandwidth-constrained network

These are more aggressive settings, which may be suitable for a large or bandwidth-constrained network.

root\@mazda1:\~$ morse\_cli cac -v -d5,60 -d4,50 -d3,40 -i2,12 -i3,6

When ARFS is greater than 5, decrease threshold by 60%

When ARFS is greater than 4, decrease threshold by 50%

When ARFS is greater than 3, decrease threshold by 40%

When ARFS is less than 2, increase threshold by 12%

When ARFS is less than 3, increase threshold by 6%

### Considerations

#### Thin LMAC

Thin LMAC is required for associating more than 200 stations, and is described in MM APPNOTE 20. That document also contains useful information for improving performance in moderate to large scale networks.

***

## 4 How to Verify

### AP

Confirm CAC is enabled by using the following command. A value of 1 indicates that CAC  is enabled.

`# cat /sys/module/morse/parameters/enable_cac`

1

#### AP-side log messages

Info level (6) or debug level (7) driver debugging can be enabled with the following commands.

`# phy=$(ls -d /sys/kernel/debug/ieee80211/phy\*)`

`# echo 6 >$phy/morse/logging/cac`

or

`# echo 7 >$phy/morse/logging/cac`

Whenever the CAC threshold changes (i.e. when many stations attempt to associate at the same time, up until most stations have associated and a threshold is no longer being set), messages such as the following are written to the AP’s syslog.

`# dmesg|grep -w CAC`

\[  205.593166] morse\_sdio mmc1:0001:2: CAC ARFS=13 period=600 adjust=-2

&#x20;       idx=14 threshold=896

\[  206.523164] morse\_sdio mmc1:0001:2: CAC ARFS=11 period=800 adjust=-1

&#x20;       idx=13 threshold=832

\[  206.963164] morse\_sdio mmc1:0001:2: CAC ARFS=11 period=400 adjust=-1

&#x20;       idx=12 threshold=768

\[  208.073159] morse\_sdio mmc1:0001:2: CAC ARFS=2 period=1000 adjust=4

&#x20;       idx=16 threshold=1024

The fields in these messages are:

* ARFS: authentication request frames received in this period
* period: period over which the ARFS were received (max will be 1 second)
* adjust: change to the threshold index
* idx: new index, which is used to set the new threshold
* threshold: threshold now being advertised in beacons and probe responses

### Station

When CAC is enabled on both the AP and STAs, and the AP starts advertising a CAC threshold (the above log messages are seen), messages like the following can be seen in the wpa\_supplicant log if INFO level debug messages are enabled.

SVT\_mercedes27\_10.53.53.37# grep CAC /var/log/morse\_wpa\_supplicant.log

202.791642: wlan1: Auth disallowed by CAC for 0c:flag\_bf:74:59:bf:11,

&#x20;       threshold=896 random=936

205.889910: wlan1: Auth allowed by CAC for 0c:flag\_bf:74:59:bf:11,

&#x20;       threshold=1023 random=936

The fields in these messages are:

* threshold: threshold from the most recently received beacon or probe response
* random: the current random value used by this STA

***

## 5 Revision History

| Release Number | Release Date | Release Notes   |
| -------------- | ------------ | --------------- |
| 01             | 2024-03-18   | Initial version |
