After upgrading to 17.01.0, I noticed hostapd generated a lot of logs as the following
Fri Mar 3 06:38:03 2017 daemon.notice hostapd: guest: AP-STA-POLL-OK 5c:a8:**:**:**:**
Fri Mar 3 06:38:33 2017 daemon.notice hostapd: guest: AP-STA-POLL-OK f4:29:**:**:**:**
Fri Mar 3 06:39:05 2017 daemon.notice hostapd: guest: AP-STA-POLL-OK 18:59:**:**:**:**
Fri Mar 3 06:39:25 2017 daemon.notice hostapd: guest: AP-STA-POLL-OK c0:9f:**:**:**:**
How can I turn of these logging? Thank you.
I've the same issues, not sure how to disable/hide it or it actually is a real problem.
I would like to resurrect this topic. I am trying to tame the logfile a bit, too. My network is not particularly large, but it has some clients in it that are connecting and disconnecting on a regular basis. And consequently, my logfile is filled with entries like
<date> daemon.notice hostapd: wlan1: AP-STA-CONNECTED <mac>
<date> daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED <mac>
sometimes to the point where I can barely see a day's regular router operation anymore.
Digging around a bit I found documented and undocumented UCI parameters. It's a bit cumbersome, but setting
option log_level 4
option log_80211 0
option log_8021x 0
option log_radius 0
option log_wpa 0
option log_driver 0
option log_iapp 0
option log_mlme 0
on a wifi-device should result in the most minimal logging hostapd allows to set through config. When I check /tmp/run/hostapd-phy(x).conf, it correctly says:
logger_syslog=0
logger_syslog_level=4
logger_stdout=0
logger_stdout_level=4
However, I am still getting the abovementioned AP-STA-CONNECTED and -DISCONNECTED lines, which makes me think there's something ever so slightly wrong in hostapd's syslog behaviour. According to syslog/stdout_level it shouldn't log anything less than warnings, and according to syslog/stout it shouldn't log any operation at all (even if a bitmask of 0 might be a bit harsh for regular operation).
Anyone any wiser? TIA!
If you switch from using the default logger to using rsyslog, you can have
complete control over the logs, throwing away any messages (or redirecting them
to a different file)
David Lang
Duly noted, will try. Still, this is a workaround, hostapd is logging things it shouldn't, no?
no, hostapd is logging things that are useful to some people, it's logging them
at debug level so that you have them if you need them, but can trivially filter
them out by only saving logs that are of info level or higher
It's a LOT easier to have the application generate logs that you throw away when
you don't need them than to not have the application generate logs that you need
and have to go in and modify the code to get them
It's only when you have a trivial logger that doesn't implement the simple
syslog filters that have been around for close to 30 years that you have
problems. It makes sense to have such a trivial implementation for LEDE as most
people don't ever look at the logs unless something has gone wrong and at that
point they may need the most detailed logs, and space is tight, so the simplist
implementation fits on low-resource devices.
But if you are actually using the logs, use a real logging daemon, either on
the router, or send the logs over the network to another system that is running
a real logging daemon and consolodate the logs from all your devices/systems
there.
David Lang
I am not trying to be confrontational. Yours is sound advice and in all honesty well appreciated.
Still, I would argue the point that in this instance hostapd is misbehaving and ignoring its own configuration. Maybe I should just file a bug with LEDE's bug tracker, but I am unsure if it is a problem with LEDE or with hostapd itself.
Something is wrong with hostapd ...
Running the actual dev build for wrt1900acs, my log ist spammed with these, cause i have a mac-filter ...
Apr 4 11:03:32 192.168.0.1 hostapd: Station e4:02:9b:af:a5:c8 not allowed to authenticate
Apr 4 11:04:07 192.168.0.1 hostapd: Station 32:d6:6b:b3:52:64 not allowed to authenticate
Apr 4 11:04:07 192.168.0.1 hostapd: Station 32:d6:6b:b3:52:64 not allowed to authenticate
Apr 4 11:04:07 192.168.0.1 hostapd: Station 32:d6:6b:b3:52:64 not allowed to authenticate
Apr 4 11:04:32 192.168.0.1 hostapd: Station e4:02:9b:af:a5:c8 not allowed to authenticate
Apr 4 11:05:32 192.168.0.1 hostapd: Station e4:02:9b:af:a5:c8 not allowed to authenticate
Apr 4 11:06:06 192.168.0.1 hostapd: Station ba:73:f9:ac:ff:c6 not allowed to authenticate
Apr 4 11:06:06 192.168.0.1 hostapd: Station ba:73:f9:ac:ff:c6 not allowed to authenticate
Apr 4 11:06:46 192.168.0.1 hostapd: Station 4c:eb:42:e0:ac:4f not allowed to authenticate
Apr 4 11:07:10 192.168.0.1 hostapd: Station 56:a2:bf:c0:d6:e8 not allowed to authenticate
Apr 4 11:08:48 192.168.0.1 hostapd: Station 16:b5:dd:e9:ad:21 not allowed to authenticate
Apr 4 11:09:12 192.168.0.1 hostapd: Station 22:eb:42:0c:1f:dc not allowed to authenticate
Apr 4 11:09:12 192.168.0.1 hostapd: Station 22:eb:42:0c:1f:dc not allowed to authenticate
Apr 4 11:10:32 192.168.0.1 hostapd: Station e4:02:9b:af:a5:c8 not allowed to authenticate
Apr 4 11:13:00 192.168.0.1 hostapd: Station c0:d3:c0:d4:73:47 not allowed to authenticate
I recongnize about 3000 entries a day, these are not my devices nor any other in my house ...
Running 17.04.4 with the same wireless config, there is no such log entry.
So, this coud not be an spoof attack but a faulty hostapd or config ...
Any hints????
I assume that you've got MAC filtering enabled and are in a "busy" area like a city. If so, you're likely seeing hostapd appropriately logging at "info" level (very low, just above "debug") that it is not responding to the normal probes that are part of the 802.11 protocol from hosts that are not on your list.
It may be that the UCI linkage to logging has changed as suggested in Advice needed about Wifi Security
can you elaborate a bit with the setup of rsyslog setup that does that?
I installed syslog-ng and cant seem to configure filters to do that.
Is there near a resolution ?
I also get this "spamming". Using 18.06.2 on ipq806x and ar71xx routers. Have had to put up with it since I started using OpenWRT back in the Attitude Adjustment days.
I've tried to filter it as much as possible through configuration without success.
This is extremely annoying. Every time I need to troubleshoot an issue when I can find time to look at it, the logs have been overrun with this.
I've resorted to building my own hostapd and wpad packages and adding additional code on the logger methods to not log any LOGGER_INFO messages.
I see the value in having the option to log at different levels, but the default logger should respect the log level specified on System > Logging configuration.
Has anyone come up with a solution for hostapd to respect the global system logging level? No matter what the global system logging level is set to, hostapd info and notice messages are written to syslog.