Add random MAC generation after each reboot

[Timollo]

Router MAC address randomization is crucial for enhancing user privacy by preventing network operators from tracking devices using their real MAC addresses as consistent identifiers. This practice has been adopted by many operating systems, including iOS 8+, Android 8+, and Windows 10, to mitigate tracking methods such as footfall tracking in retail stores. However, more advanced tracking techniques have emerged, necessitating the implementation of MAC randomization not just during network scanning but also during actual network connections. Google's Android 10, for instance, made MAC randomization the default behavior for both scanning and connecting to networks, marking a significant shift towards privacy protection.

[krazeh]

How is the router having a random MAC going to improve, privacy?

[Doppel-D]

If I don't change my WAN MAC every boot I always get the same IP from my provider

[Doppel-D]

Generate a new random WAN MAC address at every boot

As I wrote here Vodafone changed my IPv4 DHCP lease time to 24h but I don't like that ;- ) Thanks to @LEDEuser I started with this, but it didn't work out because macchanger failed, stating eth0 is up. Couldn't deactivate before execution because then macchanger complains about a missing device. I changed the script: #!/bin/sh /etc/rc.common START=99 start() { # Generate a random MAC address new_mac=$(macchanger -e eth0.2 | awk '/New MAC/ {print $3}') ifconfig eth0.2 down ifconfig e…

[elbertmai]

Are you saying that randomizing the router's MAC address enhances the privacy of the devices inside the local network? If so, there's a serious misunderstanding of the purpose of MAC addresses and the threat model that MAC randomization operates under.

First of all, MAC addresses are valid only within a local network. When I connect to openwrt.org on my computer, the (highly simplified) packet flow goes like this:

1. My computer creates an IP packet. Its source address is my computer's IP address. Its destination address is openwrt.org's IP address.
2. My computer wraps the packet into an Ethernet frame. Its source address is the computer's MAC address. Its destination address is my router's LAN MAC address.
3. My computer sends this frame which gets picked up by my router's LAN port.
4. My router strips the Ethernet frame and inspects the IP packet header. It determines it should be forwarded to the ISP's router which is reachable via my router's WAN port.
5. My router wraps the packet into a new Ethernet frame. Its source address is my router's WAN MAC address. Its destination address is the ISP router's MAC address.
6. Repeat steps 3 through 5 for each router hop until the packet gets to the final router connected to the LAN containing openwrt.org's servers.
7. That final router wraps the IP packet into the final Ethernet frame. Its source address is the final router's MAC address. Its destination address is the openwrt.org server's MAC address.

Notice that the MAC addresses of the Ethernet frames change at each hop. The ISP router never sees the MAC addresses of the internal devices. And neither does the openwrt.org servers, or the servers of any other website. (Well, except for LuCI running on the OpenWrt router, of course.)

Second of all, MAC randomization came about because of smartphones constantly transmitting probes in order to find WiFi networks to connect to. A bunch of WiFi APs collectively can use this to track the physical movement of smartphone owners. This scenario doesn't apply to your router, because it's almost always in a fixed location. MAC randomization is mainly useful for WiFi devices that are highly mobile or portable like phones and laptops.

But let's say for the sake of argument that router MAC randomization on reboot is somehow useful. OpenWrt users have uptimes measured in weeks to months, rebooting their device only to install updates or to test snapshots. So are you expecting users to constantly reboot their routers every 24 hours or so, disrupting all current connections?

[LilRedDog]

It is just a troll post.

[Doppel-D]

@elbertmai

So are you expecting users to constantly reboot their routers every 24 hours or so, disrupting all current connections?

My router, modem, NAS, network and devices are switched off while I sleep. Old habbit of mine, especially sleeping ;- )

[krazeh]

While you're free to do what you like with your hardware it is neither necessary or ideal to keep powering off or rebooting modern hardware.

[frollic]

@Timollo

Google's Android 10, for instance, made MAC randomization the default behavior for both scanning and connecting to networks, marking a significant shift towards privacy protection.

... for everyone but google.

claiming it improves online privacy, is simply laughable.

if you don't want to be tracked, stay off internet.

[jedboy]

This is a mod'd script I found somewhere.

I used it a while ago. I think what I did is in the rc.local, I did "wifi down" and then ran this script. Or, maybe some other way to set radio to not start on boot.

#!/bin/sh

LASTFIVE=$(dd if=/dev/urandom bs=1024 count=1 2>/dev/null | md5sum | sed -e 's/^\(..\)\(..\)\(..\)\(..\)\(..\)\(..\).*$/\1:\2:\3:\4:\5/')

#echo $LASTFIVE
MACFULL="07:${LASTFIVE}"
#echo $MACFULL
uci set wireless.radio1.macaddr=$MACFULL
uci commit wireless

wifi

exit 0

[Doppel-D]

@krazeh

it is neither necessary or ideal to keep powering off or rebooting modern hardware.

From my experience over the years it is ideal for increasing the lifetime of the capacitors in the power supplies and a necessity to save ~30W and get a new IP ;- )

@Timollo While useful for smartphones you have to find some other reason at least for stationary routers ;- )

@jedboy On newer versions of openwrt there is already an option for random macs

[xpciuhru]

This forum post is some sort of a duplication of my forum post some days ago: MAC address randomization by removing the ability to read the hardware mac

I search for the same solution but in a best possible way. Sadly no ideas have been posted in my forum post.
@Doppel-D I know of this OpenWrt functionality that have been added. Sadly this fails often like reported few times on this forum. Its not good if the device itself know the real mac address. The best solution is when the device do not know its own mac address. Then it generates a random one at each boot and at the same time its completely impossible for the device to leak the real mac address because its simply unknown to itself.

The two already known solutions to solve this request are listed in my forum post.

1. Remove the MAC address from the device itself (EEPROM, ART partition)
2. Remove the code that know where the MAC address is saved (take a look at changesets that 'fix' the random mac issue some devices have and do the opposite)

If no one have a better idea in mind, probably the best solution is number 1. You kind of enable and disable this random mac address by deleting the MAC address from the SPI memory of the device. If you want it back again, its in most cases printed on the devices bottom and you type it back again.
By choosing solution 1, you dont have to rebuild every single OpenWrt release and if you forget rebuilding and use the stock OpenWrt image with settings reverted to default a leak of the real MAC address is still not possible.

And because it looks like most of you did not get the benefits of this:

1. For example you use the OpenWrt device as a client for a computer with RJ45 cable. Why should the same travel place you use its Wifi know that you are back again? There is not a single benefit except tracking and that is why modern Android ROM's have enabled random mac by default.
2. And for the people who do not get the use case having a random MAC at AP mode. In many countries or local places there are wifi AP's with a widely known SSID. You just scan what is most used and generic in your place and use exactly same. On your Android ROM you enter this SSID and your own password.
   What is the privacy result of this: If your Android ROM always use a random MAC at connection, your neighbor still see on his 24/7 running monitor mode device that at the same time when you come back home from work 'some' random mac address connects. The neighbor have only to track one single BSSID for endless time and have a perfect track of your movement.
   But now you have from time to time a random BSSID together wirh a SSID also other neighbors have. The tracker have to always look at what BSSID is used now. The tracking is simply more complicated. If you are the only person with a changing BSSID, its still obvious but still better then having 0 additional work at just tracking a single BSSID. When more people join the random BSSID solution, it would be more and more work to have good working tracking. On two AP's with same SSID and both changing the BSSID from time to time with only random-mac-clients on both and both having WPA3 would be really the worst possible case for tracking.
   The connection to such a AP would only work, because the phone choose the AP with the stronger signal. Both AP's would still have many random failed login attempts from the other neighbour's clients but this is just how it would be and not that of a huge issue.

[elbertmai]

It looks like we're actually talking about several different things, which is probably the source of all the confusion.

A wireless router typically have several MAC addresses:

• The MAC address of the WAN port
• The MAC address of the LAN port
  • May be connected to an internal switch to provide multiple LAN ports
• The MAC addresses of the radios
  • Called the BSSID and is different per radio and SSID combination

The original post makes no mention of the BSSID. Because of that, many readers here thought the original poster talked about either the WAN or LAN port.

I'm still not convinced that randomizing the AP's BSSID enhances privacy, unless you're also randomizing the SSID? The "travel router as a wireless client" scenario is more compelling, but this use case wasn't clear from the original poster.

[Privacix]

That’s a real problem BTW.

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)

https://api.mylnikov.org/geolocation/wifi?v=1.1&data=open&bssid=00:00:00:00:00:00

This can cause anyone who knows your MAC find your geolocation.

[elbertmai]

That same tool also allows searches by SSID, so unless you're also randomizing your SSIDs (or disable them entirely), randomizing the BSSID doesn't add any privacy.

You also need to physically be in the range of the AP in question to even know what BSSID to use. It's not like I can remotely determine the BSSIDs of your wireless router using only Internet Protocol packets sent to a website I control. I would either need to run malware on your WiFi clients or convince you to tell me your BSSIDs directly.

[Privacix]

@elbertmai

randomizing your SSIDs

SSID should be hidden, but if you want to do something as redundant as randomising SSID, here is instructions:

Randomise SSID instructions

To randomize the SSID (Service Set Identifier) on your OpenWRT router, you can use a script that changes the SSID at regular intervals. This approach requires some familiarity with OpenWRT's command-line interface and scripting. Here's a step-by-step guide to achieve this:

1. Use script:

#!/bin/sh

# Generate a random SSID
SSID=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 10 | head -n 1)

# Apply the new SSID
uci set wireless.@wifi-iface[1].ssid="$SSID"
uci commit wireless
wifi

This script generates a random SSID consisting of 10 alphanumeric characters and applies it to the first wireless interface (@wifi-iface[1]). Adjust the interface index if your setup uses a different one.

3. Make the script executable: After creating the script, you need to make it executable. You can do this by running the following command:

chmod +x /path/to/your/script.sh

Replace /path/to/your/script.sh with the actual path to your script.

4. Schedule the script: To randomize the SSID at regular intervals, you can use the cron scheduler. First, open the crontab editor:

crontab -e

Then, add a line to schedule your script. For example, to run the script every hour, you could add:

0 * * * * /path/to/your/script.sh

This line tells cron to execute your script at the start of every hour.

5. Save and exit: After adding the line, save and exit the crontab editor. The new schedule will take effect immediately.

Now you can check that the SSID is changing by following command to see the current SSID:

uci get wireless.@wifi-iface[1].ssid

Remember to replace @wifi-iface[1] with the correct interface index if necessary.

And here is instruction how to randomise BSSID:

Randomise BSSID

Randomizing the BSSID (Basic Service Set Identifier) on your OpenWRT router involves changing the MAC address of the wireless interface at regular intervals. This can be achieved through a script that updates the MAC address and applies it to the wireless interface. Here's how you can do it:

1. Use script:

#!/bin/sh

# Generate a random MAC address
BSSID=$(printf '02:%02x:%02x:%02x:%02x:%02x' $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)))

# Apply the new MAC address
uci set wireless.@wifi-iface[1].macaddr="$BSSID"
uci commit wireless
wifi

3. Make the script executable: After creating the script, you need to make it executable. You can do this by running the following command:

chmod +x /path/to/your/script.sh

Replace /path/to/your/script.sh with the actual path to your script.

4. Schedule the script: To randomize the BSSID at regular intervals, you can use the cron scheduler. First, open the crontab editor:

crontab -e

Then, add a line to schedule your script. For example, to run the script every hour, you could add:

0 * * * * /path/to/your/script.sh

This line tells cron to execute your script at the start of every hour.

5. Save and exit: After adding the line, save and exit the crontab editor. The new schedule will take effect immediately.

6. Test: You can test that the BSSID is changing by following command to see the current BSSID:

uci get wireless.@wifi-iface[1].macaddr

Remember to replace @wifi-iface[1] with the correct interface index if necessary.

P.S: Do NOT follow instructions blindly, recheck before executing.

[Doppel-D]

One aspect of the BSSID is that is usually has a higher unique value than a (short) SSID and is more persistant over time because it usually won't change and cannot be changed by an user.

Second AFAI guess the first couple of bytes lead to the vendor and could help to determine what AP you are dealing with and attack old and rotten OEM firmware. Gladly we are all using openwrt ;- ) ....but still there are wireless firmware blobs......

So generally it is an interesting peace of information so if I can choose I prefer a randomized BSSID especially if I am surrounded by stock OEM smartphone vendors with particular interests, the Google Android OS itself with its own particular interests and not to forget all the apps with (you guess it ;- ) own particular interests.

And no, I am not diagnosed with some paranoid disorder but that doesn't mean that I am not paranoid ;- )

@xpciuhru

@xpciuhru

I know of this OpenWrt functionality that have been added. Sadly this fails often like reported few times on this forum.

I would really like to make / see some logging to see some facts / evidence

[frollic]

@Privacix

SSID should be hidden,

AFAIK this doesn't do anything for your WiFi security.

@Privacix

Randomise SSID instructions

What's the point, if the password remains the same ?

[Privacix]

@frollic

AFAIK this doesn't do anything for your WiFi security.

This is for privacy

@frollic

What's the point, if the password remains the same ?

It is redundant, as I said, but if you want random password…

Random password instructions

1. Create the Script: First, ensure you have the script that generates the password as described in the previous response.

#!/bin/sh

# Define your password
static_password="your_password"

# Get the current date in DD.MM format
current_date=$(date +%d.%m)

# Calculate the sum of the day and month
day_month_sum=$(date +%d%m | awk '{print $1+$2}')

# Combine the static password, current date, and sum of the day and month
final_password="${static_password}_${current_date}_${day_month_sum}"

# Set the password for the first WiFi interface
uci set wireless.@wifi-iface[0].key="${final_password}"
uci commit wireless
wifi

Let's assume you've saved this script as /usr/local/bin/update_password.sh. Make sure this script is executable by running:

chmod +x /usr/local/bin/update_password.sh

2. Edit the Crontab: Open the crontab for editing by running:

crontab -e

This command opens the crontab file in your default text editor. If you're not sure which editor is set, you can specify one by setting the EDITOR environment variable before running crontab -e, for example:

export EDITOR=nano
crontab -e

3. Add the Cron Job: In the crontab file, add the following line to schedule the script to run at midnight every day:

0 0 * * * /usr/local/bin/update_password.sh

This line breaks down as follows:

• 0 0 specifies the time (0 minutes and 0 hours, which is midnight).
• * * means every day of every month.
• * means every month.
• * means every day of the week.
• /usr/local/bin/update_password.shis the command to run, which is your script for updating the password.

4. Save and Exit: After adding the line, save the file and exit the editor. The exact commands to save and exit depend on the editor you're using. For example, in nano, you would press Ctrl+O to save and Ctrl+X to exit.

5. Verify the Cron Job: You can verify that your cron job has been added by listing the current user's crontab entries with:

crontab -l

This command should show the line you added, confirming that the cron job is scheduled.

Now your password looks like:
pass_DD_MM_DD+MM
For example:
12345678_10_12_22

[loaNga0m]

@Privacix

This is for privacy

how far does this protect privacy?

In order for a client to connect to a hidden network, the client must ask if the network "I pretend to be invisible" is there somewhere, to which the router responds "yes, here I am".

The SSID is then known.