[FS#1468] hostapd spams log

[LEDE Bugs]

The following task has a new comment added:

FS#1468 - hostapd spams log
User who did this - Jeff Kletsky (jeffsf)

----------
hostapd is an upstream project and widely used far beyond OpenWRT.

''git blame'' suggests that the change in behavior was introduced over a year ago
53d17144 src/ap/ieee802_11.c  (Dedy Lansky               2017-01-17 14:51:02 +0200 1596)        if (res == HOSTAPD_ACL_REJECT) {
53d17144 src/ap/ieee802_11.c  (Dedy Lansky               2017-01-17 14:51:02 +0200 1597)                wpa_printf(MSG_INFO,
53d17144 src/ap/ieee802_11.c  (Dedy Lansky               2017-01-17 14:51:02 +0200 1598)                           "Station " MACSTR " not allowed to authenticate",
53d17144 src/ap/ieee802_11.c  (Dedy Lansky               2017-01-17 14:51:02 +0200 1599)                           MAC2STR(addr));
53d17144 src/ap/ieee802_11.c  (Dedy Lansky               2017-01-17 14:51:02 +0200 1600)                return HOSTAPD_ACL_REJECT;
53d17144 src/ap/ieee802_11.c  (Dedy Lansky               2017-01-17 14:51:02 +0200 1601)        }

The author seems to come from a reputable organization
Author: Dedy Lansky 
Date:   Tue Jan 17 14:51:02 2017 +0200

    AP: Check ACL upon association request for 802.11ad
    
    With device_ap_sme disabled, ACL was checked upon authentication
    request. In 802.11ad there is no authentication phase so need to check
    ACL upon association.
    
    Signed-off-by: Dedy Lansky 

I am puzzled as to why it shows as ''daemon.notice'' and not "info" in the OpenWRT logs. 

I disagree that the log messages are either "spam" or "unhelpful". In diagnosing a problem or resolving an incident, every log message can potentially be the one that provides the clue. Even in a busy environment, knowing what device had just failed to connect can make it much easier to determine which MAC to add, especially for devices that do not easily reveal their MAC to the user, or not at all (IoT devices, for example).

I do agree that OpenWRT users who use the ring-buffer logging system should be able to control the level of messages logged more easily than they can now. Determining why the upstream code suggests that these messages are to be logged as "info" and they appear as "notice" may provide further clues to resolving what is essentially a //logging// problem, not a functional one.
----------

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=1468#comment4611