Seamless extension of WiFi/WLAN range

Hello all,

I want to increase the WiFi coverage of my TO. All should work seamlessly, i.e. moving between the area covered by the Omnia and the extended zone should lead to no (apparent) reconnection of the moving device. Especially Android devices seem to cling to APs as long as possible, even though communication already broke down.

Form what I understand (I’m not really sure about this) this would require some kind of management entity handling the hand-over from one zone to the other.

  1. Is it possible to achieve my goal using the Omnia WiFi?
  2. If so, what additional hardware do you suggest?
  3. What would I need on the software side?

I know I could boost the hardware by changing the setup as explained in [1] or a WiFi range extender. I also know I could buy OTS WiFi-Mesh devices and controllers (UniFy, …). But since the TO does its job perfectly, I would rather use it.

Thank you for your suggestions!

[1] High-performance configuration (update)

1 Like

I have the same question and would really appreciate an answer by someone experienced. Thanks!

In particular, I’d like to provide WiFi to three floors, using the same ESSID. I have ethernet ports in all rooms that connect to a patch field in the basement, so any new device could be connected to the Turris Omnia by cable. All walls and ceilings are made of concrete. At the moment, the Turris Omnia’s WiFi doesn’t even fully cover a single floor.

1 Like

I have similar setup at home two Omnias connected by cable. One logical network as one Omnia acts as dumb AP and I have DAWN configured to allow seemless roaming between networks. But be sure to use same SSID for your networks as its requirement for FastTransition to work

2 Likes

I’ve just finished configuring DAWN for my 2 Turris routers. Here are my notes because above Wiki is little bit obsolete/misleading:

My Turris’es are connected by cable. On the both, I’ve enabled 802.11r Fast Transition for all Wifi networks (they have the same SSID) and set up Mobility Domain. There is no need to set 802.11k and 802.11v and bss_transition (see GitHub issue). Then I installed DAWN:

opkg install dawn
opkg install luci-app-dawn

Configure it /etc/config/dawn. I took config inspiration from reddit. Here are just changes from defaults:

config metric 'global'
    option bandwidth_threshold '0'
    option kicking '1'
    option min_number_to_kick '2'
    option duration '200'
    option rrm_mode 'apt'

I don’t want to kick devices with low bandwidth (e.g. home automation devices), I want to kick only by RSSI comparison - not by absolute values. I want to speed up kicking a little bit and most important imho is to set rrm_mode to active otherwise it’s up to device to check all wifi networks and phones don’t do it often.

Full config for wifi parts - I want to prefer 5GHz networks a lot and don’t care about channel utilization, HT, VHT, …:

config metric '802_11g'
    option initial_score '80'
    option ht_support '0'
    option vht_support '0'
    option no_ht_support '0'
    option no_vht_support '0'
    option rssi '0'
    option rssi_val '-60'
    option low_rssi_val '-80'
    option low_rssi '0'
    option chan_util '0'
    option chan_util_val '140'
    option max_chan_util '0'
    option max_chan_util_val '170'
    option rssi_weight '1'
    option rssi_center '-70'

config metric '802_11a'
    option initial_score '150'
    option ht_support '0'
    option vht_support '0'
    option no_ht_support '0'
    option no_vht_support '0'
    option rssi '0'
    option rssi_val '-60'
    option low_rssi_val '-80'
    option low_rssi '0'
    option chan_util '0'
    option chan_util_val '140'
    option max_chan_util '0'
    option max_chan_util_val '170'
    option rssi_weight '5'
    option rssi_center '-70'

Then I’ve enabled dawn service and restared router.

6 Likes

Seeing that this is the post where I commented too (Reddit - Dive into anything), here’s my configuration:

root@omnia:~# cat /etc/config/dawn
config local
	option loglevel '9'

config network
	option broadcast_ip '192.168.1.255'
	option broadcast_port '1025'
	option tcp_port '1026'
	option network_option '2'
	option shared_key 'Niiiiiiiiiiiiick'
	option iv 'Niiiiiiiiiiiiick'
	option use_symm_enc '0'
	option collision_domain '-1'
	option bandwidth '-1'

config hostapd
	option hostapd_dir '/var/run/hostapd'

config times
	option con_timeout '60'
	option update_client '10'
	option remove_client '15'
	option remove_probe '30'
	option remove_ap '460'
	option update_hostapd '10'
	option update_tcp_con '10'
	option update_chan_util '5'
	option update_beacon_reports '20'

config metric 'global'
	option min_probe_count '0'
	option bandwidth_threshold '0'
	option use_station_count '0'
	option max_station_diff '1'
	option eval_probe_req '0'
	option eval_auth_req '0'
	option eval_assoc_req '0'
	option kicking '1'
	option kicking_threshold '40'
	option deny_auth_reason '1'
	option deny_assoc_reason '17'
	option min_number_to_kick '2'
	option chan_util_avg_period '3'
	option set_hostapd_nr '1'
	option duration '200'
	option rrm_mode 'apt'

config metric '802_11g'
	option initial_score '200'
	option ht_support '0'
	option vht_support '0'
	option no_ht_support '0'
	option no_vht_support '0'
	option rssi '0'
	option rssi_val '-10'
	option low_rssi_val '-50'
	option low_rssi '0'
	option chan_util '0'
	option chan_util_val '140'
	option max_chan_util '0'
	option max_chan_util_val '170'
	option rssi_weight '4'
	option rssi_center '-25'

config metric '802_11a'
	option initial_score '80'
	option ht_support '0'
	option vht_support '0'
	option no_ht_support '0'
	option no_vht_support '0'
	option rssi '0'
	option rssi_val '-10'
	option low_rssi_val '-65'
	option low_rssi '0'
	option chan_util '0'
	option chan_util_val '140'
	option max_chan_util '0'
	option max_chan_util_val '170'
	option rssi_weight '8'
	option rssi_center '-65'

This is made based on that post and the neighboring one (Reddit - Dive into anything).

It’s deployed on Turris Omnia as well as 4 other devices that are dumb APs with the latest stable OpenWRT built with an image builder the same way (3 of those are the same device model and 1 is different).

3 Likes

Thanks for your share @webknjaz - do the “dumb AP” need some extra care or just activating Fast Transition and Mobility domain? Would be great to get an idea how you set up those.

Thx!

When you install software like DAWN, I believe it activates FT programmatically when it starts. So changing the config is probably unnecessary. But I’d set the mobility domain manually to something non-default, and that needs to be the same on all the hotspots.

Thx @webknjaz

I have acutally migrated to TOS 8 in HBD - will provide infos when needed at a later stage.

Greets,
Vienna

demystifying wifi roaming based on experience with a large (50 ap’s) installation

802.11r - fast transition
enables faster authentication during a transition between two different ap’s
or even between two different radios on the same device with a same ssid
this helps a lot with 802.1x authentication and a little with psk or sae
(and no advantage in open networks)
ft can be done over the air or over the ds (distribution system)
you have to choose while configuring ft in openwrt
you have to fully configure ft in openwrt, just switching on is not enough

problems:
in some situations ft is not working over the air
some clients do not work with ft over the ds
some clients do not support ft at all or with psk

  • because of the os and sw implementation
  • because of the hw and drivers

i came across problems or no ft support with:

  • windows 10 + psk/sae
  • windows 11+ psk/sae
  • x86 macos
  • older androids
  • some linux distributions
  • older wifi cards
  • etc.

some buggy clients are known to refuse to associate with networks which are ft enabled

@webknjaz : when you install software like dawn,
believe it doesn’t activate ft programmatically
@Vienna changing the config is definitely necessary, if you want dawn with ft
but you can use 802.11k and 802.11v (that is what’s dawn about) without or with ft
there is no problem - those are separated options

i can write next time more about 802.11k and 802.11v and openwrt
especially about dawn and usteer packages
@Vienna for example there is no problem in different versions of those packages
they use a standard protocol to communicate and exchange info between ap’s
and this software is not actively developed, there are no commits for 1-2 years
the last commits to these packages are mostly doc or ci related

2 Likes