Auto-deny wireless rogue devices

From time to time, I notice that one of my APs is starting to act weird (clients cannot connect, there is no traffic flowing, ...); upon watching the logs, I see and endless sequence of messages similar to these:

Sat Nov 27 16:27:52 2021 daemon.notice hostapd: wlan_iot: STA 84:e3:42:b5:ac:21 IEEE 802.11: did not acknowledge authentication response
Sat Nov 27 16:27:52 2021 daemon.notice hostapd: wlan_aux: STA 84:e3:42:b5:ac:21 IEEE 802.11: did not acknowledge authentication response

Looks like some rogue device (that does not belong to me) is probing all my SSID's in sequence, over and over again, effectively blocking any other device. I usually solve this by adding the MAC address to the deny list, but I would like to find a better solution.

Has anybody had the same issue? How did you solve it? Thanks!

1 Like

I've not experienced that behaviour so far, but I'd probably ask at http://lists.infradead.org/mailman/listinfo/hostap for this.

2 Likes

Use the whitelist instead?

2 Likes

I would try to rename the SSID, this might be by accident, having same SSID as the "rogue" device. The built in mechanism for connecting the wifi is when the SSID matches, it starts authentication.

These devices are hitting all my SSIDs on all my routers... it cannot be a coincidence.

Then, how about this? https://www.oreilly.com/library/view/wireless-hacks/0596005598/ch04s19.html

1 Like

Yes, this is what I am doing now. But each time this happens, it leaves my network unusable, until I figure out what is happening, then I have to add the MAC address manually. That is why I was looking for some automated solution. Thanks!

cat << "EOF" > /root/wifi-fix.sh
WIFI_MSG="did not acknowledge authentication response"
WIFI_STA="$(logread -e hostapd \
| awk -e "/${WIFI_MSG}/{print \$10}" \
| sort -u)"
if [ -n "${WIFI_STA}" ]
then for WIFI_STA in ${WIFI_STA}
do uci add_list wireless.@wifi-iface[0].maclist="${WIFI_STA}"
done
uci set wireless.@wifi-iface[0].macfilter="deny"
uci commit wireless
wifi reload
/etc/init.d/log restart
fi
EOF
cat << "EOF" >> /etc/crontabs/root
* * * * * . /root/wifi-fix.sh
EOF
uci set system.@system[0].cronloglevel="9"
uci commit system
/etc/init.d/cron restart
1 Like

This would work and is a simple and clever script.

But wouldn’t this have the side effect of blocking legit devices for which the password is accidentally entered incorrectly? I’m thinking of a houseguest who makes a typo while entering the password. So then, @eduperez would need to find the legit MAC and remove it from the block list.

1 Like

Or list of pre-selected legit MAC can be stored in some db from where the script checks if the subject mac is present in the list or not before blocking it for good. But this might be complicated to implement.

At that point, you'd be talking about an allow list rather than a block list.

I think that the challenge here is that @eduperez seemed to suggest that the allow-list approach (deny all, allow those explicitly listed) becomes problematic because the allow-list is forgotten until a new device is have trouble joining. Then the MAC needs to be located on that device and added to the allow list.

OTOH, an automatic block-list might be more appealing, but it has the side effect I described earlier where the user has one shot to enter the credentials properly, else be banned and require extra effort to unblock.

@eduperez -- I'm curious -- do you see the same MAC addresses probing over and over again? How many of them do you see? How often is each probing and how often do you see new ones appear? I ask because your block-list may become extraordinarily long if you're seeing them change frequently. And if you only see a given MAC once or twice anyway, the block-list doesn't really do much good since it may block MACs that don't ever probe again.

Also, when you said this:

do you mean to say that these probes are actually making it difficult for your legit devices to join the network?

Yeah, i was also talking about the allow list, may've interpreted wrongly.

Yes, this is quite close to what I was looking for; many thanks!

1 Like

So far, this has only happened about half a dozen times; so, the list of blocked MACs is still manageable.

When it happens, I detect one single MAC address probing (in a round-robin sequence) all the SSIDs on thew 2.4GHz band from one of the APs, continuously. I block it on that AP, then the same happens on the other AP, until I also block it there. It is silent for weeks, then another MAC address starts again.

Yes, that's exactly how I detect the probes.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.