macOS 15 doesn't set mac addr in dhcp_leases anymore

[phaer]

Hello,

usage.md recommends /var/db/dhcp_leases to get the IP address of a given virtual machine.
But it seems like macOS Sequoia has changed the format of that file and haven't been able to find much about it nor to easily match DHCP leases with VMs.

{
        name=nixos
        ip_address=192.168.64.30
        hw_address=ff,f1:f5:dd:7f:0:2:0:0:ab:11:b5:40:7c:3:e2:a9:8c:b3
        identifier=ff,f1:f5:dd:7f:0:2:0:0:ab:11:b5:40:7c:3:e2:a9:8c:b3
        lease=0x6782bfd4
}
{
        name=nixos
        ip_address=192.168.64.29
        hw_address=1,f6:25:e2:48:58:1e
        identifier=1,f6:25:e2:48:58:1e
        lease=0x6782bf9a
}

The second entry is an older lease, probably from before I upgraded? It contains the mac address of my machine as expected. The first entry is a current lease, without a mac address. At least not a plain one, I haven't been able to find documentation about the new format.

canonical/multipass#3661 looks like it could be related.
I wonder if might be a side-effect of https://macadmin.fraserhess.com/2024/09/16/handling-mac-address-randomization-in-macos-15/.

[lstocchi]

Hi phaer,

thanks for opening the issue. It could be a side-effect of the MAC address randomization as you pointed out. We'll work on an enhancement to help users find the VM IP.

Were you still able to log in into the VM using the first entry, though?

[phaer]

Were you still able to log in into the VM using the first entry, though?

Yes, the VM is reachable just fine.

A workaround to get a predictable IP for the VM is to use a static mac address and convert that to a ipv6 link local ip (e.g. via ipv6calc or one the online calculators).

[gbraad]

Looks to work like a stack (populates at the top).
And the lease looks like a hex (timestamp?)

0x6782bf9a = 1736621978 => Sat Jan 11 2025 18:59:38 GMT+0000
0x6782bfd4 = 1736622036 => Sat Jan 11 2025 19:00:36 GMT+0000

Wonder how these are so different with just a minute in between.
Not sure what is different for:

• hw_address=ff,
• hw_address=1,

as the length is different. I would think IPv6, but that should not affect the hw address?

[gbraad]

The second entry is an older lease, probably from before I upgraded?

Unlikely, as it is a timestamp from just a minute before. @phaer Was this a single start of the VM ? As I am confused why you got two different entries. Can you explain more how you were connected?

---

The issue you reference assumes the format changed, as mentioned in canonical/multipass#3661 (comment). But I do not think this is the case. @vyasgun just ran this a few times and only got hw_address=1 as entries. So I am wondering if this is something else that causes this... the time is SO close in your case that it feels like a renegotiation... (due to randomization?)

---

I suspect the guest OS. @phaer what did you start?

[cmoulliard]

On macos sonoma, we can still got the entry of the VM name created

❯ cat /var/db/dhcpd_leases
{
        ip_address=192.168.64.4
        hw_address=1,5a:94:ef:e4:c:ee
        identifier=1,5a:94:ef:e4:c:ee
        lease=0x678b83a2
        name=cloud-vm. #### VM CREATED BY VM_KIT
}
{
        ip_address=192.168.64.3
        hw_address=1,56:46:4b:49:54:1
        identifier=1,56:46:4b:49:54:1
        lease=0x67822439
}
{
        ip_address=192.168.64.2
        hw_address=1,12:b2:39:d9:3e:79
        identifier=1,12:b2:39:d9:3e:79
        lease=0x673ef481
}

[afbjorklund]

This issue with "randomized" hw_address (canonical/multipass#3661) was fixed in multipass 1.14.1 (using arp -an)

canonical/multipass#3661 (comment)

I added the workaround (as code) to a small shell script that I used, when running with vfkit instead of with qemu:

https://github.com/afbjorklund/lima-the-hard-way/blob/main/getip.sh

---

$ ./runvzf.sh&
INFO[0000] &{1 1024    {[efi variable-store=efi-variable-store create] true}  [virtio-blk,path=disk.raw virtio-blk,path=seed.img virtio-net,nat,mac=52:54:00:70:2b:71] none://  false } 
INFO[0000] boot parameters: &{EFIVariableStorePath:efi-variable-store CreateVariableStore:true} 
INFO[0000]                                              
INFO[0000] virtual machine parameters:                  
INFO[0000] 	vCPUs: 1                                    
INFO[0000] 	memory: 1024 MiB                            
INFO[0000]                                              
INFO[0000] Adding virtio-blk device (imagePath: disk.raw) 
INFO[0000] Adding virtio-blk device (imagePath: seed.img) 
INFO[0000] Adding virtio-net device (nat: true macAddress: [52:54:00:70:2b:71]) 
INFO[0000] virtual machine is running                   
INFO[0000] waiting for VM to stop                       

$ ./getip.sh "52:54:00:70:2b:71"
ubuntu has address 192.168.64.7

[gbraad]

This is related to the guest OS that runs; in the case of CRC/ Podman Machine, we use gvisor/gvproxy. I guess the OP ran another OS.

Note: I do not have access top a current macbook, so I had to base my assessment on the information given. As @afbjorklund does, the multipass project, uses arp to match the addresses; it is suggested for vfkit to do something similar as part of the API/CLI.

[afbjorklund]

I guess the OP ran another OS.

From the name, I would guess NixOS

[gbraad]

Right... I never trust names given 'bogon' ;-)

[afbjorklund]

This would need to be fixed in minikube as well, it has some vintage code for the dhcpd leases parsing

https://github.com/kubernetes/minikube/blob/master/pkg/drivers/common.go

There is some other issue regarding "security" as well, where you have to open up access to localhost.

• Minikube waits indefinitely for vfkit on MacOS 15.2 kubernetes/minikube#20104

[gbraad]

I remember; We will eventually get to this on our end too, but not the highest priority.
I hate to say, but cat /var/db/dhcp_leases | head -n 7 would work around this for now.

/me hides from @cfergeau...

[phaer]

Hello,

I can confirm that it seems to depend on the client, not the macOS version.

You are right that it's NixOS in my case. The difference between my runs was that the one that has the mac address uses NixOS scripted networking (networking.useDHCP) while the other ones where created with systemd-networkd running in the guest.

So I suspect it might be related to some difference in the DHCP requests / GUID sent by the guest. I don't really have a use case left to look further, and i don't think there's much actionable stuff left for vfkit, except maybe a hint in the README? Feel free to close this :)

[afbjorklund]

It would still be nice if vfkit did all the parsing, and printed the IP address next to the MAC address

But the current documentation is not wrong: "its IP can be found in /var/db/dhcpd_leases on the host"

[phaer]

5 minutes later I found https://unix.stackexchange.com/a/743782 which explains the whole thing.

I just gave it a quick try and can confirm that it works as described. systemd-networkd (as well as probably other dhcp clients) defaults to sending a DUID. If i set ClientIdentifier=mac in the dhcpv4 of my network config, I get the mac address (and a stable ipv4 per mac address) again.

For nixos users

      systemd.network.networks."10-uplink" = {
        matchConfig.Name = lib.mkDefault "en* eth*";
        networkConfig.DHCP = lib.mkDefault "ipv4";
        dhcpV4Config.ClientIdentifier = lib.mkDefault "mac";
      };