@PolynomialDivision Does the time_zone setting take the same format as the timezone setting in /etc/config/system? E.g.:
# uci show system|grep timezone
system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3'
What time_zone setting? 
That is a hostapd setting:
# Local time zone as specified in 8.3 of IEEE Std 1003.1-2004:
# stdoffset[dst[offset][,start[/time],end[/time]]]
#time_zone=EST5
I think this time stuff is only useful for 802.11v wmm sleeping states. However, I am not sure.
1 Like
Yep looks alright, thanks 
.
1 Like
It is working now :D.
1 Like
Cool. However, would be nicer if the clients would respect the transition request by itself.
1 Like
@IanC -
this issue of steadily-increasing traffic is still occurring with current build
i will next try using dawn on just one AP - but doesnt this defeat the whole purpose?
I dont know but i have some memetek phone with stupid roaming, "kick" is better ( ios and snapdragon has no issue ).
Weird, can you check how many connetions are open?
i've got 3 access points on identical hardware (RAC2V1K) identically configured: same SSID on 2.4g and 5g bands, serving 25-30 wifi clients (laptops, iphones, smartspeakers, streaming media devices, and household infrastructure (alarm, themostat, etc). typical outgoing web traffic is 4-5 GB /day.
as soon as Dawn is initiallized, traffic on AP's increases.
after about a week the thropughput slows because of this background stuff.
I'm seeing errors like this in the log, but not sure how to interpret them:
Sun Jul 31 15:26:00 2022 daemon.err dawn: client_to_server_state()=tcpsocket.c@103 Closing connection, pending: 0, total: 33816578
Sun Jul 31 15:26:00 2022 daemon.warn dawn: Connection to server closed
Sun Jul 31 15:26:00 2022 daemon.err dawn: client_notify_state()=tcpsocket.c@76 Closing client-connection, pending: 0, total: 0
Sun Jul 31 15:26:00 2022 daemon.warn dawn: Connection closed
Sun Jul 31 15:26:09 2022 daemon.err dawn: connect_cb()=tcpsocket.c@319 Connection failed (ERROR)
Is this something to worry about? I'm not sure, but I'm having occasional problems where a client (like an iPhone) will show a Wifi connection, then suddenly drop to cellular, and then reconnect. (Presumably a kick and resume? For some reason I expected it to be more seamless, like fast roaming.)
@jeff47 Are they spamming the log? That should not happen often, however it can happen.
Further, are you using 21.02? I realized yesterday that a very important fix for hostapd is missing:
That can crash your hostapd frequently.
It happens several times an hour. This is on the router; it doesn't provide any wireless, that comes from two dumb APs. Should I just ignore it, or remove Dawn from the router? If I understand how it works, as long as the two APs can talk to each other (which they can), I only need Dawn on the router if I want to be able to watch it there.
I'm on 21.02.3-29255 (Wulfy's rpi4 build).
I get similar messages on master to (based on snapshot from July 31):
ug 1 11:56:24 OpenWrt dawn[4068]: client_notify_state()=tcpsocket.c@68 eof!, pending: 0, total: 0
Aug 1 11:56:24 OpenWrt dawn[4068]: Connection closed
Aug 1 11:57:13 OpenWrt dawn[4068]: client_notify_state()=tcpsocket.c@68 eof!, pending: 0, total: 0
Aug 1 11:57:13 OpenWrt dawn[4068]: Connection closed
Aug 1 11:57:44 OpenWrt dawn[4068]: client_notify_state()=tcpsocket.c@68 eof!, pending: 0, total: 0
Aug 1 11:57:44 OpenWrt dawn[4068]: Connection closed
Aug 1 11:58:33 OpenWrt dawn[4068]: client_notify_state()=tcpsocket.c@68 eof!, pending: 0, total: 0
Aug 1 11:58:33 OpenWrt dawn[4068]: Connection closed
Aug 1 11:58:55 OpenWrt dawn[4068]: client_notify_state()=tcpsocket.c@68 eof!, pending: 0, total: 0
Aug 1 11:58:55 OpenWrt dawn[4068]: Connection closed
Aug 1 11:59:53 OpenWrt dawn[4068]: client_notify_state()=tcpsocket.c@68 eof!, pending: 0, total: 0
Aug 1 11:59:53 OpenWrt dawn[4068]: Connection closed
Aug 1 12:00:15 OpenWrt dawn[4068]: client_notify_state()=tcpsocket.c@68 eof!, pending: 0, total: 0
Aug 1 12:00:15 OpenWrt dawn[4068]: Connection closed
I installed statistics on one of the APs to check if my setup was experiencing the same; I found that it isn't.
The AP is running master build.
1 Like
I'm also a little confused about the 'hearing map'. Here's an example, from my iPhone:
| Client MAC | AP MAC | Frequency | HT Sup | VHT Sup | Signal | RCPI | RSNI | Channel Utilization | Station connect to AP | Score |
|---|---|---|---|---|---|---|---|---|---|---|
| 34:08:BC:xx:xx:xx | yy:yy:yy:yy:yy:yy | 5.785 GHz Channel: 157 | True | True | -77 | -1 | -1 | 0.00 % | 4 | 107 |
That's the only entry I see for that client MAC.
The log also reads:
Mon Aug 1 14:44:12 2022 daemon.info dawn: Client 34:08:BC:xx:xx:xx: Compared 0 alternate AP candidates
Mon Aug 1 14:44:12 2022 daemon.info dawn: Client 34:08:BC:xx:xx:xx: Current AP is best. Client will stay:
Interpreting this, it seems like this client can only "see" one AP. However, using the Airport Utility on the phone shows this:
Access Point
RRSI -42 dBm
Channel 6
Access Point
RRSI -45 dBm
Channel 11
Access Point
RRSI -48 dBm
Channel 157
Access Point
RRSI -61 dBm
Channel 144
Shouldn't it be comparing 3 alternate APs, not 0?
Maybe it scans using mac randomization or it uses passive scans only.
That is why 802.11k is so important.
MAC randomization is definitely off.
Here are the parameters from /etc/config/wireless. I believe the options for 802.11k are correct.
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option key 'redacted'
option ieee80211r '1'
option mobility_domain '4747'
option ft_over_ds '0'
option ft_psk_generate_local '1'
option wpa_disable_eapol_key_retries '1'
option ssid 'BIRDNEST'
option ieee80211w '0'
option encryption 'psk2+ccmp'
option bss_transition '1'
option wnm_sleep_mode '1'
option time_advertisement '2'
option time_zone 'EST5EDT'
option ieee80211k '1'
option rrm_neighbor_report '1'
option rrm_beacon_report '1'
option network 'LAN'
option dtim_period '3'
@PolynomialDivision This might seem a silly question, but do I need to install DAWN on the router (providing DHCP and DNS) if it has no AP functionality (no radios)?
To clarify: I've read the instructions on the Freifunk GitHub. It talks about installing DAWN on your 'main' AP as well (with routing functionality). Hence why I'm asking if that applies to a wired only router as well since it has no AP functionality.