Randomized MAC addresses in scan results on MacOS

[ranok]

Describe the bug
When using the nmap.org installed version of nmap (v7.98), the MAC addresses of the scanned hosts are randomized. Using the same version installed via homebrew outputs the correct MAC address(es).

To Reproduce
Install the MacOS (I'm running Tahoe 26.2 on an M1) DMG from nmap.org
As root, run the command nmap -nO <IP/host>

Expected behavior
The MAC address reported for the scanned host should match reality/the OS' ARP table (arp <IP>).

This is a screenshot of the nmap.org showing a different MAC (and vendor) for the target from the system's arp output. When I use the homebrew-based version, it shows the correct (same as arp) MAC.

Version info (please complete the following information):

• OS: ARM MacOS 26.2 (Tahoe)
• Output of nmap --version: 7.98

Additional context
This is a bog-standard DHCP IPv4 wired network with a 2.5GB ethernet unmanaged switch between the devices, and a UniFi Cloud Gateway Router.

[joostvdl]

Same issue here.

[dmiller-nmap]

Apparently also affects FreeBSD.

[dmiller-nmap]

This is a result of libdnet's configure script not correctly detecting the BSD-like OS and failing to compile support for sending raw packets. The code for the Nmap 7.98 release is correct for macOS, but apparently we did not reconfigure prior to building the release binary, so the bug persisted. The fix is in libdnet-stripped/m4/acinclude.m4 in 5887484:

--- a/libdnet-stripped/m4/acinclude.m4
+++ b/libdnet-stripped/m4/acinclude.m4
@@ -94,7 +94,7 @@ dnl
 AC_DEFUN([AC_DNET_BSD_BPF],
     [AC_MSG_CHECKING(for Berkeley Packet Filter)
     AC_CACHE_VAL(ac_cv_dnet_bsd_bpf,
-    if test -c /dev/bpf ; then
+    if test -c /dev/bpf -o -c /dev/bpf0 ; then
         ac_cv_dnet_bsd_bpf=yes
     else
         ac_cv_dnet_bsd_bpf=no

For FreeBSD, I would have to see the libdnet-stripped/config.log file to see what may have gone wrong.

[ds-cbo]

For FreeBSD, I would have to see the libdnet-stripped/config.log file to see what may have gone wrong.

Here you go:
libdnet-stripped-config.log

Searching for anything related to bpf yields:

configure:14501: checking for net/bpf.h
configure:14501: cc -c -O2 -pipe  -I/usr/include -D_FORTIFY_SOURCE=2 -fPIE -fPIC -fstack-protector-strong -ftrivial-auto-var-init=zero -fzero-call-used-regs=used -fno-strict-aliasing   conftest.c >&5
configure:14501: $? = 0
configure:14501: result: yes

several cases of #define HAVE_NET_BPF_H 1

and one of ac_cv_header_net_bpf_h=yes

No mentions of _bsd_ apart from ac_cv_header_bsd_string_h=no

---

Big footnote here that the issue I made in #3314 is using the version compiled and distributed by FreeBSD itself - while this log file is from my local build. They may not be identical. However, the behaviour seems to be the same at quick glance.

The general nmap build log from FreeBSD is here: https://pkg-status.freebsd.org/beefy22/data/latest-per-pkg/nmap/7.98/143amd64-default.log but that might not include the libdnet config log

---

And fwiw:

$ stat /dev/bpf /dev/bpf0
1895890688 39 crw------- 1 root wheel 39 0 "Mar 10 10:39:50 2026" "Mar 10 10:39:40 2026" "Mar 10 10:39:40 2026" "Jan  1 00:59:59 1970" 4096 0 0 /dev/bpf
1895890688 40 lrwxr-xr-x 1 root wheel 18446744073709551615 3 "Feb 26 22:11:24 2026" "Feb 26 22:11:24 2026" "Feb 26 22:11:24 2026" "Jan  1 00:59:59 1970" 4096 0 0 /dev/bpf0

$ test -c /dev/bpf; echo $?
0

$ test -c /dev/bpf0; echo $?
0

$ ls -l /dev/bpf0
lrwxr-xr-x  1 root wheel 3 Feb 26 22:11 /dev/bpf0 -> bpf

Though again, that's on our router, not on the FreeBSD build server or my own build environment of the logs above

[ds-cbo]

Hm, for the FreeBSD case there might be something going on with the patch files it applies:

https://cgit.freebsd.org/ports/commit/?id=be8868737f7ba298396a5bbb94f4fa2b3a5e6efb

Especially this part stands out:

-+# PR ports/154353 : support building in FreeBSD jail
-+    ac_cv_dnet_bsd_bpf=yes

I'll ping the maintainers there as well: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293713

[dmiller-nmap]

@ds-cbo The log has a very odd anomaly where the test in question did not record either yes or no:

configure:15120: checking for strsep
configure:15120: result: yes
configure:15137: checking for Berkeley Packet Filter
configure:15144: result: 
configure:15151: checking for Linux proc filesystem
configure:15165: result: no

Can you confirm whether a clean checkout of the latest source has the same issue? I just pushed a change to force a build failure if the configure script doesn't find any valid ethernet or route backend, so at least we won't get silent runtime errors like this in the future.

[ds-cbo]

@dmiller-nmap

Sure, now it does indeed fail on configure (exit code 1):

$ git clone https://github.com/nmap/nmap.git && cd nmap
$ git log -1
commit 8ce9f0457098fc8f8c136e01f79c200a45ae79ec (HEAD -> master, origin/master, origin/HEAD)
Author: dmiller <dmiller@e0a8ed71-7df4-0310-8962-fdc924857419>
Date:   Tue Mar 10 20:23:17 2026 +0000

    Use cross-platform-safe quoting for perl commands

$ ./configure
...
=== configuring in libdnet-stripped (/home/nmap/libdnet-stripped)
...
checking for net/bpf.h... yes
...
checking for Berkeley Packet Filter... no
checking for Linux proc filesystem... no
checking for Linux PF_PACKET sockets... no
checking for SNMP MIB2 STREAMS... no
checking for route(7) STREAMS... no
checking for arp(7) ioctls... no
checking for raw IP sockets ip_{len,off} host byte ordering... yes
checking for cooked raw IP sockets... no
checking for getkerninfo... no
configure: error: "Ethernet support not found for this system."
configure: error: ./configure failed for libdnet-stripped

(not quite the same build env as my previous log tho, let's see if I can get upstream into the same build server without a tag)

---

Update: on the same build server as the log before:

...
checking for strsep... (cached) yes
checking for Berkeley Packet Filter...
test: =: unexpected operator
checking for Linux proc filesystem... no
checking for Linux PF_PACKET sockets... no
checking for SNMP MIB2 STREAMS... no
checking for route(7) STREAMS... no
checking for arp(7) ioctls... no
checking for raw IP sockets ip_{len,off} host byte ordering... yes
checking for cooked raw IP sockets... no
checking for getkerninfo... no
configure: error: "Ethernet support not found for this system."
configure: error: ./configure failed for libdnet-stripped
===>  Script "configure" failed unexpectedly.
Please report the problem to cy@FreeBSD.org [maintainer] and attach the
"/var/ports/usr/ports/security/nmap/work/nmap-8ce9f04/config.log" including
the output of the failure of your make command. Also, it might be a good idea
to provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

that test: =: unexpected operator seems to arrive from the if test $ac_cv_dnet_bsd_bpf = yes ; then a few lines later, which is triggered because the freebsd patch file removed the else test -c ... part, not setting the variable at all

Fixing that patch to restore the explicit ac_cv_dnet_bsd_bpf=yes from before:

checking for strlcpy... (cached) yes
checking for strsep... (cached) yes
checking for Berkeley Packet Filter... yes
checking for Linux proc filesystem... no
checking for Linux PF_PACKET sockets... no
checking for SNMP MIB2 STREAMS... no
checking for route(7) STREAMS... no
checking for arp(7) ioctls... no
checking for raw IP sockets ip_{len,off} host byte ordering... yes
checking for cooked raw IP sockets... no
checking for getkerninfo... no
checking that generated files are newer than configure... done
configure: creating ./config.status

but does not manage to build a binary because of issues with linking to pcre2, most likely unrelated.

---

Even with --with-libpcre=included I still get linking errors:

ld: error: version script assignment of 'PCRE2_10.47' to symbol 'pcre2_jit_compile_8' failed: symbol not defined
ld: error: version script assignment of 'PCRE2_10.47' to symbol 'pcre2_jit_free_unused_memory_8' failed: symbol not defined
ld: error: version script assignment of 'PCRE2_10.47' to symbol 'pcre2_jit_match_8' failed: symbol not defined
ld: error: version script assignment of 'PCRE2_10.47' to symbol 'pcre2_jit_stack_assign_8' failed: symbol not defined
ld: error: version script assignment of 'PCRE2_10.47' to symbol 'pcre2_jit_stack_create_8' failed: symbol not defined
ld: error: version script assignment of 'PCRE2_10.47' to symbol 'pcre2_jit_stack_free_8' failed: symbol not defined

might be related to 7ed728c

---

Added a patch to fix libpcre:

--- libpcre/src/libpcre2-8.sym.orig	2026-03-11 11:27:17.187238000 +0100
+++ libpcre/src/libpcre2-8.sym	2026-03-11 11:27:31.128995000 +0100
@@ -25,12 +25,6 @@
     pcre2_get_ovector_count_8;
     pcre2_get_ovector_pointer_8;
     pcre2_get_startchar_8;
-    pcre2_jit_compile_8;
-    pcre2_jit_free_unused_memory_8;
-    pcre2_jit_match_8;
-    pcre2_jit_stack_assign_8;
-    pcre2_jit_stack_create_8;
-    pcre2_jit_stack_free_8;
     pcre2_maketables_8;
     pcre2_maketables_free_8;
     pcre2_match_8;

now it's building a binary. Which at long last is showing the correct MAC address again 🥳

so TLDR: FreeBSD needs to fix its patch for bpf
will continue tracking on their own bugtracker: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293713

[dmiller-nmap]

Of course we'd love for Nmap to build on FreeBSD without needing patches, so I'll continue to look at how to get our configure script to work better.