[Solved] MAC address spoofing

V1del · 2026-09-17 15:54:02

Well I'd say the reasons for wanting to do that are somewhat out of scope.

However @alfredino is your original question answered? Can you mark as [SOLVED] in that case by editing the title in your first post? The only thing I can somewhat garner from your responses that you want it to show up as a file in system connections for some reason, in which case marking the connection as a system connection (in many UIs commonly referred to "make available for all users" or similar) will lead to networkmanager creating a file there, but the stipulation of this is that e.g. connection credentials would be stored in plain text (albeit limited to be read by the root account), while many other frontends usually solve this via encrypted keyrings.

Beemo · 2026-09-17 16:17:33

I received many replies, but not really useful.

Why? If you did some researched yourself, or even just kept asking what's unclear (instead of shutting down / dissing on the answers), I doubt you'd come to this conclusion.

I changed one of urls in #15 to this: https://netplan.readthedocs.io/en/stabl … w-it-works
How it usually works: NM is enabled, Desktop Environment interact with NM, NM persists the config.
How it works in Ubuntu / with netplan: netplan is enabled, netplan runs NM in a transient way, DE still interacts with NM, netplan takes config from NM and stores it in its own place.
That's why your network-manager-gnome package which uses nm-applet works, and why netplan config is the place to change it (through files, otherwise nmcli).

If you find the contrary, I'd love to know :)

alfredino · Yesterday 09:07:36

cryptearth wrote:

counter-question: why have you come to the conclusion to use randomized mac?
a mac is already something used only at very low levels to enable communication in the first place because a network is usually more tgan one single point-to-point connection hence there need to be something to uniquily identify sender and recipient within a network
and with just 48 bits and how mac addresses are usually organized even with randomization that space is limited
in fact: randomization can cause issues: it can cause unknown vendor identifiers or collisions - with using the physical nic one can be sure it's both valid and won't cause collisions
if you think about privacy: nah, forget it - your device and you as its user get fingerprinted all over they layers - in fact: using randomization can make you an even more interesting target: imagine a starbucks with a bad actor - he sees the same people every day - and the same devices - but everytime you show up it looks like you have a new phone - yet it's clearly the same you used for tge past year - why?
THAT's the way an attacker thinks: WHY? do you use randomization? and why is all your traffic only with one single IP (vpn)? what you hiding?
that's when you get on thier list and how you become a target - because you may hide something worth the effort of attack

Thank you for the explanation. Right, the reason is related to privacy. If you want to protect your digital footprint, you need to minimise the traces you leave behind. The MAC address, IP address and device ID are all tracking data that I try to minimise (by randomising them and using a trusted VPN). Generally speaking, there are two main approaches to protecting yourself from fingerprinting: data randomisation (you become a different user each time) and data homogenisation (you blend into the crowd). The first works better than the second because it’s very easy to become unique, just a few anomalies are enough.
I’ve got nothing to hide, but I’ve got nothing to show either. Snowden teaches us.
Could it cause problems? Perhaps, but I’ve been using it for years via the graphical interface without any real issues. I then switched to the command line because I wrote a script that configures various things and came across the arch linux documentation.

P.S. regardless of the operating system, is there no way to solve my problem without using nmcli?

alfredino · Yesterday 09:09:36

V1del wrote:

Well I'd say the reasons for wanting to do that are somewhat out of scope.

I agree.

V1del wrote:

However @alfredino is your original question answered? Can you mark as [SOLVED] in that case by editing the title in your first post? The only thing I can somewhat garner from your responses that you want it to show up as a file in system connections for some reason, in which case marking the connection as a system connection (in many UIs commonly referred to "make available for all users" or similar) will lead to networkmanager creating a file there, but the stipulation of this is that e.g. connection credentials would be stored in plain text (albeit limited to be read by the root account), while many other frontends usually solve this via encrypted keyrings.

Sorry, no. I still do not know how to solve the problem via configuration file, without nmcli.

alfredino · Yesterday 09:14:21

Beemo wrote:

I received many replies, but not really useful.
Why? If you did some researched yourself, or even just kept asking what's unclear (instead of shutting down / dissing on the answers), I doubt you'd come to this conclusion.

Sorry, it was not a critique, just my feeling.

Beemo wrote:

I changed one of urls in #15 to this: https://netplan.readthedocs.io/en/stabl … w-it-works
How it usually works: NM is enabled, Desktop Environment interact with NM, NM persists the config.
How it works in Ubuntu / with netplan: netplan is enabled, netplan runs NM in a transient way, DE still interacts with NM, netplan takes config from NM and stores it in its own place.
That's why your network-manager-gnome package which uses nm-applet works, and why netplan config is the place to change it (through files, otherwise nmcli).
If you find the contrary, I'd love to know

Ok, so you are confirming that I need to use nmcli.

cryptearth · Yesterday 14:14:46

alfredino wrote:

...

to not further spam, let's keep it short: we have quite different point of view about this topic

seth · Yesterday 14:22:43

1. don't use netplan
2. figure how to configure the MAC spoofing behavior in netplan
3. figure how to make netplan operate on static NM profiles

Your mistake is that you are NOT using networkmanager to manage your connections but netplan.
Netplan piggybacking on NM is a detail you must ignore - in doubt your configuration efforts will collide w/ netplan's

As for the privacy aspect you two might be talking past each other wrt privacy against who or what: facebook (mac spoofing will do jack shit) or the government/legal authorities via the AP provider.

Ultimately this is *all* off topic because https://bbs.archlinux.org/misc.php?action=rules

alfredino · Yesterday 14:23:25

cryptearth wrote:

alfredino wrote:
...
to not further spam, let's keep it short: we have quite different point of view about this topic

Sorry, but you started spamming. However, everyone has its own opinion, but facts are equal for all.

cryptearth · Yesterday 14:48:59

well - full aware of the risk this reply may bring along:

as seth pointed out short but elegant: MAC randomizing won't grant you any benefit in how you feel about privacy, as a nic's mac is only relevant between to ends of one physical link - in case of wlan: between your devices radio and the AP - so with randomized mac all you randmize against is the ap you connect to - and unless you randomize quite a lot more meta data than just the "physical" address there's enough left to still fingerprint a specific device - and, as exlained by yourself: the random mac is then exactly what makes you stick out of the crowd you try to blend in - which completely inverts the idea in the first place (at least by your specific definition)

seth · Yesterday 15:00:27

https://en.wikipedia.org/wiki/IPv6_addr … on_(SLAAC)
Money quote is

unless you randomize quite a lot more meta data than just the "physical" address there's enough left to still fingerprint

alfredino · Yesterday 15:05:50

cryptearth wrote:

well - full aware of the risk this reply may bring along:
as seth pointed out short but elegant: MAC randomizing won't grant you any benefit in how you feel about privacy, as a nic's mac is only relevant between to ends of one physical link - in case of wlan: between your devices radio and the AP - so with randomized mac all you randmize against is the ap you connect to - and unless you randomize quite a lot more meta data than just the "physical" address there's enough left to still fingerprint a specific device - and, as exlained by yourself: the random mac is then exactly what makes you stick out of the crowd you try to blend in - which completely inverts the idea in the first place (at least by your specific definition)

This is the first time anyone has not advised me to protect unique identifying data in order to safeguard privacy. Is that enough? No, of course. Do we need to protect them? Of course. Are there ways to uncover them? Yes, but it’s not as straightforward as it would be if they weren’t protected: https://arxiv.org/html/2408.01578v1 and https://www.sciencedirect.com/science/a … 8622004273
Of course, the MAC address is only available on the local network, but a programme or application can access it and transmit it externally.
Why do all desktop and mobile operating systems offer this option?

alfredino · Yesterday 15:07:30

seth wrote:

https://en.wikipedia.org/wiki/IPv6_addr … on_(SLAAC)
Money quote is
unless you randomize quite a lot more meta data than just the "physical" address there's enough left to still fingerprint

Of course. The objective is to minimise the amount of data and metadata exposed. I never said that simply hiding the MAC address was enough.

seth · Yesterday 15:25:34

but a programme or application can access it and transmit it externally

If you're running malware, any attempts to spoof your MAC are a completely lost cause.

nb. that some APs (that includes ISP issued ones) will consider mac spoofing attempts (on scan or connection) malicious behavior and completely stop talking to you.
Keep that in mind if you encounter weird connection failures w/ isolated APs

alfredino · Yesterday 15:30:28

seth wrote:

but a programme or application can access it and transmit it externally
If you're running malware, any attempts to spoof your MAC are a completely lost cause.
nb. that some APs (that includes ISP issued ones) will consider mac spoofing attempts (on scan or connection) malicious behavior and completely stop talking to you.
Keep that in mind if you encounter weird connection failures w/ isolated APs

Unfortunately, it’s not just malware, but also "goodware" (at least in theory). I’ve been using it for several years without any problems.

seth · Yesterday 15:36:46

"malware" or "goodware" - whatever is running locally and wants to expose details about your HW/identity is free to do so and mac spoofing on connection is meaningless anyway - you'd have to pull that before entering the userspace (resp. running the goodware) https://wiki.archlinux.org/title/MAC_address_spoofing and since the "goodware" can correlate the MAC w/ the actual HW ID it will sniff you out when you set the MAC to that of a different vendor.

Also putting lipstick on a pig does not make it not a pig.
Anything doing that is malware.

alfredino · Yesterday 15:49:10

seth wrote:

"malware" or "goodware" - whatever is running locally and wants to expose details about your HW/identity is free to do so and mac spoofing on connection is meaningless anyway - you'd have to pull that before entering the userspace (resp. running the goodware) https://wiki.archlinux.org/title/MAC_address_spoofing and since the "goodware" can correlate the MAC w/ the actual HW ID it will sniff you out when you set the MAC to that of a different vendor.
Also putting lipstick on a pig does not make it not a pig.
Anything doing that is malware.

I agree, but I was referring to "goodware" within the network or at the AP/switch level, not within the device itself. For example, graphene OS, considered the best android operating system in terms of security and privacy, requires MAC randomisation: https://grapheneos.org/faq#future-devices
The NSA tracked users via their MAC addresses https://en.wikipedia.org/wiki/MAC_address#Randomization, whilst Netgear collects MAC addresses https://www.downloads.netgear.com/files … .05.26.pdf. Is this "goodware" or malware? To me, it’s malware, but for most people it isn’t.

Beemo · Today 09:56:34

alfredino wrote:

Ok, so you are confirming that I need to use nmcli.

No, you can write the netplan config yourself.
You can reference your other files in /etc/netplan/ to write it, but the safest way is always letting netplan write it. netplan cli has no command to dump the config to disk so nmcli is used to trigger it.

Beemo wrote:

netplan does have a macaddress setting: https://netplan.readthedocs.io/en/lates … vice-types

Beemo wrote:

trigger netplan to create a file in /etc/netplan/
(Or you could always write the netplan config yourself)

Tbh I'm not sure what's going on with netplan on your install. I tried Ubuntu LiveOS on a physical machine, connecting to Wi-Fi will save a config in /etc/netplan/ with plain-text password.
Maybe one of the files under your /etc/netplan/ is the config for the "Orange Wi-Fi" but the UUID changed.
But anyway, the filename would suggest the connection is indeed managed by netplan.

alfredino wrote:

Orange Wi-Fi                     --            /run/NetworkManager/system-connections/netplan-NM-bbec9122-8c23-4b48-847c-4824530a788c-Orange%20Wi>

Beemo wrote:

https://netplan.readthedocs.io/en/stabl … w-it-works

Last edited by Beemo (Today 10:03:29)

alfredino · Today 12:12:42

Beemo wrote:

alfredino wrote:
Ok, so you are confirming that I need to use nmcli.
No, you can write the netplan config yourself.
You can reference your other files in /etc/netplan/ to write it, but the safest way is always letting netplan write it. netplan cli has no command to dump the config to disk so nmcli is used to trigger it.

Ok, but I found easier to use nmcli.

Beemo wrote:

Beemo wrote:
netplan does have a macaddress setting: https://netplan.readthedocs.io/en/lates … vice-types
Beemo wrote:
trigger netplan to create a file in /etc/netplan/
(Or you could always write the netplan config yourself)
Tbh I'm not sure what's going on with netplan on your install. I tried Ubuntu LiveOS on a physical machine, connecting to Wi-Fi will save a config in /etc/netplan/ with plain-text password.
Maybe one of the files under your /etc/netplan/ is the config for the "Orange Wi-Fi" but the UUID changed.
But anyway, the filename would suggest the connection is indeed managed by netplan.
alfredino wrote:
Orange Wi-Fi                     --            /run/NetworkManager/system-connections/netplan-NM-bbec9122-8c23-4b48-847c-4824530a788c-Orange%20Wi>
Beemo wrote:
https://netplan.readthedocs.io/en/stabl … w-it-works

Not sure and this is the reason for which I asked.

Last edited by alfredino (Today 12:14:50)

Beemo · Today 12:55:44

You can check by opening those files (in /etc/netplan/) with root to see if any of them has "name:" that matches (e.g. Orange Wi-Fi).
It'll probably also give you a clue on what's going on. (There are 5 configs but 3 NM connections, and none of the UUID match.)

Arch Linux

#26 2026-09-17 15:54:02

Re: [Solved] MAC address spoofing

#27 2026-09-17 16:17:33

Re: [Solved] MAC address spoofing

#28 Yesterday 09:07:36

Re: [Solved] MAC address spoofing

#29 Yesterday 09:09:36

Re: [Solved] MAC address spoofing

#30 Yesterday 09:14:21

Re: [Solved] MAC address spoofing

#31 Yesterday 14:14:46

Re: [Solved] MAC address spoofing

#32 Yesterday 14:22:43

Re: [Solved] MAC address spoofing

#33 Yesterday 14:23:25

Re: [Solved] MAC address spoofing

#34 Yesterday 14:48:59

Re: [Solved] MAC address spoofing

#35 Yesterday 15:00:27

Re: [Solved] MAC address spoofing

#36 Yesterday 15:05:50

Re: [Solved] MAC address spoofing

#37 Yesterday 15:07:30

Re: [Solved] MAC address spoofing

#38 Yesterday 15:25:34

Re: [Solved] MAC address spoofing

#39 Yesterday 15:30:28

Re: [Solved] MAC address spoofing

#40 Yesterday 15:36:46

Re: [Solved] MAC address spoofing

#41 Yesterday 15:49:10

Re: [Solved] MAC address spoofing

#42 Today 09:56:34

Re: [Solved] MAC address spoofing

#43 Today 12:12:42

Re: [Solved] MAC address spoofing

#44 Today 12:55:44

Re: [Solved] MAC address spoofing

Board footer