MAC of your home router MUST be randomised


Found this two articles:


Your Wi-Fi router could tell everyone where you live — here's what you can do about it | Tom's Guide

Now let’s look it practical!

Creepy part

And ready to use tool from GitHub and article how to use it.

Also you can check your MAC like this example (replace 00:00:00:00:00:00 with your routers MAC and just follow in browser)

There is one more untested database:

Let’s fix it!

If you are not using OpenWRT, it’s time to start now, because all instructions below will be given for OpenWRT.

P.S: Don’t follow instructions blindly, check if your router supports such operations.

Technical part
  1. Create the Script
#!/bin/sh /etc/rc.common


prefix='28:6A:BA' #prefix used for the mac address, randomizing this part gave strange errors (sometimes)
iface=0 #interface number according to: uci show wireless
renew=39600 #timeout to renew the mac address in seconds


start() {
 if [ -f "${pidfile}" ]; then
    pid=`cat "${pidfile}"`
    if [ ! -z `top -bn1 | awk '{if ($1 == "'"${pid}"'") print $1}'` ]; then
      logger -t "mac changer" -s -p daemon.error "already running!"
      return  1
 logger -t "mac changer" -s -p "started"
 while [ true ]; do
    mac="${prefix}"`hexdump -n3 -v -e '/1 ":%02X"' /dev/urandom`
    network=`uci get wireless.@wifi-iface[${iface}].network`
    if [ $? -ne 0 ]; then
      logger -t "mac changer" -s -p daemon.error "iface ${iface} not found, exiting"
      exit 1
    uci set wireless.@wifi-iface[${iface}].macaddr="${mac}"
    uci commit wireless
    logger -t "mac changer" -p "new mac: ${mac} set for: ${network}"
    [ "$action" != "boot" ] && /sbin/wifi restart 2> /dev/null || action=''
    sleep "${renew}"
 echo $! > "${pidfile}"

stop() {
 if [ -f "${pidfile}" ]; then
    pid=`cat "${pidfile}"`
    rm "${pidfile}"
    if [ ! -z `top -bn1 | awk '{if ($1 == "'"${pid}"'") print $1}'` ]; then
      kill ${pid} $(top -bn1 | awk '{if ($2 == "'$pid'") print $1}')
      logger -t "mac changer" -s -p "stopped"
      return 0
 logger -t "mac changer" -s -p daemon.error "not running!"
 return 1

This script is designed to run at startup (as indicated by START=17), generate a new MAC address with a fixed prefix, and apply it to the wireless interface specified by iface=0. The renew variable determines how often the MAC address is renewed. Adjust the prefix and iface variables as needed for your setup.

Alternative script by ChatGPT (untested!):

# Generate a random MAC address
MAC=$(printf '02:%02x:%02x:%02x:%02x:%02x\n' $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random))

# Apply the new MAC address to the WAN interface (replace 'wan' with your interface name if different)
uci set network.wan.macaddr=$MAC
uci commit network
/etc/init.d/network restart
  1. Save the Script: Save the script to /etc/init.d/macChanger. This location is standard for init scripts in OpenWRT (macChanger you can replace name if you want)

  2. Make the Script Executable
    Run chmod +x /etc/init.d/macChanger to make the script executable.

  3. Enable the Script
    Enable the script to run at startup by executing /etc/init.d/macChanger enable.

These databases are not particularly new. Adding _nomap to the WiFi SSID will opt out of the Microsoft/Google one. Also setting your SSID to hidden will help.

Probably a good idea to do that as well otherwise a random one will be mapped at your house anyway.

Should this be added in a PR to privacy guides?

Also this may cause unexpected issues according to a forum post on OpenWRT along with this disclaimer:

what use is it to successfully fool google/ apple/ microsoft about your AP, if the neighbours’ APs 6m left and right are loud and strong in their database.

This will attract more attention I think…

That’s what I recommend + set random MAC

Here is new scripts that probably should help you:

Mimic script:
# Define MAC address prefix

# Generate a random MAC address with the Apple prefix
NEW_MAC=$(printf "%s:%02X:%02X:%02X" $PREFIX $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random))

# Apply the new MAC address to the router's interface (replace wlan0 with your interface name)
ifconfig wlan0 down
ifconfig wlan0 hw ether $NEW_MAC
ifconfig wlan0 up

Prefixes (as example):

  • Apple: The prefix for Apple devices is 00:1B:63.
  • ASUS: ASUS devices use the prefix 00:11:22.
Change MAC when no devices are connected (UNTESTED!)

# Function to generate a random MAC address
generate_random_mac() {
    local OUI="00:11:22" # Replace with your router's OUI
    local RANDOM_MAC=$(printf '%02x:%02x:%02x' $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)))
    echo "$OUI:$RANDOM_MAC"

# Check if all devices are disconnected
if [ $(iw dev wlan0 station dump | grep -c Station) -eq 0 ]; then
    # Generate a new MAC address

    # Apply the new MAC address to the wireless interface
    ip link set dev wlan0 down
    ip link set dev wlan0 address $NEW_MAC
    ip link set dev wlan0 up
Change MAC by time:

# Function to generate a random MAC address
generate_random_mac() {
    local OUI="00:11:22" # Replace with your router's OUI
    local RANDOM_MAC=$(printf '%02x:%02x:%02x' $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)))
    echo "$OUI:$RANDOM_MAC"

# Apply the new MAC address to the wireless interface
ip link set dev wlan0 down
ip link set dev wlan0 address $NEW_MAC
ip link set dev wlan0 up

Replace wlan0 with the name of your wireless interface if it’s different. Also, replace 00:11:22 with the first three octets of your router’s original MAC address to maintain the same OUI.

To schedule this script to run for example at 12:00 and 0:00, you can add the following lines to your crontab:

0 0 * * * /path/to/your/
0 12 * * * /path/to/your/

To edit your crontab, use the command crontab -e

I think yes. It is good idea :slight_smile:

1 Like

On some devices you can select a specific BSSID your device is permitted to connect to. Is there a security benefit to this that would be negated if the MAC was randomized and you are unable to leverage this feature?

What? I wrote about randomising router’s MAC, not devices MAC. Even if router’s MAC randomised this feature would work.

P.S: Phones have random MAC from factory so this feature will not work with new smartphones.

I’m referring to the broadcast MAC of the router, are you not also? I was not referring to the client MAC of the connecting device.

Depending on how often you randomize it would have an impact to the BSSID MAC selection when connecting.

1 Like

You should only know SSID + Password. In my case there is absolutely no impact on connection or stability.

Your devices will connect even if MAC randomised.

BUT! Some “stupid” internet devices like thermometers or anything like that can probably experience some issues.

I think we are misunderstanding eachother. My question was whether there are security benefits to ones ability to restrict connection to a specific BSSID that would outweigh the privacy benefits of randomizing the MAC address on some interval of time.

1 Like

Maybe it would be more constructive if you outline the scenario in which you are imagining using your BSSID strategy to improve security?

It could be that I’m misunderstanding the utility or the use-case for this strategy, but it seems that it would have limited value in the context of your home router, unless (1) you have reason to believe you are being (or might be) actively targeted by a motivated adversary in close proximity to your router, or (2) you live in a crowded environment (like a big apartment building) and are worried about either an opportunistic threat. If I understand the feature correctly, I’d think the primary utility of locking to a specific BSSID would be using that feature for public wifi and other contexts where its more likely someone would be attempting to impersonate/spoof an SSID.

Am I thinking about this correctly, or have I misunderstood the technique you are referring to?

1 Like

I wasn’t positing any specifics, but asked if there were any implications under the assumption the client feature of isolating BSSID existed for a reason. I agree those threats/use-cases are rather obscure, and couldn’t think of others. Hence the question.

I wouldn’t use ifconfig in any of those scripts that’s from the old net-tools package. ip link set dev is the correct way to do this on a modern linux system.

It looks as if this feature has been implemented upstream and is exposed in luci. There is some discussion about it including the code that your ChatGPT answer spilled out.

I would go with a design that uses the uci comamand to do this though and not modify the interfaces directly with ip link or ifconfig, as that is bound to cause issues. It certainly should come with warnings as this is not possible with all drivers.

If it were added it could be added as a section under the openwrt card. Would highly suggest checking it actually works though first.I have a few openwrt capable WiFi Devices I can test this on TDW8970 and some original UniFi APs.


I also have and OpenWRT device. I’ll report back my findings in probably a week of usage.

Should also mention doing that will cause your devices to look for that network in the area.

I think all three are worth suggesting. I would not use strong words like “must” as I think it’s overly alarming for something which isn’t particularly serious.

  • bssid randomization
  • hidden ssid (but disable wifi when not in area)
  • nomap

The reason being is that

  • BSSID randomization isn’t always possible (depends on driver and if the device even supports it or openwrt).
  • Hidden ssid has downsides such as if you have a lot of people in your household then they might forget to disable wifi on their devices when not in the area. Those devices will scan for the BSSID when not in area
  • Some drivers cannot connect to hidden networks, I have one such Lenovo laptop which has that problem. It is quite common for IoT related devices to not work with hidden networks, and be confused by randomized BSSIDs. Ie if the BSSID changes from the first time you connect to the device it may refuse to connect in later attempts.

I believe that if the BSSID changes, most devices will not reconnect to the Wi-Fi network automatically.

If this were to happen, it could pose a security issue. For instance, a malicious actor could create a hotspot with the same SSID as a network to which you have already connected, and your phone would automatically connect to it.

Which is why I am having second thoughts about this even being mentioned.

It’s going to break a lot of really shouldn’t be done. If you hide the network, you will still be able to detect it with promiscuous scanning tools anyway.

_nomap is the least dangerous, way to prevent white hat WiFi netowrk mapping. If someone really wants to find your WiFi network there is nothing you can do.

If I remember correctly NetworkManager puts the BSSID in the WiFi configuration on linux automatically.

Is the solution MAC randomization or is it disabling IVP6 and/or ensuring your devices are not using the EUI-64 MAC to generate the IPV6 address?

Makes sense for devices (phones laptops etc) but not base stations (access points).

1 Like

Linking the MS opt-out for visibility as an alternative to _nomap: (MS specific)

In my opinion the solution for that is using a very generic SSID and a random but fixed BSSID.

I am certain that Google’s use of Wi-Fi network names and MAC addresses for its location data is on the edge of legality.