Dawn: a decentralized wireless controller

Are both routers seeing each others? Test

ubus call umdns browse

Yup they see each other via umdns.

root@ap:~# ubus call umdns browse
{
        "_dawn._tcp": {
                "router": {
                        "ipv4": "$IP_of_router",
(...)

And vice versa.

On the router dawn network I see ap but on the ap I cannot see router.

EDIT: I have VLANs between devices an many wireless AP. So when DAWN is binding to each IP of each network maybe that is making some trouble. But that command lists all of the IPs. Is /etc/config/dawn important in that case?

I disabled STP and IGMP Snooping and it seems like it helped.
Now both devices see each other in each network map.
Could it be the case?

No there is still something wrong I just checked syslogs and I see a lot of

Jun  3 15:02:28 ap dawn[6369]: connect_cb()=tcpsocket.c@272 Connection failed
 (ERROR)

On the access point and AP can see router but router doesnt see AP. Is there some debugging options?

Edit: umdns works tho... wait look at this:

root@ap:~# ubus call umdns browse
{
        "_dawn._tcp": {
                "router": {
                        "ipv4": "10.0.X.254",
                        "ipv4": "10.111.X.1",
                        "ipv4": "10.13.X.254",
                        "ipv4": "10.19.X.254",
                        "ipv4": "10.222.X.254",
                        "ipv4": "172.18.0.1",
                        "ipv6": "fd00:bad:c0de:X::254",
                        "ipv6": "fe80::da58:d7ff:fe00:3d9e",
                        "ipv6": "fe80::da58:d7ff:fe00:3d9e",
                        "port": 1026,
                        "port": 1026

Thats on AP and weird thing is that port is listed twice. On the router there is only one position specifying port. A bug?

Maybe the tcp connection is failing for some IPs but not for others? I am just guessing.

Restarted umdns on both devices and everything is back operational. Hmmm

Maybe tell umdns to listen only on one specific interface?

How do I do that? I see /etc/config/umdns

I will check maybe there some docs on openwrt wiki

Umdns is buggy. I bumped into another threat that aparently I participated but I forgot How to announce service with umDNS? - #17 by AreYouLoco

After restarting umdns everything is back operational. I have ssh session open and I move around and I am roamed corectly without dropping the session.

Multiple people wished, that I pull the latest changes from @IanC GitHub repository. I pushed everything now to OpenWrt Master:

Would be nice, if people would do some testing. Please remove your /etc/config/dawn before intalling since a lot changed. If it runs stable, I would also push it to 21.02 and 22.03.

@IanC branch is not compatible to openwrt master anymore, since an important ubus function for kicking was removed in:

1 Like

Apologies that I don't understand fully - does it mean latest dawn in master, will not work due to the change or you made adjustments to make it compatible ? Thank you btw, happy to test it as soon as it will get compiled.

Some people used @IanC GitHub fork. In this repository an important fix is missing, because an important IPC-function of hostapd was removed:

Everything is good, if you use openwrt master with dawn. :slight_smile:

Thank you btw, happy to test it as soon as it will get compiled.

You have to thank @IanC for all the changes. :slight_smile: I just pulled them to my github repository.

4 Likes

Hi, with latest version I'm getting full log of these :

Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...

I have same problem with Dawn on two different routers. AP doesn't see other AP clients. Each client has only one AP record in hearing map.

But if I'm restarting dawn or network service, Dawn shows both APs for clients for a short period of time (10-20sec)

Should be fixed with the new update:

3 Likes

I confirm, seems to be fixed, thank you :wink:

1 Like

Merged changes to 22.03 and 21.02. Please also adjust the config files if you update, or remove it before installing.

2 Likes

I just upgraded dawn on following target

Hostname	AC2100
Model	Xiaomi Mi Router AC2100
Architecture	MediaTek MT7621 ver:1 eco:3
Target Platform	ramips/mt7621
Firmware Version	OpenWrt 21.02.2 r16495-bf0c965af0 / LuCI openwrt-21.02 branch git-22.119.37126-a993714
Kernel Version	5.4.179

Upgrading dawn on root from 2022-05-09-2bfd7397-1 to 2022-06-13-58861a1a-1...

Dawn was working fine before upgrade.
Now dawn is failing to start:

Wed Jun 15 20:06:45 2022 kern.info kernel: [230785.846201] epc = 0040972f in dawn[400000+12000]
Wed Jun 15 20:06:45 2022 kern.info kernel: [230785.851097] ra  = 0040972d in dawn[400000+12000]
Wed Jun 15 20:07:00 2022 kern.info kernel: [230800.868293] do_page_fault(): sending SIGSEGV to dawn for invalid read access from 00000010

EDIT:
My mistake!
I removed dawn config file
dawn crashes with no config file

I removed dawn package / reintall to recreate default dawn config file.
Now dawn starts correctly.

1 Like

Hello,

I setup DAWN follow this guide;
https://openwrt.org/wiki/dawn

On the hardware:

Model ASUS Lyra MAP-AC2200
Architecture ARMv7 Processor rev 5 (v7l)
Target Platform ipq40xx/generic
Firmware Version OpenWrt 21.02.3 r16554-1d4dea6d4f / LuCI openwrt-21.02 branch git-22.167.28411-ee8170b
Kernel Version 5.4.188

Run the non CT version drivers.

If i click "View Hearing Map" on the webpage then iget some errors,

Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!

And the Wifi Client does not switch to another AP.
It keeps trying..

Mon Jun 20 10:28:34 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:28:44 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:28:55 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:05 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:15 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:26 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:36 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:46 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:57 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:07 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:17 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:28 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:38 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:48 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:59 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit

Looks like the ""Kick" function is not working.
What do I wrong ??

Greets:Mietse

1 Like

im still facing with same issue

Did you install wpad-full or just basic?

These mutex warnings should be fixed with: https://github.com/berlin-open-wireless-lab/DAWN/commit/181549f7bb706f04d6cdd2e8dae80ba4e9549cbe

2 Likes