Setting up DAWN and band-steering in OpenWrt

DAWN is a “Decentralized Wifi Controller” which can be used for band-steering in OpenWrt.

This can be useful for improved WiFi performance when you have a network with multiple APs. Especially on EAP networks, it is highly recommended to set up 802.11r also.

An summary of WiFi roaming technologies can be found on the roaming page.

The following items are required to setup DAWN with OpenWrt:

• One or more OpenWrt based APs (and routers).
• install the full version of wpad
• install and configure required packages for DAWN

To setup DAWN:

• configure 802.11k and 802.11v on all WiFi AP-nodes.
• install and configure required packages for DAWN
• reboot all nodes (or just restart the network if no wpad packages have been changed).

SSH into each of your wifi/AP nodes and add the following config-lines in /etc/config/wireless to each of your SSIDs:

      option bss_transition '1'
      option ieee80211k '1'

Note: From OpenWrt 18.06.0 to 21.02, the config option ieee80211v was also required. If migrating from an older version, you could remove this option.

We need to install DAWN and umdns. Unfortunately for us, in OpenWrt 21.02.x none of these packages works out of the box, and need fixing before we can use them.

First of all, SSH into all the AP-nodes in your network and install the required packages. If you have a dedicated router (without AP functionality enabled) and you would like to get DAWN dashboards in Luci there too, you need to install these packages here as well:

 opkg update && opkg install dawn

umdns is a dependency of dawn and will be installed automatically too.

At this point you have all the packages you need, but they may be in need of additional configuration.

Since dawn in network mode 2 (umdns + tcp) depends on umdns, ensure umdns is working correctly first. On all nodes where you installed dawn, try the following command:

 /etc/init.d/umdns restart

If this command completes without error, umdns is working correctly. If it fails, we can disable the umdns seccomp profile:

 mv /etc/seccomp/umdns.json /etc/seccomp/umdns.json.disable

Restarting or starting umdns should now succeed.

Do this for all nodes in your “DAWN”-netwwrk.

dawn's config-file /etc/config/dawn specifies which subnet is used for broadcasts to discover other nodes. By default this is specified as “10.0.0.255”. If your OpenWrt has a default 192.168.1.x LAN-subnet, you will need to change this file.

In /etc/config/dawn, change this line:

  option broadcast_ip '10.0.0.255'

To this line:

  option broadcast_ip '192.168.1.255'

Also, consider changing the default password to something else, but make sure the same password is used on all nodes!

After making this change, restart dawn:

  /etc/init.d/dawn restart

Again, do this on all nodes in your “DAWN”-network.

Two key parameters, “rssi_weight” and “rssi_center,” helps in fine tuning DAWN in kick method 1 (RSSI Comparison) or 3 (default, RSSI Comparison and Absolute RSSI).

In kick methods 1 and 3, adjusting default scoring parameters like “ht_support,” “vht_support,” “rssi,” “low_rssi,” “chan_util,” and “max_chan_util” to 0 is recommended. This will allow for a completely dynamic scoring calculation based solely on the RSSI reducing complexity and chance of misconfiguration, this means the calculation will solely become:

new_score = initial_score + (rssi - rssi_center) * rssi_weight

For instance, if the initial score is 100, rssi is -47, rssi_weight is 2, and rssi_center is -20, the new score would be 46. Experimenting with these parameters in a spreadsheet can help.

The benefit of this approach lies in avoiding fixed values in parameters like “rssi” and “low_rssi” that are based solely on the threshold defined in “rssi_val” and “low_rssi_val.” In scenarios where two APs are in close proximity, but one has a 20 RSSI difference, the dynamic scoring prevents identical scores, ensuring the selection of the superior AP. This might not be the case if those two APs happen to both classify as within the “low_rssi_val” threshold, for instance.

• Kick Method 2 and 3: Special attention is required when selecting “rssi_center” as it serves as the threshold for client kicks, disregarding the score and RSSI comparison with other APs. For this reason, kick method 1 (RSSI Comparison) is generally preferred, while kick method 2 (Absolute RSSI) and kick method 3 (Both RSSI Comparison and Absolute RSSI) are to be avoided.
• Default Kicking Method Consideration: The default kicking method may not be suitable, as it may continue to kick clients below the “rssi_center” even when there is no alternative AP the client may connect to. Kick method 1 is often more appropriate as it considers other APs when making such decisions and wouldn't kick if no better option exists for the client.
• Misconception Clarification: There is a common misconception on forums that kick method 3 requires both RSSI comparison and absolute RSSI to be satisfied. However, a closer look at the code shows that this is not the case: https://github.com/berlin-open-wireless-lab/DAWN/blob/e036905ae3a5d079f899bbe46461fc78b4566349/src/storage/datastorage.c#L509-L543

DAWN decides to kick a client at every update_client interval. This means that reducing this number to “1” from the default “20,” would cause DAWN to make its calculations on whether to kick a client every 1 second (with min_number_to_kick still being considered as usual).

You may also optionally install “luci-app-dawn”. luci-app-dawn provides a network overview inside Luci, and can be useful to ensure your setup works correctly.

You can install it on any node you like, including your main router, even if that does not provide wifi.

Installing it on all nodes can be useful, as it lets you verify that you get the same DAWN information on all nodes, and thus that they are communicating together correctly.

On the nodes where you want a DAWN dashboard in luci, enter the following command:

  opkg install luci-app-dawn

After making these changes you need to restart networking on all nodes to make changes effective.

You can either reboot/power-cycle the device, or just SSH into the node and issue:

  /etc/init.d/network restart

Once this has been done on all nodes, you should be able to get a nice dashboard in luci showing you your network topology:

Mission accomplished!