Please see this post by @jeff on April 3
- A word search for "log" would have shown this [#20]...
I saw that post already yesterday and I added " option log_level '3' " to both of my wifi-device configs. That did not change anything (even with log level 4!). But jeff also states below of his post that he does NOT have MAC filtering enabled. So if I disable MAC filtering then I also do not see any of these messages (which seems to be obvious ;-)) Later you answered that MAC filtering provides negligible security. Maybe, but I still want to enable it 
With MAC filtering enabled I still see these messages in the log.
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:16 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:17 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:17 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:17 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:52 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:52 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:54 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:54 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
I cannot relate any of these MAC addresses to any of my devices. All my devices are correctly connected and have other MAC addresses. I did not see that until yesterday morning (where I upgraded from 17.01 to 18.06). I do not see this as an attack on my network but I also have no explanation where these message are coming from. As I said, with 17.01 I only saw these kind of messages if a new device really wanted to connect to my network but was not allowed to (I regularly saw these messages if I forgot to enable a new device before...)
In the threads the opinion is that these messages are "normal" as every device nearby m ynetwork e.g. from my neighbour might be causing such messages. In that case I am asking me why I did not see such spammy messages before? My neighbourhood has not quite changed between before an after the upgrade?
The reason is a faulty commit in upstream hostapd which changed the logging of this message in a way that ignores the verbosity settings in the hostapd config, or rather uses an inappropriate log level (LOG_INFO) instead of a lower priority one which would be normally filtered away.
Someone has to report it upstream to the hostapd developers so that it gets fixed there.
Ah, now we are coming closer 
"Someone has to report it upstream": However, I am not sure what exactly is meant by that. Anything I can/must do?
Did you restart services / reboot router after making the change?
I restarted wifi via the web console for "4". And rebooted for "3".
The only "fix" would then be to disable MAC filtering. MAC filtering offers minimal security, as anyone can garnish wireless MAC addresses being utilized with the proper software. Rather than providing a lengthy explanation, to understand how/why, it would probably be more beneficial to google it.
1 Like
I know that ... I still want to have it As "jow" commented above it seems to be a bug with the logging of these messages (which was not there in earlier releases). So for me the correct "fix" would be to fix the hostapd logging behaviour. Unfortunately I have no understood what exactly "jow" wanted to tell me with "Someone has to report it upstream to the hostapd developers". Can I do that and how should I do that in that case? Or does anyone else need to do that? In this case who and how can I tell him?
In other words, someone has to file a bug report with the devs of hostapd directly
If I understand it correctly, then this has already be done some months ago:
At least it looks like our problem ...
I just sent a mail to one of the developers of "hostapd" and asked him to have a look ...
Seriously though, if this is an important enough issue for you, and you want to get control of your logs quickly, installing and configuring a better logging daemon and setting up filters would be not that hard.
Debian uses rsyslog so that's the one I'm more familiar with. https://www.rsyslog.com/
the line
:msg, regex, "Station .* not allowed to authenticate" ~
should cause rsyslog to throw those messages away
1 Like
Good to know, but that's not the point. Something was "broken" along hostapd updates.
Sooner or later will be fixed. Time to wait.
Here is the answer I just got from Jouni Malinen HOSTAPD developer):
Thanks for letting me know. I dropped the priority of these messages
(and well, dropped some of the messages completely from the new Probe
Request frame case where they were not supposed to show up) in this
commits:
https://w1.fi/cgit/hostap/commit/?id=6588f712220797c69dbd019daa19b82a50d92782
https://w1.fi/cgit/hostap/commit/?id=dc1b1c8db7905639be6f4de8173e2d97bf6df90dI'd expect OpenWrt to pull in those commits when they update their
hostapd version the next time.
So, now we need to wait until the changed code of HOSTAPD will be included to OpenWRT 
4 Likes
Fixed today:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3e633bb3709611d79965fab667e3239fd3bde151
I still see " Station xx:xx:xx:xx:xx:xx not allowed to authenticate" after installation today's wpad package (Tue Oct 16 18:36:28 2018) and rebooting device
Installing wpad (2018-04-09-fa617ee6-5) to root...
Downloading http://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a7_neon-vfpv4/base/wpad_2018-04-09-fa617ee6-5_arm_cortex-a7_neon-vfpv4.ipk
Configuring wpad.
You noticed that this version does not have today's date, correct?
I'm certain that you should wait until tomorrow, when the software is likely compiled by the buildbot.
I found commit with fix only in master branch.
Will the fix be backported to openwrt-18.06 branch?
You'll have to ask the developers. It should definitely be included in:
- The next Snapshot
- 18.06.2
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.