In Red Hat Enterprise Linux (RHEL) 8, if someone does ifconfig eth0 hw ether abcd12341234,

all I know is ifconfig and ip -a,

so then is there a way to reliably get the real MAC address of that eth0 interface and if so how? ... other than for example rebooting to a Linux live CD coming from a reliable source to be sure the MAC address of the interface hasn't been changed.

3 Answers 3


This answer is about Linux.

ifconfig is obsolete and doesn't have access to a kernel API able to provide it this information.

This information has been able to be retrieved for a long time with ethtool --show-permaddr. Example (redacted):

# ethtool --show-permaddr eth0
Permanent address: 10:1f:74:32:10:fe

Some board/firmware/driver combination might not have a permanent address and the result could be like this:

# ethtool --show-permaddr eth0
Permanent address: not set

A recent enough ip link/kernel will provide (possibly through an other API) the permanent address whenever the current address differs from an existing permanent address if it is set. For example (redacted):

# ip link set dev eth0 address 12:34:56:78:9a:bc

$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 12:34:56:78:9a:bc brd ff:ff:ff:ff:ff:ff permaddr 10:1f:74:32:10:fe

Here permaddr 10:1f:74:32:10:fe represents the original MAC address. It's provided only when the current MAC address differs from the permanent MAC address. Such change could also have happened temporarily for example when an interface is set as a bond slave and (depending on its mode) inherits the bond's MAC address.

To retrieve it programmatically, even when it was not changed, better use the JSON output and jq, for example like this:

ip -json link show dev eth0 | jq -r '.[] | .permaddr // .address'

which retrieves the permanent MAC address or if not provided the MAC address (which means it's the unchanged permanent MAC address... unless there is none, in which case it's the current).

If this matters, one must first be sure there is a permanent address, because contrary to ethtool it doesn't appear to allow to know there is no known permanent address set for the board/firmware/driver combination.

  • 1
    Note that I remember some older cards that read the "permanent" address at initialization from EEPROM, but had no way of reading the EEPROM at run time, nor did they have some "shadow" register for the previous MAC address; thus, once you set a MAC address, that was the only one the card or anything else knew about. Commented Feb 14 at 21:26
  • but I didn't know about --show-permaddr, so, a clear +1 from me. Very neat ip -json … | jq solution as well! Commented Feb 14 at 21:27
  • 3
    @MarcusMüller there are even cards without such ROM but with a patched driver allowing to fake a permanent address (for Linux' API consumption) at kernel/module load time. My old Odroid XU3L was working like this until the driver's patch was dropped so now it says "not set" instead.
    – A.B
    Commented Feb 14 at 21:33
  • thanks, using ethtool --show-permaddr eno1np0 for example seems to do exactly what I was asking.
    – ron
    Commented Feb 15 at 13:39
  • ifconfig provides backward and lateral compatibility and maybe shouldn't be discarded. Don't disparage people for not defaulting to your pet dialect. Commented Feb 17 at 22:31

This answer is about NICs in general.

Nothing about that MAC address is "unreal". In general, nothing guarantees that any network card does have any ROM that contains a unique MAC address. In fact, you'll find such quite commonly especially in SoCs, that the whole device is software-defined and that there's only the MAC address that software sets.

So, no. In general there's no such thing as a "real" MAC address, and if your system decided to change that of an interface, even if it was real before, for all your computer can know, that's the "real" MAC address.

PS: Many a large software company has in the 1990s tried to bind their software licenses (often for multi-k€ software!) to NIC addresses, to hilarious results. Xilinx did that well into the 2010s, and it was a delight for people who needed the floating license, but only had single-seat license.

Identifying a computer via its network interface is a dead concept, especially if you're trying to defend against someone who has root on the machine: what would stop them from just modifying a kernel driver to tell you whatever you want to hear?

If you need to achieve that, TPMs exist. These are actually "cryptographically secure", as in, you can't program your TPM to behave like someone else's TPM, because for that you would need to access memory inside that other person's TPM that's unreadable externally. And you don't ask the TPM for its ID (again, that would be spoofable by a kernel driver), but you ask it to cryptographically prove it has the right internal secret by decrypting something.

  • 2
    We still have software that uses MAC-based licensing (AutoCAD uses Flexnet); it's really handy because I was able to migrate the lmgrd service from a Windows VM into a Linux container and just create a dummy eth0 with the MAC address of choice. Fancy things like TPM-based licensing might seem attractive to the vendor but they're such a pain in the ass for sysadmins. Commented Feb 15 at 8:07
  • 1
    @u1686_grawity exactly my point. If you're a vendor, and you don't really want to make sure it's impossible to move your software, stop trying to do stupid things like trusting network drivers about MAC addresses. If you really need that (and I'm thinking more in terms of "who can access this very confidential data" than "who has paid to use my software"), then go for TPM. Commented Feb 15 at 11:29
  • 3
    @ron yeah, well wikipedia being wrong is honestly not a new thing! I'm not sure how you bring SSH into this? Anyways, multiple misconceptions: IEEE assigns no MAC addresses, it sells prefixes (OUIs) for MAC addresses. When you build your own network card, nothing (literally, nothing) forces you to have bought any prefix, or to use a new MAC address or anything. As described in my answer, this is the normal case for SoCs, or anything developed yourself. So, I'm afraid my paragraph about how identification is quite right. Commented Feb 15 at 14:59
  • 3
    For example, you can go on the market for network chips, and buy one, build a network card yourself. Many of these chips have an interface for an external EEPROM, but in absence of that, will just accept any configuration of a MAC address before they become functional. Or, you buy a 20€ FPGA eval board and put a soft-MAC in there, and make it do whatever you want, including switching MACs for every single packet. Really, I'm not sure why you assume I'm wrong; I've built devices with network interfaces :) Commented Feb 15 at 15:02
  • 3
    @ron: When you buy a PC motherboard, or a mainstream NIC for one, it will normally come programmed with a unique MAC from the range "owned" by the vendor. It's reasonable to expect this to be globally unique, and meaningful to call it a "real" MAC address. The embedded world is apparently very different. But the other key point is that unless you're writing the drivers yourself for a freestanding program on bare metal (no OS or virtualization), you don't have a way to get the "real" hardware MAC address even if there is one, only different levels of difficulty to spoof. Commented Feb 15 at 17:08

This answer is specific to FreeBSD.

The MAC addresses of the NICs that were identified during the most recent boot are recorded in /var/run/dmesg.boot:

$ grep 'Ethernet' /var/run/dmesg.boot 
em0: Ethernet address: b8:ca:3a:9f:a8:1e
igb0: Ethernet address: 90:e2:ba:78:ae:40
igb1: Ethernet address: 90:e2:ba:78:ae:41
igb2: Ethernet address: 90:e2:ba:78:ae:44
igb3: Ethernet address: 90:e2:ba:78:ae:45
  • I cannot find a dmesg.boot file, in /var/run nor in /var/log in RHEL-8.9, and seemingly not anywhere under /var. you mentioned specific to FreeBSD, I feel like I should be able to find similar information somewhere in RHEL ?
    – ron
    Commented Feb 15 at 13:40
  • @ron: RHEL is a Linux distro, not FreeBSD. This answer is for other future readers searching on the title question, not you, as indicated by the first line that says it's specific to FreeBSD. Commented Feb 15 at 17:09
  • I agree @ron, it seems like RH/Linux ought to make this easier.
    – Jim L.
    Commented Feb 16 at 18:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .