[FS#1468] hostapd spams log
LEDE Bugs
lede-bugs at lists.infradead.org
Thu Apr 19 12:58:16 PDT 2018
The following task has a new comment added:
FS#1468 - hostapd spams log
User who did this - Jeff Kletsky (jeffsf)
----------
Glad that could get you going -- yes, I won't claim a typo, just a derp on my part.
It may well be that the phone app is just picking up the beacon frames that are periodically broadcast by the AP.
Knowing what stations are in range provide valuable information to the AP operator in a couple of ways. One is when one needs to reconfigure the AP to accept a "new" device. It's often much easier to see the device in the logs, than it is to try to wade through the device's secondary settings screens (especially with a device that the AP operator is not terribly familiar with), and may be nearly impossible with many embedded devices. As an example, there's no screen on an 802.11 light switch, and the MAC address is on a sticker, often buried in the back of the electrical box. Logging the events is also valuable when you believe that your AP should generally not be in range of "strange" devices, and want to know what unexpected devices might be in range.
On a "normal" system, these kinds of log messages can be filtered out into their own log, and that log managed appropriately. Without installing a different logging package, OpenWRT does not directly support this kind of log segmentation, at least that I am aware of. The patch supplied (and modified, as you indicate) the rejection should still be logged at the debug level, which is a noop unless enabled in the configuration of the compile of ''hostap'' sources. As I recall, the config parameter is ''WPA_MSG_MIN_PRIORITY''
----------
More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=1468#comment4628
More information about the lede-bugs
mailing list