Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
docs:guide-user:network:wifi:dawn [2023/12/29 18:29] – [Prerequisites] Remove 802.11r requirement, not actually needed... only recommended especially for EAP networks. On PSK there isn't much of an advantage. ranydocs:guide-user:network:wifi:dawn [2023/12/30 13:21] – [Configure 802.11k and 802.11v on all AP-nodes] rany
Line 3: Line 3:
 [[https://github.com/berlin-open-wireless-lab/DAWN|DAWN]] is a "Decentralized Wifi Controller" which can be used for band-steering in OpenWrt. [[https://github.com/berlin-open-wireless-lab/DAWN|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 and 802.11r-based Wifi roaming enabled.+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 [[docs:guide-user:network:wifi:basic#fast_bss_transition_options_80211r|802.11r]] also.
  
 ===== Prerequisites ===== ===== Prerequisites =====
Line 10: Line 10:
  
   * One or more OpenWrt based APs (and routers).   * One or more OpenWrt based APs (and routers).
 +  * install the full version of wpad
 +  * install and configure required packages for DAWN
  
-And that's pretty much it.+===== Setting up DAWN =====
  
-===== Setting up DAWN with OpenWrt 21.02.x ===== +To setup DAWN:
-These instructions have been tested with OpenWrt 21.02.x. For different versions, details may differ.+
  
-To setup DAWN we need to do 4 things: +  * configure 802.11k and 802.11v on all WiFi AP-nodes.
- +
-  * install the full version of wpad +
-  * configure 802.11k and 802.11v on all wifi AP-nodes.+
   * install and configure required packages for DAWN   * install and configure required packages for DAWN
-  * reboot all nodes (or just restart the network)+  * reboot all nodes (or just restart the network if no wpad packages have been changed).
- +
-Due to a bug in DSA, roaming does not work on VLANs (see [[https://github.com/openwrt/openwrt/issues/11650|#11650]]). There is a workaround by running "brctl br-lan setaging 3" which must be via script at boot for every bridge.+
  
 ==== Configure 802.11k and 802.11v on all AP-nodes ==== ==== Configure 802.11k and 802.11v on all AP-nodes ====
  
-SSH into each of your wifi/AP nodes and add the following config-lines in ''/etc/config/wireless'' to each of your 802.11r enabled SSIDs:+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 bss_transition '1'
Line 46: Line 42:
 At this point you have all the packages you need, but they may be in need of additional configuration. At this point you have all the packages you need, but they may be in need of additional configuration.
  
-==== Configuring/fixing umdns ====+==== Fixing umdns (OpenWrt 21.02 only) ====
  
-Since dawn depends on umdns, ensure umdns is working correctly first. On all nodes where you installed dawn, try the following command:+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    /etc/init.d/umdns restart
  
-If this command completes without error, umdns is working correctly. On OpenWrt 21.02.x however, it has an incorrect seccomp configuration causing loading to fail. To fix/bypass this, we can disable the umdns seccomp profile:+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    mv /etc/seccomp/umdns.json /etc/seccomp/umdns.json.disable
Line 61: Line 57:
  
 ==== Configuring dawn ==== ==== Configuring dawn ====
 +
 +<WRAP important 100%>**Warning!** This is NOT needed if you stick to the default "network_option" of 2 (umdns + tcp). It is recommended to stick with the defaults and ignore this section due to issues with the other UDP-based network mode options offered by DAWN as it sends packets that are larger interface MTU causing corrupted data to be received on the other end.</WRAP>
  
 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. 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.
Line 80: Line 78:
 Again, do this on all nodes in your "DAWN"-network. Again, do this on all nodes in your "DAWN"-network.
  
 +==== Configuration Tips ====
 +
 +=== Using "rssi_weight" and "rssi_center" for Improved Target Selection ===
 +
 +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 Considerations ===
 +
 +- **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 
 ==== Optional (Dashboard) ==== ==== Optional (Dashboard) ====
  
  • Last modified: 2024/12/03 18:09
  • by palebloodsky