OpenWRT patches the source so that the debug-level calls are optimized out by the compiler to significantly reduce the size of the binary. There is a CONFIG parameter that allows setting the cutoff level. It was not an obvious name, and the hostap applications define their own "unique" logging levels that are not the same as syslog.
Ah, there it is
-CONFIG_WPA_MSG_MIN_PRIORITY=3
+CONFIG_WPA_MSG_MIN_PRIORITY=2
Thanks @jeff. I didn't know that option. So I have changed this option to CONFIG_WPA_MSG_MIN_PRIORITY=1 so that I can output messages in MSG_DEBUG. Recompiled LEDE and tested. I still have problems. I can now control log level from UCI, but for some reason only debug messages sent by function hostapd_logger appears in syslog. If message is send by wpa_printf function, then it appears only if it was sent with MSG_INFO parameter. If I change it to MSG_DEBUG, then message is not appearing in syslog, even though that hostapd is started with -s flag (output messages to syslog instead of stdout). So I do not really understand why behavior is like this. Continue testing, but any idea is welcome 
I poked at the "default" logger for a while with similar puzzlement. For that and other unrelated reasons, I moved to syslog-ng and logrotate. Here's a snippet from my syslog-ng config, if you decide to go that way.
destination messages {
file("/var/log/messages" template("$FULLDATE $HOST $PRIORITY $PROGRAM: $MSG\n"));
};
destination wireless {
file("/var/log/wireless" template("$FULLDATE $HOST $PRIORITY $PROGRAM: $MSG\n"));
};
filter f_wireless { program("hostapd") or program("wpa_supplicant"); };
filter f_messages { level(warning..emerg) or not filter(f_wireless); };
log {
source(src);
source(net);
source(kernel);
filter(f_messages);
destination(messages);
};
log {
source(src);
source(net);
source(kernel);
filter(f_wireless);
destination(wireless);
};
I'm using ulogd and logrotate. Not sure if I can configure it as you have done with syslog-ng. Will spend some time tomorrow again trying to figure out with this wpa_printf.
If it helps at all, when I dug into it, I found in src/utils/wpa_debug.c
static int syslog_priority(int level)
{
switch (level) {
case MSG_MSGDUMP:
case MSG_DEBUG:
return LOG_DEBUG;
case MSG_INFO:
return LOG_NOTICE;
case MSG_WARNING:
return LOG_WARNING;
case MSG_ERROR:
return LOG_ERR;
}
return LOG_INFO;
}
Yes, I was it in https://bugs.openwrt.org/index.php?do=details&task_id=1468, but it does not give any extra details. While reading forums, I found this one - Patched package hostapd doesn't log as expected where you have also replied. To me it makes sense that wpa_printf with too low log level gets removed during compilation as suggested by @hnyman. I think stock logger works ok, as it still prints debug messages sent by hostapd_logger function, but it just do not print debug messages sent by wpa_printf. I'll check later today regarding compilation of hostapd and will get back. Worst case I think wpa_printf can be replaced with hostapd_logger where it is needed.
Ok, I dug a bit deeper and I think I found the answer I was looking for.
As stated before, there are two interfaces that outputs messages to syslog (the are actually more, but I'm concerned about those two). One is via wpa_printf and the other is via hostapd_logger.
wpa_printf is not really checking log_level setting in UCI wireless setting. In fact, in current version I have (2018-04-09), wpa_printf minimum level is hard coded into the software to MSG_INFO. So, it does not even check CONFIG_MSG_MIN_PRIORITY. I'm not sure if it was intension, or if it is a bug, but I have changed it with the following path:
--- a/src/utils/wpa_debug.c +++ b/src/utils/wpa_debug.c @@ -29,7 +29,7 @@ static FILE *wpa_debug_tracing_file = NU #endif /* CONFIG_DEBUG_LINUX_TRACING */ -int wpa_debug_level = MSG_INFO; +int wpa_debug_level = CONFIG_MSG_MIN_PRIORITY; int wpa_debug_show_keys = 0; int wpa_debug_timestamp = 0;
In that case wpa_printf will at least take value from CONFIG_MSG_MIN_PRIORITY and will print messages accordingly. I have set it to '1' and got A LOT OF messages, so maybe lower number makes more sense (depends on each and everyone's needs).
Another logging interface hostapd_logger is actually logging hostap based messages and it reads config from UCI wireless, eventually from /var/run/hostapd-phy0.conf. Current log_level value for current hostap is stored in hapd->conf->logger_syslog_level. So, I have patched src/ap/ieee802_11.c file for my own needs only, so that I will get all these connection not allowed messages only if log_level setting in wireless UCI is less than 2. Message will be sent as MSG_INFO, because we get already a lot of information on this error in case CONFIG_MSG_MIN_PRIORITY <= 2. This way I can control only those particular messages with UCI wireless setting. If someone is interested, patch is below (!is_probe part was taken from patch suggested in bugreport in link in post above):
--- a/src/ap/ieee802_11.c +++ b/src/ap/ieee802_11.c @@ -1606,9 +1606,15 @@ ieee802_11_allowed_address(struct hostap is_probe_req); if (res == HOSTAPD_ACL_REJECT) { - wpa_printf(MSG_INFO, + if (!is_probe_req) { + wpa_printf(MSG_INFO, "Station " MACSTR " not allowed to authenticate", MAC2STR(addr)); + } else if (hapd->conf->logger_syslog_level < MSG_DEBUG) { + wpa_printf(MSG_INFO, + "Station " MACSTR " not allowed to authenticate", + MAC2STR(addr)); + } return HOSTAPD_ACL_REJECT; }
Any chance that this will be solved in 18.06.1? I just upgraded from 17.04 and now I have the same issue. I have MAC filtering enabled and I would like to leave it enabled. However the log is now quite useless as I see several log entries per second with "daemon.notice hostapd: Station xx:xx:xx:xx:xx:x not allowed to authenticate". This was not the case in 17.04 so I consider it a bug ... Thanks a lot!
I running 17.01.6, to avoid hostapd messages. In 18.06.1 I didn't find a way to solve it.
In my opinion, the hostapd behaviour in 18.06.1 is not correct (about log messages and filtering enabled).
Yes, I agree. The behaviour is not correct in my opinion. At least it cannot be that you can no longer use the log as you only see such messages. I disabled MAC address filtering at the moment. But I want to enable that again. And yse, I know it is not such a big security advantage, but I still want to enable it 
The question is: What can I do that this will be re-examined and maybe fixed?
You can open a case as bug, and one day will be examined. But, honestly I don't know how to do it.
This was answered a long time ago in this thread... please take the time to do a word search for log
I saw several threads, however I seem to have missed the one where a solution for this issue has been provided? I saw changes in the code done by someone (however that never got implemented in the official code). I also saw the suggestion going to rsyslog, however is this really a solution? These spamming "not allowed to authenticate" messages for MAC addresses which do not really trying to connect to my network (!) were not present in the 17.04 version. Although I saw real "not allowed to authenticate" message if e.g. I tried to connect a new device. So everything was fine in 17.04 and started to go worse in the later releases.
So if you know the solution for that, could you please give me a hint where to look for? Thanks a lot!
Just forgot: I played with the different logging levels but that did not solve it for me. Or I did it wrong? What I want to achieve is the same behaviour as before, so that these "spamming" messages disappear while I still can see real message if someone is trying to connect to my network with the correct passsword but is not allowed because of the MAC filter.
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".