After every 5-7 days uptime openwrt 19.07.4 dissociates clients

Installing and Using OpenWrt
1

Hi guys.

I have tplink 3600v1 running openwrt 19.07.4 (target ath79)
I have setup 801.1x authentication from wireless supplicants via autenticator openwrt AP to authentication server (freefadius 3.0.21).
all wireless clients (linux/android, Windows, MACs) being joining AP &authenticated normaly for 5-7 day access point uptime.
Whenever issue happening. All already authenticated clients cannot reauthenticate and new client cannot authenticate showing "cannot authenticate with this network"
meantime openwrt has massive dissassociation in system log file:

Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: authenticated
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: associated (aid 1)
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: CTRL-EVENT-EAP-STARTED 48:5f:99:b9:2e:df
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: disassociated
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: authenticated
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: associated (aid 1)
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: CTRL-EVENT-EAP-STARTED 48:5f:99:b9:2e:df
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: disassociated
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: authenticated
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: associated (aid 1)
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: CTRL-EVENT-EAP-STARTED 48:5f:99:b9:2e:df
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Feb  2 18:50:22 ap03.at1.net hostapd: wlan1: STA 48:5f:99:b9:2e:df IEEE 802.11: disassociated

only reboot AP fixes this issue. (so I mean no changes at all at clients&ap&radius)

Do you have any idea what it could be?

Thank you in advance.

2

Unless you find a better solution, here's a workaround:

cat << "EOF" > /root/wifi-fix.sh
WIFI_ERRNUM="$(logread -e hostapd \
| tail -n 20 | grep -c -e disassociated)"
WIFI_ERRLIM="3"
if [ "${WIFI_ERRNUM}" -ge "${WIFI_ERRLIM}" ]
then
wifi reload
/etc/init.d/log restart
fi
EOF
cat << "EOF" >> /etc/crontabs/root
* * * * * . /root/wifi-fix.sh
EOF
uci set system.@system[0].cronloglevel="9"
uci commit system
/etc/init.d/cron restart

Use the reboot command if reloading Wi-Fi doesn't help.

3

This sounds a little bit like the known problem of wpa enterprise. If you google for
wpa_group_rekey you might find some background. If this is the problem, disabling or increasing the interval between rekeying could help. See

2 Likes
4

Thank you guys.
"Stefan1" - I increased "wpa_group_rekey" value to 3600. let's see if it helps.
"vgaetera" - I'll keep this possible "fix" in mind. I need this wireless network up and running 24x7 and avoid possible situation whenever STA/wireless station run out of wireless coverage, AP writes this in log and script reboots AP because of this.
Anyway thank you both!

2 Likes
5

Hi Stefan1.

your suggestion works perfectly. I didn't see this issue for more that 21 days.

Thank you again.

1 Like
6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.