Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
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.
 
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.
 
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.
 
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...
 
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.
 
Hi,

Just restart your router or shut off. We have had the same or similar problem here so we solved it this way.
 
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.
 
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
 
Last edited:
One of the few aspects I find unsatisfactory about the EERO router is its design as a wireless device. It only has two Ethernet ports. I utilize one for input from my DSL modem, while the other connects to a Netgear 8-Port Gigabit Ethernet Unmanaged Switch (GS108). From there, I connect to my Mac, the GMK11 mini PC, and the Yamaha AVR. I do not use the wireless connection for these three devices because I have high-powered amateur radio equipment in close proximity. While I do not encounter issues with RFI from the Wi-Fi system, this router has consistently functioned well, so why change it now? I have been using this system in this configuration since 2023. The renaming issue has only recently emerged with macOS 26.4.


 
Found a discussion about this issue on Reddit. It is an mDNS issue, and there is not much you can do about it.
I don't think so. I have had a similar problem with a Pixel pro smartphone and a restart of the router did help.

And what device is your DNS and DHCP server? I hope only one! Your router!

And please read this:


Please make sure that your router is up to date.

Use a proper name for your computer. Instead of using, for example, "George Washington's MacBook Pro" use a shorter name without spaces like "GeorgewMBP" or something similar. For my Air it would be "boppinsAir" and not "boppins Air".

A name that is too long may also cause the effect that Sharing will something like "Windows users can access it at smb://noname".

And please don't use at all some kind of Terminal commands. The rest is the job of your router or DNS and DHCP server.
 
Last edited:
  • Like
Reactions: transmaster
I have seen this exact behavior many years ago. It is not new.

Unfortunately, it's long enough ago that I don't remember what I did to resolve it.
 
Is this option enabled or disabled under General -> Sharing -> Local hostname?
1778345189481.png
 
I think you're all making this unnecessarily complicated. Please read what I wrote in reply #38.
 
I think you're all making this unnecessarily complicated. Please read what I wrote in reply #38.

I think you had one piece of advice in that post that the OP could address.

The actual mDNS hostname of the computer with display name of "Radio Station W7ITC (14421)" is actually "Radio-Station-W7ITC-14421.local". Also, the name is case-insensitive, so that would collide with "radio-station-w7itc-14421.local". I would certainly try simpler names with only the allowed characters of letters, numbers, and hyphens (not at the beginning and end of the name). That could eliminate the required sanitization of the name in case that is tripping over a bug somewhere.
 
  • Like
Reactions: transmaster
The actual mDNS hostname of the computer with display name of "Radio Station W7ITC (14421)" is actually "Radio-Station-W7ITC-14421.local".

The .local is for Bonjour only! Please use another term.

For example, our router from Deutsche Telekom gives every device the following:

mycomputer.speedport.ip

My MacBook Air and our printer is still reachable via Bonjour.
 
The .local is for Bonjour only! Please use another term.

For example, our router from Deutsche Telekom gives every device the following:

mycomputer.speedport.ip

My MacBook Air and our printer is still reachable via Bonjour.

I think you're just saying that the user should not append ".local" to the name entered in System Settings. That is correct.

.local is the required top-level name for all mDNS. mDNS is Bonjour. When you assign a name in the System Settings, the Mac adds the .local automatically to derive the Bonjour name. That is what is used when querying the network. The ".local" should not be typed into System Settings. If you do, then the name derived is a little unexpected:

Entered in System Settings: xyz.local -> derived mDNS name: xyzlocal.local

That's likely not what a user intended.


Which has a link to the old overview document:

 
I think you're just saying that the user should not append ".local" to the name entered in System Settings. That is correct.

.local is the required top-level name for all mDNS. mDNS is Bonjour.

No, no, no!

Am I speaking Spanish or Chinese? (Explanation: An idiom used here in Germany when someone is not understood or is misunderstood.)

The first domain name, so to say, is that what your router gives you. As I said before "speedport.ip" and the ".local" comes after.

The "speedport.ip" comes first, after this the ".local" comes second.
 
No, no, no!

Am I speaking Spanish or Chinese? (Explanation: An idiom used here in Germany when someone is not understood or is misunderstood.)

The first domain name, so to say, is that what your router gives you. As I said before "speedport.ip" and the ".local" comes after.

The "speedport.ip" comes first, after this the ".local" comes second.

My router doesn't give me my domain name. I'll let the OP speak up on how his name is being assigned.
 
Open terminal and type
Ping my computer

And a result like

mycomputer.router.ip

should appear

In my world, my OPNsense router's DHCP server gives my computer the domain's name (e.g. xyz.com). My computer then combines that name with its own local name (sven) to get a fully qualified name of the computer within the domain (sven.xyz.com). That combination is not used for mDNS/Bonjour. Only the name "sven" is used for Bonjour. My router doesn't know the name "sven".

It's hard to experiment much with this since System Settings seems to have acquired a bug that makes it hard to change my computer's name. But I did manage an experiment where I typed some random name into System Settings - "bozy m(24)". I used the space and parenthesis intentionally to see what happens. I then rebooted.

In the terminal.

% hostname
bozy-m24ana.xyz.com

% scutil --get LocalHostName
bozy-m24ana

% scutil --get ComputerName
bozy m(24)ana


More interesting is how Bonjour uses this name. At no point is ".xyz.com" mentioned in any of the bonjour network traffic or various bonjour tools I have (e.g. the Flame app). It advertises various services under the full name with the space and parenthesis. But, in all cases the service is listed as being available at bozy-m24ana.local. Here's a screenshot from Wireshark showing my computer responding to a Bonjour query.

1779035217719.png


And a Flame screenshot looking at the smb Bonjour service my computer is offering:


1779035800237.png



Bonjour makes use of the friendly name (with spaces and parenthesis) in service advertisements. But in all cases, the address given to access the service is a bozy-m24ana.local.

I would definitely not be using friendly names that didn't match the derived name on the chance this is causing an issue. So I would recommend the OP eliminate the parenthesis and spaces from his name.
 
  • Like
Reactions: chown33
In my world, my OPNsense router's DHCP server gives my computer the domain's name (e.g. xyz.com).
Hi,

From our EPSON printer, network status sheet:

<TCP/IP IPv4>
IPv4: Enable
Obtain IP Address: Auto(DHCP)
IP Address: 192.168.x.x
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.x.x
APIPA: Enable
Acquisition way of DNS ADDR: Auto
Primary DNS Address: router ip
Secondary DNS Address: none

<Dynamic DNS>
Dynamic DNS: Enable
Host Name: EPSON.speedport.ip
Obtain Host Name: Auto

<Bonjour>
Bonjour: Enable
Bonjour Name: EPSON.local
Bonjour Service Name: EPSON printer name


Everything works fine. We just typed in the password for our WLAN/WiFi and it just works.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.