[SOLVED] Hostapd log bloat authentification problems

outofscope · May 10, 2018, 12:12pm

Hi all,

With the OpenWRT forum still not resolving correctly, I have decided to post this question here with the hope that someone will be able to assist me with my problem.

As a background, my device is a WRT1900AC Samba (v1) running @Davidc502 custom build - Lede SNAPSHOT r6781-2c192b6916 / LuCI Master (git-18.118.21533-00d2429) .

In addition to DNSCrypt, I have an OpenVPN client with one wireless network using wpad with MAC address filtering, client isolation, and KRACK prevention for our 6 wireless devices. I also have static leases setup for everything (wired and wireless).

While reviewing my system logs earlier, I discovered hundreds of entries containing daemon.notice hostapd: Station not allowed to authenticate messages. The MAC addresses appear to be random and do not resemble any of the MAC addresses of the devices we have on our network. I researched some of the addresses online and found the devices manufacturers are from Google, Samsung, Ubiquiti, Apple and so forth.

Enclosed below is a sample of the entries:

Thu May 10 21:44:17 2018 daemon.notice hostapd: Station f4:f5:d8:3e:13:14 not allowed to authenticate
Thu May 10 21:44:17 2018 daemon.notice hostapd: Station f4:f5:d8:3e:13:14 not allowed to authenticate
Thu May 10 21:44:18 2018 daemon.notice hostapd: Station 20:c9:d0:7c:34:b5 not allowed to authenticate
Thu May 10 21:44:18 2018 daemon.notice hostapd: Station 20:c9:d0:7c:34:b5 not allowed to authenticate
Thu May 10 21:44:18 2018 daemon.notice hostapd: Station 20:c9:d0:7c:34:b5 not allowed to authenticate
Thu May 10 21:44:18 2018 daemon.notice hostapd: Station 20:c9:d0:7c:34:b5 not allowed to authenticate
Thu May 10 21:44:19 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:20 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:27 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:27 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:28 2018 daemon.notice hostapd: Station 20:c9:d0:7c:34:b5 not allowed to authenticate
Thu May 10 21:44:28 2018 daemon.notice hostapd: Station 20:c9:d0:7c:34:b5 not allowed to authenticate
Thu May 10 21:44:30 2018 daemon.notice hostapd: Station 20:c9:d0:7c:34:b5 not allowed to authenticate
Thu May 10 21:44:33 2018 daemon.notice hostapd: Station 50:3e:aa:34:e0:8c not allowed to authenticate
Thu May 10 21:44:34 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:34 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:41 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:41 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:48 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:48 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:48 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:44:55 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:45:00 2018 cron.info crond[2311]: USER root pid 32168 cmd /sbin/fan_ctrl.sh
Thu May 10 21:45:02 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:45:09 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:45:10 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:45:11 2018 daemon.notice hostapd: Station 08:3e:8e:66:92:b3 not allowed to authenticate
Thu May 10 21:45:11 2018 daemon.notice hostapd: Station 08:3e:8e:66:92:b3 not allowed to authenticate
Thu May 10 21:45:16 2018 daemon.notice hostapd: Station c0:9f:05:ac:57:fd not allowed to authenticate
Thu May 10 21:45:16 2018 daemon.notice hostapd: Station c0:9f:05:ac:57:fd not allowed to authenticate
Thu May 10 21:45:16 2018 daemon.notice hostapd: Station c0:9f:05:ac:57:fd not allowed to authenticate
Thu May 10 21:45:16 2018 daemon.notice hostapd: Station c0:9f:05:ac:57:fd not allowed to authenticate
Thu May 10 21:45:17 2018 daemon.notice hostapd: Station ac:a2:13:c9:98:ae not allowed to authenticate
Thu May 10 21:45:20 2018 daemon.notice hostapd: Station f4:f5:d8:3e:13:14 not allowed to authenticate
Thu May 10 21:45:20 2018 daemon.notice hostapd: Station f4:f5:d8:3e:13:14 not allowed to authenticate
Thu May 10 21:45:20 2018 daemon.notice hostapd: Station f4:f5:d8:3e:13:14 not allowed to authenticate
Thu May 10 21:45:20 2018 daemon.notice hostapd: Station f4:f5:d8:3e:13:14 not allowed to authenticate
Thu May 10 21:45:20 2018 daemon.notice hostapd: Station f4:f5:d8:3e:13:14 not allowed to authenticate
Thu May 10 21:45:20 2018 daemon.notice hostapd: Station f4:f5:d8:3e:13:14 not allowed to authenticate

Has anyone got any idea what is happening here? How can I get rid of all these messages?
Thanks in advance.
Tala

jow · May 10, 2018, 1:33pm

In /etc/config/wireless, try setting option log_level 3 in the config wifi-device section(s). This will raise the minimum logged message priority from the default 2 (info) to 3 (notification).

outofscope · May 10, 2018, 1:56pm

Thanks. Any idea what the messages are though? My number one concern is security? I am worried it may be someone trying to gain access to our network?

davidc502 · May 10, 2018, 2:00pm

I have mac address filtering on wifi, and see similar logs. Like yours, I often wonder what these other mac addresses are, and looking them up I get similar results... Google, Samsung etc....

Seems to me there are phantom devices trying to authenticate. Unknown reason why.

I do know that mac address filtering is working correctly as if I don't put the mac address in the list, the device absolutely will not authenticate.

The mystery is why these other mac addresses are showing up. I would like to put the router in a faraday cage and see if these logs are still created. Of course, competing wifi in my area is crazy busy, so who knows what people are doing.

If you don't want the logs see if what @jow suggested will dampen them.

jow · May 10, 2018, 2:05pm

Also note that many mobile phones randomize their wifi MAC addresses for privacy reasons nowadays when scanning for networks, so maybe these logs can also be caused by legit devices roaming into the network.

But it could also be random mobile devices proactively trying to connect to any wifi.

outofscope · May 10, 2018, 2:17pm

Thanks to both of you for your comments. Your last comment jow put my mind at ease a bit more with the theory of 'try and connect to any network' option on many devices nowadays! I am a bit of an old school kinda guy and prefer to keep things to myself if you know what I mean

So, could you please confirm where in my config I need to place that option. Is it in wifi-device section or wifi-iface section?

My config as follows:

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'soc/soc:pcie@82000000/pci0000:00/0000:00:02.0/0000:02:00.0'
	option country '00'
	option channel '3'
	option enabled '1'
	option legacy_rates '0'
	option htmode 'HT20'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option macaddr 'REDACTED'
	option macfilter 'allow'
	option isolate '1'
	option maxassoc '6'
	option encryption 'psk2+ccmp'
	option wpa_disable_eapol_key_retries '1'
	option ssid 'REDACTED'
	option key 'REDACTED'
	list maclist 'REDACTED'

Thanks.

jow · May 10, 2018, 2:18pm

It needs to go into the wifi-device section.

outofscope · May 10, 2018, 2:24pm

Sorry jow I overlooked you specified it for me in your first reply

Thanks to both of you for your help.

jeff · May 10, 2018, 2:51pm

What you're seeing is the result of the "normal" operation of 802.11 devices sending protocol-specified, broadcast "probe" requests to find out what stations are out there and what their capabilities are to consider whether to try to connect to the AP. These probes are generally sent to the "all BSSIDs" address rather than "directed" to your AP. As you have MAC-address filtering enabled, that a non-permitted device is not being responded to is being logged.

It's actually being logged twice as I read the code. Once at an appropriate "debug" level, another at the MSG_INFO / LOG_NOTICE level. While the default configuration of hostap in OpenWRT doesn't log at the debug level, it does log at the LOG_NOTICE level.

See https://bugs.openwrt.org/index.php?do=details&task_id=1468 for more details. There's a quick hack there to remove the code that does the higher-level logging that probably should have a UCI "switch" added, as there are some good reasons to retain the message in certain applications.

outofscope · May 10, 2018, 3:11pm

@jeff - thanks for your informative input as well. As a newcomer, it's always nice to get feedback from multiple participants based on their own experience with this excellent firmware

I will be sure to check out the link you enclosed and see if I can adapt the 'hack' to my setup as well.

Thanks,
Tala

dlang · May 10, 2018, 6:52pm

Many devices that get in range of a wifi AP attempt to connect to it to see if
it's an open internet connection.

cantenna · April 21, 2019, 8:39am

Couldn't this be a sign of someone nearby launching a DeAuth attack?

tmomas · May 1, 2019, 8:39am

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