I need some help. My Mac Studio renames itself everytime I reboot it.

[svenmany]

Some routers forward mDNS across subnets/VLANs, so if your Mac's WiFi interface is on one subnet/VLAN and Ethernet is on another, that would cause this problem.

I know this because I have a… complex home network. I use many VLANs to segment off the unholy spawn that is all IoT/smarthome gear. Unfortunately, with HomeKit, you need to forward mDNS (Bonjour) across the VLANs or it doesn't work well. This isn't a problem—I think—if your WiFi and Ethernet interfaces are on the same VLAN, but if they're on different ones (e.g. for "guest" WiFi or various other reasons like a VLAN for each WiFi version / band), the Mac gets confused and doesn't realize it's talking to itself.

I'm not sure why the mDNS response packet can't include a node-unique identifier (like a UUID initialized on boot) that the node then uses to realize it just said hello, er, bonjour, to itself across a network… Maybe I should put that in a feedback ticket.

I've been looking a bit at https://www.rfc-editor.org/rfc/rfc6762.html, which is where this is all documented. Apple doesn't own the protocol and has to interoperate with other non-Apple devices on the network.

There is a lot of interesting things in the RFC about the challenges of a computer having multiple interfaces reachable from each other via broadcast. Apple could have bugs in this but the OP had the issue with only a single interface in use during testing.

 

[transmaster]

The instructions given are probably trying to address a name caching issue on the Mac rather than the Eero. It makes sense to try it.

If there is an actual naming conflict on the network then allowing it to remain would be pretty bad. Setting LocalHostName is assigning the mDNS name. I would have thought this is just the command-line way of setting that rather than using System Settings. Do you have any reference that suggests this use of scutil disables subsequent conflict detection or prevents the Mac from renaming itself if it detects that?

I really think this is a 26.4 issue. I did not have this until this version loaded. I am just going to ignore it, it does not affect how the Mac works, it is just the annoyance of it.

 

[gwang73]

The instructions given are probably trying to address a name caching issue on the Mac rather than the Eero. It makes sense to try it.

If there is an actual naming conflict on the network then allowing it to remain would be pretty bad. Setting LocalHostName is assigning the mDNS name. I would have thought this is just the command-line way of setting that rather than using System Settings. Do you have any reference that suggests this use of scutil disables subsequent conflict detection or prevents the Mac from renaming itself if it detects that?

It stops the Mac from checking and renaming itself on the network. You're right in that if there is an actual name conflict, then it would be bad. If you take this manual approach, make sure the hostname is unique.

With every new Mac, I've been setting this manually since Yosemite when Apple changed mDNSresponder to discoveryd and created a disaster.

 

[nmt1900]

That discoveryd debacle was so bad that Apple had to revert back to mDNSresponder and bury discoveryd completely. It happened at 10.10.4 beta4 so quite long time ago...

 

[isomorphic]

Open Terminal and set the hostnames manually. This stops the machine renaming itself.

sudo scutil --set HostName
sudo scutil --set LocalHostName
sudo scutil --set ComputerName
dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Reboot

I can tell you definitively this does not stop the machine from renaming itself. It may for a while, but at some point it reverts and you get the "The name of your computer…" dialog again. At least in my situation.

Source: I got so tired of running these commands I made them into a literal set-host-name script.

Again, I speculate there is something about my many-VLAN network with mDNS/Bonjour forwarding that is causing this.

 

[bogdanw]

about scutil https://forums.macrumors.com/threads/hostname-in-terminal-with-macos-15-1-1.2444219/post-33598010

 

[boppin]

Hi,

Just restart your router or shut off. We have had the same or similar problem here so we solved it this way.

 

[svenmany]

I can tell you definitively this does not stop the machine from renaming itself. It may for a while, but at some point it reverts and you get the "The name of your computer…" dialog again. At least in my situation.

Source: I got so tired of running these commands I made them into a literal set-host-name script.

Again, I speculate there is something about my many-VLAN network with mDNS/Bonjour forwarding that is causing this.

I was going to experiment with this on the weekend. I was going to run those commands and then just use Wireshark to see what happens when the interface is brought up. Also, it's pretty easy to check what would happen in a collision since I have multiple computers.

It would be very surprising if the scutil command actually disabled collision detection and prevented the rename. That could break the functioning of many networks (even large corporate one) and Apple would take a lot of flack for allowing that to happen. This would be a violation of the mDNS spec.

The VLAN situation is discussed indirectly in the mDNS spec in the section about multi-homed hosts. Each interface broadcasts its name. Assuming interface A is already setup, when interface B broadcasts the name, interface A sees that. The Mac knows that nay mDNS caches on the network will have flushed the A's assignment, so interface A has to reassert its claim on the name. Of course, then interface B will see the A assignment and it, in turn, has to reassert its claim on the name. To prevent infinite loops of these reassertions, the spec discusses the use of a timeout to prevent these cache clears. This allows the same name to co-exist in the mDNS caches for the two different interfaces. I suppose this is a bit of a fragile situation, since bugs on the Mac or routers which propagate mDNS could cause problems.

But the OP had the problem with a single interface when they disabled WiFi. So the collision being detected is being caused by a router broadcasting that the name is in use as the Mac brings up its ethernet interface. This would be trivial to diagnose with a bit of Wireshark experience.

Because the Eero is a mesh router, it likely has functionality to reduce the need to constantly propagate mDNS broadcasts between all the mesh nodes. It likely does some caching and there's a bug there.

 

[boppin]

Did you restarted all of your machines and devices? I suggest this instead of anything else. As first step.

If your computer is connected to a router it should get a hostname something like this mycomputer.myrouter.ip