Advice needed about Wifi Security

Can be considered as a bug? Or just is showing more info (not a bug).

imo, an issue that needs to be addressed; assuming it truly cannot to turned down by log level settings.

Thanks @anomeome @jeff @JW0914 for your help!!!!

        if (res == HOSTAPD_ACL_REJECT) {
                           "Station " MACSTR " not allowed to authenticate",
                return HOSTAPD_ACL_REJECT;

Can certainly be handled by syslog-ng or another logging system that can filter messages. A priority of "info" is the next one higher than "debug", so seems appropriate to me.

Edit: It may be possible to change the default logger to only show "notice" and higher, but I haven't found coherent documentation on how to do so. That assumes that there is nothing at "info" level of interest from other loggers.

Right, but it no longer seems to honour settings in /etc/config/wireless, at least not as it once did. And this:


is not in agreement with the wiki, I have not gone back to check when it changed though.

I just did a quick check here, with a recent master build. With as guidance, I added option log_level '3' to the wifi-device stanza. I'm not seeing "info" messages anymore (though I'm in a pretty quiet environment). I see the UCI config reflected in



Do you have a:

    option macfilter 'allow'
    list maclist 'xx:xx:xx:xx:xx:xx'

in stanza as well. I think this may be the trigger, but not sure. I have the log_level setting, always have actually.

Yes, I'm using it.

@anomeome No, I don't have MAC filtering turned on.

and yes I'm aware this is is as useful as the proverbial, mammaries on a male bovine, before someone leaps in with the obvious. But it is still an issue

As I mentioned above, MAC filtering provides negligible security, as while it will work for obfuscation from the run of the mill neighbor, it's easy enough to determine what MACs are transmitting and receiving in any given area.

  • Once garnished, it's a matter of narrowing down which MACs are communicating with what APs, at which point those MACs can be cloned.

  • This shouldn't deter anyone from utilizing MAC filtering, but users should also be aware it is easy to bypass... this is why the recommendations in Wireless Overview -> Wireless Security should be followed.
  • make sure that you force CCMP (AES) and use a strong password
  • use at least 17.01.4 to ensure that you are protected against Krack and Spectre
  • Enable the Krack and Spect countermeasures

What doesn't work well:

  • MAC restrictions
  • Hiding SSID

Good link!

I agree with you, but in my case I use MAC filtering in the same way I use DHCP with static leases for MAC, it's not for security, for security I use WPA2 + CCMP, I use MAC Filtering + DHCP with static leases to "tidy up" my home network, not as security system.

I would check for ports open to the Internet...

GRC ShieldsUP!

SpeedGuide Security Scan

@Klingon, I opened FS#1468 regarding this.

Edit: Under no circumstances should you read any of the above to understand the gist of what has happened/changed. If the author of that change is happy with the new spam that is occurring...

Edit2: Do you actually expect me to regurgitate that which has been written above. Everything you have asked is in the posts above.


You opened a bug report?

  • OP made a MAC filter
  • Others are connecting not on that MAC filter
  • The log tells you...

How is this s bug???

Albeit, it's not good it is a Security is one. I doubt it will be taken as a bug.

Can't you lower the logging level?

How can I do it?

See section on

Logging hostapd behaviour

1 Like

Finally I decided to disable MAC Filtering, and now the log has came to "normality".

Maybe technically is not bug, I can't discuss that, but in my opinion is not a correct behavior in hostapd logging.

Not true at all. It makes it more difficult and time consuming, and will protect you from people trying to guess the password that connect to your router manually brute forcing....

But it's easy to capture the EAPOL packets using tools such as aircrack-ng suite. At that point you just run aircrack-ng against that capture file with a wordlist. You don't even have to be near the router once the handshake is captured while it is cracking as it's all done at this point without having to attempt to authenticate with the router.

It's time consuming, and resource consuming, but is not out of the realm of possibility. If your password is n characters long, and the person has a wordlist of all combinations of characters up to your password length or greater, it can be cracked. It may take months or years, depending on the machine(s) used to crack it, but it still is possible. If you have access to a botnet and can distribute the work it makes it faster, as well as using GPUs.

So in conjunction with a complex WiFi password, changing it regularly also improves security. Changing your passwords regularly is just security basics 101.

1 Like