MAC address spoofing not working

I've updated to 10.13.6 (17G65) and checked on my mac mini late 2012 and MBP 2011.

Had no issues changint it on both on ethernet(en0) and wifi(en1)

bash-3.2# ifconfig en1 ether
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  ether 28:cf:e9:00:7a:b7 
bash-3.2# ifconfig en1 ether 28:cf:e9:00:7a:b8
bash-3.2# ifconfig en1 ether
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  ether 28:cf:e9:00:7a:b8

Router also sees this change

Yes, I also test with a 2014 MacBook Pro and it worked fine.

I'm only seeing the problem on a 2018 MacBook Pro

intresting if it's an OS/kext or hardware issue.

You could find out by booting from USB other OS, which has MBP2018 LAN card driver.

I would be really suprised to see if hardware chip would not allow to send packet with MAC address other than factory assigned 🙂

In either way You should fill bug report related to this machine.

Having the same issue with a 13-inch MacBook Pro 2018.

Any resolution available?

same here... it seems like it's a specific problem on MacBook Pro 2018 series...

any resolutions, yet?

This is kinda outside my area of expertise — being more of a user-level thing than an API-level thing — but I’m curious if anyone has filed a bug about this yet? If so, what’s the bug number?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hello. It seems like there is no further activity on this thread. I am experiencing the issue on a 2018 MacBook Pro, running Mojave. I tried chatting with Applecare about this, and was advised this was an "unsupported feature". Anything you could do to help from your end would be appreciated.

Anything you could do to help from your end would be appreciated.

What was the number of the bug you filed?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Same issue on a brand new iMac pro running high sierra

Since @alberto33016 didn't reply, I filed a new bug with Apple: #46479902.

Any help would be really appreciated.

Edit: it turns out that my bug is a duplicate of bug #45252200

I filed a new bug with Apple: #46479902.

Thanks for that.

it turns out that my bug is a duplicate of bug #45252200

Indeed. I can’t say anything about the state of that bug right now )-:

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I filed the following bug: 45252200

Hasnt been marked as duplicate, but I filed it under Security since for me it breaks my confidentiality and I got an email saying that they re-categorized it.

Alright everyone.

My ticket has been closed and I pinged a bunch of friends I have that work at Apple HQ.

Final result. This is not a bug. Apple is removing this feature for security reasons. This makes no sense since doing this does not put the individual doing it at a security risk. But I don't. Im so done with the platform. You can't just remove ifconfig functionality. Thats not how any of this works.

I filed another bug since I really don't think they are getting that they are breaking standards.

Here is the bug <47137510>

Area:
Terminal

Summary:
Per the manual page, a user with sudo should be able to change the link-level MAC address using the ifconfig command

lladdr addr              Set the link-level address on an interface.  This can be used to              e.g. set a new MAC address on an ethernet interface, though the              mechanism used is not ethernet-specific.  The address addr is              specified as a series of colon-separated hex digits.  If the              interface is already up when this option is used, it will be              briefly brought down and then brought back up again in order to              ensure that the receive filter in the underlying ethernet hard-              ware is properly reprogrammed.

However this does not work on all hardware models late 2018+
Steps to Reproduce:
run:

ifconfig INTERFACE lladdr aa:bb:cc:dd:ee:ff

ifconfig INTERFACE ether aa:bb:cc:dd:ee:ff

Expected Results:

for the Link-Level address to be changed per the manual page and following standards of Unix and BSD for the ifconfig command

Actual Results:
Fails silently

Version/Build:
10.14.2 (18C54)

Configuration:
All Macs shipped after August of 2018

Any updates on this bug?

Did Apple respond to this bug yet?

From Apple on May 29, 2019 at 3:32 PM:

Having this issue with a M2 MacBook Pro 14" 2023, running macOS 13.2 and 13.3 Ventura.

Or.. "had"..

It seems to be driver related. Check out this post: https://khronokernel.github.io/macos/2021/11/22/PCIE-ETHERNET.html

Apple prefers PCI adapters for driver support, so the full functionality should be supported there. The ifconfig ether command actually works using the Apple TB display as well as the TB3-TB2 + TB1-GbE adapters - at least in my testing.

When using a USB ethernet adapter, either a more generic ECM driver or a more native NCM driver class is used (check in System Information and compare with the linked article).

1. When I attach a USB ethernet adapter that uses an ECM driver, then the ifconfig ether command fails.
2. When the NCM driver is used, the ifconfig ether command is accepted but does not actually change the MAC address.
3. When using a PCI ethernet adapter with supported driver, then the ifconfig ether command works as expected.

To note: a TB3 or TB4 dock will not necessarily use a PCI ethernet chipset, and may just use an USB one.

As this seems to be related to drivers, it will probably disappear, show up again and disappear once more with future OS releases. Especially with major transitions like arm vs x86. The safest way to go is to have some Apple HW lying around to test "native" drivers (TB1 to GbE adapter, even if a bit outdated), as these will probably be ported first.

Nearly 20,000 views on this question, and probably a fair number of votes distributed across the many accidental and forced duplicates..

Recent Reddit threads suggest it's a driver/chipset issue, and Apple is choosing to not document or not communicate anything (that's never helped, but there's always a first time).

This is using the 10G hardware-Ethernet port found in the Mac Mini M2. I specifically bought this for networking testing, but I guess I still need my Raspberry Pi :-(

@somewhereInTime oh wow, I would've expected the built-in hardware of the Mac Mini to actually work with the shipped OS.

Thanks for sharing!

I specifically bought a OWC TB3 to 10GbE adapter, as it uses the Aquantia AQC107 chipset.

According to the previously shared link to the guide on Github:

With the above 5 drivers, currently Apple only uses 2 of them in their products:

Aquantia is used on all Macs with 10Gbe
ie. 2017 iMac Pro, 2019 Mac Pro, 2018 Mac mini
Broadcom is used on all 2011+ Macs with 1Gbe
ie. 2011-2020 iMacs, 2010-2020 Mac minis, 2013 Mac Pro

However - no luck. Offloading seems to work, the used driver is Driver: com.apple.driver.AppleEthernetAquantiaAqtion. But using ifconfig ether still fails silently :(

"Upgrading" to the latest macOS Sonoma Developer beta seems to have solved my other issue regarding WiFi 6E (6GHz), it now detects my AP correctly and actually connects. But regarding wired network adapters I didn't see any changes.

As this is my daily driver I will "downgrade" to macOS Ventura again, was having some trouble with specific programs not running anymore.

Apple needs to acknowledge this issue.

1. If they CHOOSE to remove ifconfig support, then they should stand behind it and not mislead customers by claiming it's "unsupported" 3rd-party adapters.
2. more likely it's "only" a driver issue though, as the Apple TB1 GbE adapter still supports ifconfig ether (I do need to admit that I did not test that with macOS Sonoma though). It uses a different driver, and likely the Aquantia driver is not feature-complete on Apple Silicon machines.

Maybe it's also both - officially they did not want to break ifconfig when porting drivers, but some head of department may have made some decision that "MAC Spoofing is nefarious" and only used by internet buccaneers.