Dawn: a decentralized wireless controller

Community Builds, Projects & Packages
1

Maybe you know already DAWN. Thanks to the great work of some other contributors, I was now able to push some important new changes you can find here or also very interesting. (only on master). Be aware that I removed the config interface of the luci-app-dawn.

Before you update to the newest version please remove the old config: rm /etc/config/dawn.
Afterwards, please try enabling kicking by setting uci set dawn.@metric[0].kicking=1 && uci commit && /etc/init.d/dawn restart.

I would like to receive some feedback on the config options and I thought it would be a good idea to have a support thread where I can push important config changes and updates.

20 Likes
2

hi,

sorry stupid question: if i want to try i should used snapshot or build my own image with the update DAWN package, right?

3

I pushed that 2 days ago to master branch. So depending on your architecture and the speed of the buildbot, it could already be the newest version in the normal openwrt package repro. So you don't need to compile an own image. Otherwise, you can also wait some days.

4

Maximizing interoperability with all existing openwrt r/v/k settings would be interesting. Putting all the toggles (config options) for everything r/v/k (and dawn) on a single config page would be great for optimizing all the handover technologies on one page. “Here are all the centralized and decentralized options on one page, config to your heart’s delight”:

2 Likes
5

Pushed a new commit that hopefully fixes some handling with ubus:

Further, if you still experience segfaults, can you try disabling symmetric encryption?

Please Try:

uci set dawn.@network[0].use_symm_enc=0 && uci commit && /etc/init.d/dawn restart
6

What are the benefits of dawn vs usteer?

1 Like
7

I can not tell you. :confused: I think @blocktrron could probably tell something about it. I saw in his staging tree some work that is very interesting regarding bss-transitions, and learning of certain transitions, e.g. hostapd: ubus: add notification for BSS transition response.

However, I think usteer will be some really good project since a lot of OpenWrt Maintainers (@nbd, @blocktrron, @dangowrt) are working on it. Maybe they can say something about it. I don't know if it is a good idea to work as "one-man-show" on such a controller, if on the other side OpenWrt Devs are also developing a "new" solution. :wink: Maybe we can combine our efforts.

However, I will go on developing and testing DAWN. :slight_smile:

8

If you live in Berlin and want to get connected to the Freifunk Berlin (community wireless mesh) you can also use our ansible scripts with DAWN when I fixed everything: https://github.com/Freifunk-Spalter/bbb-configs/pull/81

9

I was not affiliated with the initial development of usteer, from my understanding it was developed for the TelecomInfraProject solution, but i do not have in-depth knowledge about that.

I'm working on usteer, as i have more familiarity with the codebase (and like the approach it takes more, personal preference) as we have offered a University undergraduate project for it last year, where the group was adding several features to usteer. Due to being busy most of last year, this is now slowly trickling upstream (IPv6 being the first).

4 Likes
10

Is there any overview what OpenWrt does or any meeting I could join to see whats happening?

Maybe next time they can also work on DAWN. xD (just kidding)

I have to do that also. However, umdns has no IPv6 support, but I don't understand how I can access the json format. For me it is just wrong, since the same identifier "ipv6" is used for every ipv6 address.

Currently, DAWN has issues with latest trunk. I will add more debug output. It looks like its appearing when using multiple APs. It could be the datastorage, network connection, or whatever. There was a big rewrite of the datastorage to linked list in the last months/years.

Thanks for taking time to answer here. :slight_smile:

1 Like
11

Thanks to @blocktrron we can now monitor bss-transision decisions from clients:

I will have a look how to integrate this in DAWN. Meanwhile you can also just use ubus monitor.

1 Like
12

Hey,
would love some assistance, been using DAWN for the last year with 4 dumb APs.
I Upgraded today to latest snapshots including new version of dawn, and now it seems like APs can't find each other.
each AP is only seeing itself in the DAWN network overview.

I tried to disable sym enc & update beacon report to no avail.
any help would be appreciated

my dawn config:

config network
	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'
	option broadcast_ip '10.0.0.255'

config ordering
	option sort_order 'cbfs'

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

config times
	option update_client '10'
	option denied_req_threshold '30'
	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 '0'

config metric 'global'
	option rssi_weight '0'
	option rssi_center '0'
	option initial_score '0'
	option kicking_threshold '20'
	option duration '600'
	option rrm_mode 'apt'
	option ap_weight '0'
	option ht_support '0'
	option vht_support '0'
	option no_ht_support '0'
	option no_vht_support '0'
	option rssi '0'
	option low_rssi '0'
	option freq '0'
	option chan_util '0'
	option max_chan_util '0'
	option rssi_val '-60'
	option low_rssi_val '-80'
	option chan_util_val '0'
	option max_chan_util_val '0'
	option min_probe_count '0'
	option bandwidth_threshold '6'
	option use_station_count '0'
	option max_station_diff '0'
	option eval_probe_req '0'
	option eval_auth_req '0'
	option eval_assoc_req '0'
	option kicking '0'
	option deny_auth_reason '1'
	option deny_assoc_reason '17'
	option use_driver_recog '1'
	option chan_util_avg_period '3'
	option set_hostapd_nr '1'

config metric '802_11a'
	option rssi_weight '2'
	option rssi_center '-70'
	option initial_score '125'

config metric '802_11g'
	option rssi_weight '2'
	option rssi_center '-70'
	option initial_score '100'
13

Again important things happened, that also affect dawn. Here @blocktrron pushed a fix for inifinity goto loop:

If you use dawn with option eval_assoc '1' you can be affected.

Furtheremore, I would like to hear if you are also fine with adding this as workaround until I find the cause of segfaults:

14

Topic deadline for this term is already over, but if you have a good idea we might be able to work something out for next year.

1 Like
15

An important bugfix was pushed to hostapd:

That fixes crashes of the hostapd instance, but not crashes of dawn.

16

Wanted to report some of the behavior surrounding dawn that I noticed on a recent master branch build. When I did my usual build and sysupgrade umdns wouldn't start and would error out with umdns Command failed: Request timed out. Looked up and found the previous bug reports and it started working after I removed procd-seccomp and installed procd-ujail, never had an issue with that before so just strange.

When enabling kicking on my system this message keeps repeating on my APs:
hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
I'm not noticing any issues though I have yet to do any thorough testing, and it seems like Dawn is doing what it's supposed to when I move my iPhone around the house.

Lastly, one of my radios uses DFS to scan for free channels before starting, and I think this causes dawn to fail to start sometimes, so I probably need to add some sort of delay.

Anyways, just wanted to give some feedback, thank you!

1 Like
17

Good point thanks! Is the interface in "pending" state? We recently pushed some workaround for olsr:

Which "OpenWrt commit/version" did you use?

Thanks for feedback!

18

I have installed it on 21.02.0 with kicking enabled; other than a lot of chatter in the logs, it doesn't seem to have any other effect, so dual band clients who happen to choose the low band are not kicked upwards.

Do I need other config options? Is it perhaps still too early to use outside master?

1 Like
19

It's actually in a "pending" state before the scans. I did test the olsrd init script changes in dawn and it starts up fine, so my assumption was wrong and I'm having trouble reproducing the issue :thinking:

I ran into another issue when testing the reboot behavior. The interfaces wouldn't come up on one of my APs and this message kept appearing in the logs:

jail: prctl(PR_CAPBSET_DROP, 38) failed: Invalid argument

So I reverted the package changes from my initial comment and moved/removed /etc/seccomp/umdns.json, now everything starts fine.

9b880f09f394049e0629e3c9d4061f431a6b19a8 - the same commit id posted before my initial comment

20

If someone wants to test, we were able to track down some issue and hopefully it is fixed by:

I'm also just compiling toolchain and will runtest again. If it works I will push it to master. However, always happy if other people also ack. :slight_smile: