Hi, I want to suggest a feature for AP with OpenWRT Firmware. The Feature that I want to suggest is the
Random Mac (Toggle On or Off).
This said feature is to prevent some Wifi Deather Jammer. that can sabotage some Deployed AP.
Every time the AP reboots. the wifi mac will be changed so that the information of the wifi will be changed and the jammed wifi will be free again.
You should be able to script it, then add it to rc.local ?
That's "deauther", as in "de-authentication", nothing to do with "death". And deauthing is not jamming.
Nitpicking aside, out of sheer curiosity, do you suffer from such malicious actors?
When you set a new mac address, do you:
?
If you do this once the device have completely booted, the setting will kick in during next reboot (or network restart).
This would be sufficient then in rc.local: (untested)
#!/bin/sh
random_mac(){ printf "%012x" $(( 0x$(hexdump -n6 -ve '/1 "%02X"' /dev/urandom) & 0xFCFFFFFFFFFF )) | sed 's/../:&/g;s/^://';}
uci set network.wan.macaddr $(random_mac)
maybe random_mac could be inserted into rc.common via PR?
something like this?
random_mac(){
printf "%012x" \
$(( 0x$(hexdump -n6 -ve '/1 "%02X"' /dev/urandom) & 0xFCFFFFFFFFFF )) |\
sed 's/../:&/g;s/^://'
}
Sorry for that, here in our place. deauther esp8266 is widespread here because paid wifi here in our country is one of the trend businesses in the Philippines—they use deauther to sabotage a certain Deployed AP so that the Dumb AP will be unusable. my competitor uses this malicious device to pull down my sales.
So what I need for all my OpenWRT AP is to set a random Mac address when they are attacked. With just one click of the restart button in the wifi interface then the Mac will be changed. but the thing is they can also be attacked multiple times but only a single AP can attack.
Then start testing it ..
rc.local
#!/bin/sh
random_mac(){ printf "%012x" $(( 0x$(hexdump -n6 -ve '/1 "%02X"' /dev/urandom) & 0xFCFFFFFFFFFF )) | sed 's/../:&/g;s/^://';}
uci set network.wan.macaddr $(random_mac)
uci commit
edit: it might need a commit at the end
If your AP supports 802.11w Management Frame you should consider setting it to "required" as it was designed to try and stop these types of attacks.
Read some more on this here https://en.wikipedia.org/wiki/IEEE_802.11w-2009
Also switch to 5Ghz if possible. The 8266 only operates on 2.4Ghz.
Random MAC is a great idea.
I also must say I like your multi AP idea as the 8266 can only deauth one AP at a time.
Building on the multiple AP idea: in theory you could go with 10 AP's. Reboot each one once per hour staggered in 6 minute intervals using luci-app-netcat (or cron job uci network restart). When clients get deauthed or the AP reboots they just jump to one of the other 9 AP's.
They would have a damn tough time trying to deauth that.
OR start smaller with 5 AP's staggered timewise to reboot every 12 mins.
They would need one deauther per AP to dos it. Those deauthers still cost $20-30USD each (unless they can roll their own $5-10USD?) - how many can they afford? How many loose circuit boards with volatile 18650 lipos can they carry in one bag without something shorting out?
All client devices sold nowadays are 5Ghz 802.11ac compliant so migrating to WPA3 with mfp enabled should solve all 8266 problems (or flipper which uses 8266 and can't use dongles from what I read).
Owrt can run WPA3 w/mfp on 2.4Ghz as well.
Older client devices may not be able to connect to the newer standards - but you can keep the deauth proof array of 2.4Ghz AP's running for them.
You can also run kismet on an old laptop to detect attacks in real time (under alerts tab) in order to track their activity.
Sorry for the redundant novel but this guy's business is getting attacked and he needs help ASAP.
Does anyone know if it is possible for owrt to detect a deauth attack and then change macs?
I think like everyone else said, use 802.11w (managed frame protection) this would do alot to prevent it, and the mac address changing if you managed to make a script or if someone else did.
But what maybe also works depending how the use case is, having another router operating on a different channel with same ssid and then enable roaming 802.11s with the mobility domains.
from my experience devices always want to get the closest available one, if one went down it falls back, that way you can have it work as a failover, i don't think someone with a wifi deauther considers buying two deauthers and most of their software only targets one ap, and they probably are not savvy enough to see there are 2 routers on the same ssid 
I would have done this too, perhaps not with 11s (never really tested it) but 11r, since it's very easy to set up, then just alternate, swapping the MAC on every boot.
Ah I made a mistake in my writing i ment using 802.11r not 802.11s which is mesh, but the cool thing is I see even devices like aqara switch ap if one went down which I did not expect i think this works aswell on older devices 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.