Wait really? Is that a fact? Cuz I tested this back in 2020 and I remember Mac addresses from network manager are based on OUIs, if that is true I should really apologize here
Edit: I’ll look it up again, if you are right I should be really embarrassed here lol
God, deep me in tar and dust me in feathers, you where right, I checked my notebook and this is my exert:
“”"
To have an at a glance valid MAC address I have to acquire an OUI list usually provided up to date by hacking based repos like pentoo, black arch or kali, create edit the randomization section of network manager to contain ethernet/wifi.generate-mac-address-mask= (insert OUI triplet and leave the last 3 triplet empty)
“”"
So in essence if an OUI provided by Intel is 12:34:56 then you write 12:34:56:00:00:00
In cases you have multiple OUIs to base yourself on you leave a space and continue with the next Mac address, 00:00:00 fields are randomized as far as I remember
I was wrong on a large margin here but this sure beats having the WiFi modem provider and everyone around you log your WiFi Mac and then change it like op has provided in his script, at least that’s how I perceive this working
My thinking for random instead of stable was: It’s probably common to use the same NetworkManager connection profile (e.g. the default Wired connection 1) to connect to several Ethernet networks over time. If sys-net is not rebooted in between, those networks would see the same stably randomized MAC address.
Maybe qubes-core-agent-linux could ship two inactive drop-in configuration files (one with stable and one with random), so that people can opt into the approach they prefer.
Yeah cause choosing a plausible OUI is outdated. In the past, MAC randomization was uncommon and might have marked someone as being up to no good. Thankfully that’s no longer realistic. E.g. Android 10 (released 2019) made full randomization the default, stably per Wi-Fi network. Full as in: Set the first octet’s least significant bit (multicast) to 0, set its second least significant bit (locally administered) to 1, and randomize the remaining 46 bits. That’s the modern approach to MAC randomization. Even the Tails developers, who are very mindful about some people’s need to blend into the crowd, nowadays intend to switch to doing it that way.
That said, no disrespect intended for @leandroibov and @aiziot9831non for the underlying drive to not be tracked! If you’re a bit nostalgic for the previous state of affairs 
may I suggest the wild west of IMEI randomization? Which seems like it’s about as esoteric, hardware dependent, and vaguely scandalous as MAC randomization once was.
I researched using MAC addresses with OUI via NetworkManager to see if it can solve the issue of always having MACs from manufacturers like it happens with macchanger -a or macchanger -A.
I found two links with documentation for nmcli:
As you can see, we have this option in the documentation: generate-mac-address-mask, and I believe the right path to fix this bug is through it!
The approach I intend to follow is to register the OUIs of specific manufacturers (or potentially all OUIs I can get), or even specific categories, in the NetworkManager configuration files, and then try to resolve the issue and get MAC spoofing using MACs from real manufacturers.
Below I’m sharing the step-by-step I’m using to try to fix it, along with examples I tried — so you can also help me if you want! When we find the solution, I’ll edit the post with the discovery and everything will be resolved.
sudo apt install macchanger;
sudo macchanger --list > maclist.txt;
This will generate an updated list of (almost) all real manufacturer OUIs used. To keep it updated, just periodically recreate maclist.txt using macchanger!
Using Ctrl + F in maclist.txt, you can search for the manufacturers you want to put into nmcli!
I’m trying to use these OUIs:
# example OUIs from Intel, Huawei, and Apple
00:02:b3 - Intel Corporation
0c:37:dc - Huawei Technologies Co., Ltd
b8:ff:61 - Apple
Use them in the configuration file according to the documentation so it looks like this: OUI+:00:00:00
00:02:b3:00:00:00 0c:37:dc:00:00:00 b8:ff:61:00:00:00
I tried this way:
generate-mac-address-mask=FF:FF:FF:00:00:00 68:F7:28:00:00:00 B8:FF:61:00:00:00 0C:37:DC:00:00:00
This was one of the attempts I made to try to make it work (just example):
sudo cat > /etc/NetworkManager/conf.d/00-macrandomize.conf << 'EOF'
[device]
wifi.scan-rand-mac-address=yes
wifi.scan-generate-mac-address-mask=FF:FF:FF:00:00:00 68:F7:28:00:00:00 B8:FF:61:00:00:00 0C:37:DC:00:00:00
[connection]
ethernet.cloned-mac-address=stable
wifi.cloned-mac-address=stable
generate-mac-address-mask=FF:FF:FF:00:00:00 68:F7:28:00:00:00 B8:FF:61:00:00:00 0C:37:DC:00:00:00
connection.stable-id=${CONNECTION}/${BOOT}
ipv6.ip6-privacy=2
ipv4.dhcp-send-hostname=false
ipv6.dhcp-send-hostname=false
[main]
hostname-mode=none
EOF
sudo systemctl restart NetworkManager
This is only one attempt — I tried several different forms. All do not work until!
There are also nmcli commands from the terminal following this pattern that might work. I believe the correct path is indeed this!
Another point is converting the maclist.txt list into the format for generate-mac-address-mask=FF:FF:FF:00:00:00 + list of all MACs to put into nmcli configuration files.
This works:
awk -F'- ' '/^[0-9]+[[:space:]]- /{mac=$2;gsub(/[[:space:]]/,"",mac);oui=substr(mac,1,8);val=oui":00:00:00";if(!printed){print "generate-mac-address-mask=FF:FF:FF:00:00:00 "val;printed=1}else printf " "val}END{if(printed)print ""}' maclist.txt > macnmcli.txt
In macnmcli.txt, the result is already in the format shown in the documentation. Once the problem is resolved, you just register it in the nmcli .conf file and then nmcli will do MAC spoofing using the same manufacturer approach as macchanger -a or macchanger -A!
Another point, after resolving this, is creating a custom list of MACs you want (or from certain categories):
maclist.txt, extract only the list of the manufacturers you want!my-maclist.txtawk -F'- ' '/^[0-9]+[[:space:]]- /{mac=$2;gsub(/[[:space:]]/,"",mac);oui=substr(mac,1,8);val=oui":00:00:00";if(!printed){print "generate-mac-address-mask=FF:FF:FF:00:00:00 "val;printed=1}else printf " "val}END{if(printed)print ""}' maclist.txt > my-maclist.txt
Then add this to the configuration file:
/etc/NetworkManager/conf.d/00-macrandomize.conf
In the part:
generate-mac-address-mask=
It would be possible to create lists by categories, like:
And create configuration scripts for each one, so the user can decide whether they want to “camouflage” only with router MACs or with video game MACs, and so on…
I believe this is the right direction. I’m asking everyone for help — whoever finds the solution, please post it here. I’ll test it and update the post, and this will be great for everyone who can use Qubes with this setup!
See this parte post: /42872/25
link:
In [connection], try wifi.generate-mac-address-mask= (and also ethernet.generate-mac-address-mask= if applicable).
Although I suspect that scanning with partially randomized addresses restricted to a handful of valid OUIs is, ironically, going to look rather weird if the (multiple) scans and the connection use different addresses but are correlateable. You might be better off not micromanaging OUIs at all! It’s 2026, fully random (except for 2 bits) MAC addresses are… normal.
Not really, fme less then 5 years ago that I was using it I was getting less capchas and “unexpected” internet slowdowns then the times I was not
MAC addresses are a link layer property. (Randomized) MAC addresses are not visible to the websites you visit, so they can’t be the reason you were seeing CAPTCHAs. And if you’re connecting your endpoint devices to the internet via your own router, even your ISP won’t see those MAC addresses.
(There is a long outdated method of generating stable IPv6 addresses by embedding the MAC address, and theoretically the fake OUI could have leaked this way. But probably not)
Look at this post about mac spoofing using sys-net, where it uses macchanger with the -r (random) option and also -A with OUI:
Why didn’t the moderator object to sudo macchanger -r (random), but in this post that uses random with OpenSSL they’re so bothered?
mac=$(openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//')
It will generate a random MAC that will hide the MAC and achieve the goal of avoid leaking your real MAC! It’s not ideal, but it’s a setup!
Isn’t it the same as:
macchanger -r <your-mac>
Aren’t they the same thing?
Why, in the other macchanger post on sys-net, they didn’t get on the author’s case for using macchanger -r to hide the MAC, but in this current post using random mac can’t?
Who invented macchanger, then, shouldn’t they have included the -r (random) option in it? Does this such famous software now have a “mortal” error?
If using a random MAC on sys-net is a problem, why did they allow that post?
Mod edit: comments on technical correctness moderation moved to its own thread:
And why did the moderators allow this current post with the OpenSSL version?
Some moderators on this forum should go away. The good moderators should evaluate this.
If a post is bad and wrong, why do they approve it?
And why a post that teaches how to do the same thing isn’t said anything (case of macchanger -r), but in another one using OpenSSL to generate random MAC they get criticized for it, and it’s considered a maximum security flaw not to use a MAC with OUI?
Is this harassing the guy for no reason at all?
Just delete both posts if it’s wrong!
I agree that for greater camouflage, it’s better to always use the manufacturer MAC with OUI and never use random MAC! We shouldn’t even use random MACs; virtual machines should all have MACs with OUI, but they don’t! Whonix (desktop version, not qubes) generates random MACs and not manufacturer ones, but I think it should have OUI (independent if is in NAT internal network). However, it protects the real MAC and that’s already a defense, even if it’s not ideal!
Using random MAC also projects the leak!
The big problem is: with a post using a random MAC on sys-net, nobody says anything, but here everyone condemns the author for not using OUI?
The good moderators of this forum should organize and prevent these inconsistencies! Nobody will want to post and help on this forum anymore!
While that is true and they are different layers of the OSI model, like I stated in an earlier comment I HAVE noticed a significant decrease in captchas whenever I use a “valid” Mac address, I am not questioning the validity of your facts here but I act under the assumption that captcha providers HAVE the money AND the incentive to figure out how to accuire your Mac address, nevertheless when I tested this out last time it was on an arch Linux machine so I’m not sure if they can grab the Mac address of the machine or VM your browser is running on or otherwise, I assume the former, so I’ll have to agree that getting a “correct” Mac for sys-net might be not be prudent to you but it is to
This seems like the kind of thing where it would be easy to perceive patterns that don’t exist, unless it’s done in a well-designed blinded experiment. Maybe something like: For x number of days, a mechanism in sys-net randomly either randomizes doesn’t randomize the MAC address on that day, and files a record on which day it did / didn’t. A journal is kept for how many CAPTCHAs were noticed on each day. Then groups A and B of days are compared. Needs some power analysis to figure out the lowest possible value for x (number of days) that still yields a statistically meaningful result.
While yes, a valid experiment, you also see how convoluted it is right? I am going to give you a guess statistic of 20-30%, if you happen to do it it should fall somewhere in that area, my test on this happened absentmindedly in late 2022 and early 2023 when I was playing around with other OSs, but thinking about it I am not sure on how feasible is for them to track sys-net unless they work with ISPs, but then again I was living in the UK at the time so most likely
If its captchas working with ISPs its sys-net since isps have control of your router most of the time (unless you use openwrt as a waypoint)
If its browser based it should be the VM that is running the browser that should be checked and change it’s Mac (although I am not sure how match that would affect qubes firewall)
If you do a formal experiment on it PLEASE pm me with the results, it’s not gonna really change how I perceive macs but I would like to know the current security
Edit: my guess statistic is roughly from memory so take that with a grain of salt
Could this be related to not being able to connect to the net at all after initial installation? I’ve tried messing around with all the network connections I can’t get anywhere.
No (given the context of your other post)
Damn. I’m going to have to come back and go through these steps for anonymity once I get my connection back
Told ya, we should not had included Dho-Nha curve cryptography into Qubes kernel. See, madness spreads uncontrollably. Now CAPTCHA providers can see MAC addresses. What’s next?