MAC address randomization by removing the ability to read the hardware mac

For Developers
1

Is there some more simple way other then

a) removing the hardware mac address from the write-protected space in the SPI chip

b) removing the ability from the OpenWrt sourcecode at compilation time

to get the same most secure and best working OpenWrt functionality of MAC randomization at router boot time?

There are many reports of broken configurations that leads to releasing the real hardware mac address. For example there is a thread in this forum where someone was expecting random MAC in general, but when used the interface as client instead of AP mode, the real hardware MAC address was used.

All this would be fixed if there is some function, to simply "break" the OpenWrt ability to read the MAC address. Its known, that when the MAC readout from SPI is not working properly(for example a device that is not correctly ported), then OpenWrt does perfectly working and secure MAC randomization for all interfaces at every single boot.

2

I still search for a solution

3

Thats normal router does not read your mind and re-configure.

4

Yes, it does not read my mind and re-configure. To avoid any possible software issues it should simply do not know its MAC address. The OpenWrt log should look something like this one here:

[    0.967061] ag71xx 1a000000.eth: invalid MAC address, using random address

[ 2.135680] mt76x2e 0000:01:00.0: Invalid MAC address, using random address

And ton of other examples available in this forum where it just use some random address. Often people do not want this. But in my case this is exactly what i am looking for.

5

Very good idea - install a known buggy release and never upgrade. No do not change wired mac ever, provider knows your customer linel ocation anyway.

6

That was not the idea and this is not a solution.
Modify for example the ART partition and be careful to not remove the calibration data would be probably something that apply to point a) i mentioned above.
There is not a single person who did this? Because there are few people searching for such a solution but not knowing that it can be achieved that way.
For example a discussion with you here: Can somebody help me with script (MAC generator)? - #42 by tor_hider

7

Randomizing dhcp mac causes operational problems at your provider or in some leaves you without internet.

8

This feature could be good in regimes (err, "locations") where router tinkering may be less welcome.

But in general a random MAC could cause issues as well.

9

This answers are somewhat strange but represent the changed culture these days.
About 15 years ago when a question got asked in the OpenWrt community, in general you got answers that was directed to the solution.
Now the culture change seems like it also get to the OpenWrt community. When you ask something, you get answers like the two above that just say that the person who is asking is stupid and do not know what is doing.
From a different point of view: About 15 years ago the people helped other people to run into possible problems by themself to learn something. Now people just tell that there would be some problems and do not let people run into those by themself.
Maybe i would open a different forum thread to just discuss this topic.

Back to topic: There is no 'ISP'. There is no login to someone else Server. Its just a WiFi device that like about all others ported OpenWrt devices pull out its MAC address from the read-only configured partition in the SPI chip.
I know i have to compile a OpenWrt image where i set this partition to read-write to be able to modify it. Can we now please start discussing how things have to be done instead of talking about if things have to be done?
If i run into some issues afterwards, i would post what issues i have.

10

insmod mtd-rw.ko i_want_a_brick=1 ?

11

At the moment i would like to read somewhere something what i would need to edit in those partition that have the MAC address saved inside. There should be some people in this forum that know some more details about that part.
Knowing what i would need to change in the partition opens up the second need to know how to mount it. If this can be done these days without a custom build image with just
insmod mtd-rw.ko i_want_a_brick=1
then this would save some compile time. Thanks for this information.

12

assuming the device is a supported one, the offset (if I remember correctly) where the MAC is stored, is described in the git commit for the device.

13

So you say wifi mac gets exposed? You can change that to random easily?

14

Do you know if there is some partition checksum i have to take care for?

15

probably not, it's only a guess though, it's your black box hw ...

16

Which place exposes your MAC?

1 Like
17

I would use just some random ath9k based device with ath79 chipset from here: https://downloads.openwrt.org/releases/23.05.5/targets/ath79/
Based on your knowledge at ath79 devices, at least the ones you had your hands on, those do not need any checksum on the ART partiton?

This is one of the latest ath79 devices that have been added with bigger amount of hardware description in the code. This is a port that also require a bootloader swap to u-boot to work and the commit message also mention the MAC addresses:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7e37a457d4849a5598e474bbaaba4552b1a96b8f

3 files have been added
target/linux/ath79/dts/ar9344_nec_aterm.dtsi
target/linux/ath79/dts/ar9344_nec_wr8750n.dts
target/linux/ath79/image/common-nec.mk

and 4 files have been modified that are just related to the OpenWrt build system:
target/linux/ath79/image/lzma-loader/src/board.c
target/linux/ath79/image/tiny.mk
target/linux/ath79/tiny/base-files/etc/board.d/02_network
target/linux/ath79/tiny/base-files/lib/upgrade/platform.sh

The .dts file does not tell itself where the MAC address is been taken from. #include "ar9344_nec_aterm.dtsi" explains it better. This seem to be also used on other NEC Aterm based devices later on added from same developer.

In this dtsi file there is

macaddr_config_6: macaddr@6 {
reg = <0x6 0x6>;
 };

But this looks to be some part of the NVMEM. Not the ART partition. The NVMEM and ART are configured read-only in the dtsi file. insmod mtd-rw.ko i_want_a_brick=1 still does the trick later on both of those partitions?
Is in this example the NVMEM partition@20000 and ART partition@30000 both places that have to be modified or am i misunderstanding the code?
The cal_art_1000 looks to be used for the wmac:

&wmac {
status = "okay";
nvmem-cells = <&cal_art_1000>;
nvmem-cell-names = "calibration";
};

To my knowledge calibration data is different from the mac address.
Can someone explain this part into more detail in this thread?

18

Wouldnt it be more futureproof to detect all points where device ID-s are exposed and provide configure option to randomize them?
Somehow wrenching out MAC does not sound very GA

19

What future are you talking about? Could you go into more detail in what future this would not be working any more?

This is not somehow. Its removing the MAC address to use the fallback mac randomization from the Linux kernel. This solution does not need any additional software, does not use up any additional space and you do not have to think about it when resetting the configuration or flashing a different OpenWrt image.
If you need a fixed MAC address, then you enter the MAC address you like to exact the place where it every OpenWrt image is looking for it. If you do not need a fixed MAC address, then you do not set a fixed/valid MAC address at this point.

20

Internet works exactly other way around. Would be nice from you to make a bug report or pull request to blind or randomize external protocol ID-s in place of modding device.