Systemlog is full of mac filter notifications

For Developers
1

Hi all,
can anyone tell me what changed regarding the logging of hostapd from 17.04.4 to the actual development builds? I am running the actual dev build of linksys wrt1900acs (12.04.2018) with activated mac filtering. My log ist spammed with these notifications. I can identify about 180 different mac adresses per hour - i do not think that they could be real, i live in appartment house with only 9 appartments.

If i flash 17.04.4, i do not get any single notification ... both are configured to log level 4.

Any information about this? Is this some kind of debugging functionality that simulates a bunch of mac addresses, or is it an attack?

I have no clue!

Thx, Andreas

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 …
2

Take a look here Advice needed about Wifi Security

3

Sorry, i do not understand how that link could help me - the information is about disabling the logging - i just want to know why the logging changed to include the macfilter log entries- both builds (dev and stable) are configured with loglevel 4 (the lowest logging level).

The point is: Is this some kind of debugging functionality that simulates a bunch of mac addresses, or is it an attack?

4

Have you read the full thread? or just the last message?

5

It's a bug/wrong verbosity in the code, linked to commit eba3b028, as mentioned by @anomeome in the aforementioned thread here (also see this post by @jeff)

6

Neither, it is hostapd logging that it didn't respond to a completely normal, standard "probe" request from some phone, tablet, printer, laptop, .. that happened to be nearby ("Hey, I'm interested in joining a wireless net. If you heard this, would you let me know what you offer?") and wasn't on your MAC address list. They are being logged at the "info" level, very low, just above debug.

7

@ klingon & jeff

Thanks a lot: Now i understand ..

I hope there will be a more detailed log filtering and i am wondering, if the openwrt-project will handle

https://bugs.openwrt.org/index.php?do=details&task_id=1468

8

I use syslog-ng for logging for a variety of reasons. It can be configured to separate out the various sources, log more detail, and filter by just about anything. As a quick hint as to its flexibility

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); };

lets me log all the wireless into one file, everything else and only "important" wireless messages to my "main" log file.

As far as the logging goes, it may be an "upstream" issue or a build-system issue. My guess is that it won't get attention until after the next "release" (as it isn't a functionality issue, and most users never even look at their logs).

9

ok, i will look for a good documentation of syslog-ng ... THX A LOT

10

rsyslog is also a good choice (and is what most linux distros use now)

It's not clear that this is the wrong thing to log. It's something that's really
happening, and if it's not supposed to be happening, it could indicate an attack
(say you were in an area that all cell phones were supposed to be off), but in
general it's not a very useful message.

but most 'info' and 'debug' messages are not very useful, until you really need
to know exactly what's going on.

So it's good for the software to be spitting out these messages, and it's also
good to have the syslog daemon filter them out.

Even with the default syslog option, you should be able to configure it to only
log events of 'warning' or higher, and not be bothered by the lower levels.

11

Uhhhh, filtering is not working here ...

I installed syslog-ng and changed the destination in the syslog-ng.conf on the router to my logserver:

destination messages {
        udp("192.168.0.X" port(514));
};

THIS WORKS, BUT ...

Afterwards, i added this config to the logserver´s syslog-ng.conf

source s_udp
{
    udp(port(514));
};

a) to log all incoming to /var/log(

destination d_router {
        file("/var/log/router.log");
 };

b) a destination to drop filtered messages

destination d_dev_null { 
       pipe("/dev/null"); 
};

c) finally the filters - second one to drop the unwanted info

filter f_router {
        host("192.168.0.1");
 };

filter f_macfilter_regexp {
    message("not allowed to authenticate");
};

d) the IMHO needed log-definition

log {
      source(s_udp);
      filter(f_router);
      destination(d_router);
};

log {
      source(s_src);
      filter(f_macfilter_regexp);
      destination(d_dev_null);
};

What should i say, it does not work ... any help???

Regards,
Andreas