Umgehung
Wie andere Benutzer bin ich von diesem Ärger geplagt, habe jedoch eine halbwegs zufriedenstellende Problemumgehung gefunden:
my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done
Nachdem Sie diesen Befehl ausgeführt haben, können Sie überprüfen, ob alle Stellen, an denen der Hostname gespeichert ist, mit diesem Einzeiler identisch sind:
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Wenn das Macbook ComputerNamemit einem Suffix immer wieder umbenannt wird, können Sie es möglicherweise stoppen, indem Sie es ausschalten Wake for Network Access.
System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked
Benennen Sie Ihr Gerät nach dem Ausschalten mit den obigen Befehlen um, um den Vorgang abzuschließen. Sie können auch versuchen, das Zurücksetzen zu erzwingen, ComputerNameindem Sie die System Preferences→Sharing→Computer NameTextfeldeinstellung verwenden.
Wenn dies nicht geholfen hat, versuchen Sie, den mDNS-Cache zu leeren :
# El Capitan (10.11) and later
# check if you have dscacheutil command with: which dscacheutil
sudo dscacheutil -flushcache
# Yosemite (10.10) and ealier
# check if you have discoveryutil command with: which discoveryutil
sudo discoveryutil mdnsflushcache
sudo discoveryutil mdnsrestartquestions
sudo discoveryutil mdnsrestartregistrations
sudo discoveryutil udnsflushcache
sudo discoveryutil udnsrestartquestions
Versuchen Sie nach dem Leeren des mDNS-Caches erneut, Ihren Computer mit den obigen Befehlen umzubenennen.
Wenn dies immer noch nicht funktioniert, versuchen Sie, den mDNSResponderDienst zu beenden:
sudo killall -HUP mDNSResponder
Versuchen Sie dann erneut, den Computernamen mit den oben genannten scutilBefehlen zurückzusetzen.
Wenn Sie feststellen, dass nichts davon gut tut, gibt es einige andere gemeldete Lösungen, die Folgendes umfassen:
- Stellen Sie sicher, dass Sie nur eine Verbindung zum lokalen Netzwerk haben
Schalten Sie Bonjour aus und wieder ein
# Yosemite (10.10) (and other versions with discoveryd?)
# Check for discoveryd with: ps auxww | grep -i discoveryd
sudo killall discoveryd
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
# Mac OS versions without discoveryd
# Check for mDNSResponder with: ps auxww | grep -i mDNSResponder
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
Fahren Sie ALLE Netzwerkhardware herunter und setzen Sie sie zurück
Problembesprechung
Nach meiner Erfahrung System Preferences→Sharing→Computer Namedauert das Festlegen des Hostnamens auf diese Weise oder über den Standard nur einen kurzen Zeitraum. Dies ist normalerweise <24 Stunden, aber manchmal ComputerNameändert sich die Gerade sofort, sodass eine angehängte Zahl in Klammern steht (N). Ich habe beobachtet, dass diese Zahl sofort nach der Verwendung der obigen Befehle auf entweder (4)oder vor (5)kurzem eingestellt wird scutil --set.
Die Ursache für dieses Verhalten liegt in einem Daemon-Code, der unter Mac OS ausgeführt wird und versucht, (N)jedes Mal, wenn derselbe Hostname im Netzwerk gefunden wird , ein nummeriertes Suffix hinzuzufügen . In ALLEN meinen Tests wurden die von mir ausgewählten Hostnamen NIE zuvor im Netzwerk und NIE zusätzlich für Bluetooth-Geräte verwendet.
Die wahre Ursache für den "Auslöser" dieses Verhaltens ist unbekannt und nicht überprüft. Das heißt: Bei all meinen Online-Recherchen und Tests konnte ich nicht eindeutig feststellen, warum Mac OS feststellt, dass der Name bereits verwendet wird, wenn er eindeutig NICHT ist und noch nie verwendet wurde.
Meine Theorie ist, dass irgendwie mDNSauch bekannt als Bonjour( Avahifür Linux-Benutzer oder Zero-confNetworking für Windows-Benutzer) teilweise schuld sein kann. Irgendwie bleibt der vorherige Hostname des Macbooks oder des Apple-Geräts erhalten mDNS, oder es werden ARPInformationen zu Tabelle und Hostname angezeigt, die vom Macbook oder Apple-Gerät erkannt und gespeichert werden. Dies könnte eine Art Rennbedingung sein. Irgendwie wird der Eintrag als Duplikat angesehen und löst das Umbenennungsverhalten des Mac OS-Suffix aus.
Die mit Suffixen versehenen Hostnamen werden angezeigt, wenn das von Apple bereitgestellte Dienstprogramm DNS Service Discovery verwendet wirddns-sd :
Wenn Sie beispielsweise den Hostnamen verwenden my-mbp-hostname, wird dieser möglicherweise wie folgt angezeigt
dns-sd -Z _ssh._tcp
; To direct clients to browse a different domain, substitute that domain in place of '@'
lb._dns-sd._udp PTR @
; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names.
; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local
; names with the correct fully-qualified (unicast) domain name of the target host offering the service.
_ssh._tcp PTR my-mbp-hostname\032(5)._ssh._tcp
my-mbp-hostname\032(5)._ssh._tcp SRV 0 0 22 my-mbp-hostname.local. ; Replace with unicast FQDN of target host
my-mbp-hostname\032(5)._ssh._tcp TXT ""
[...SNIP...]
[...OTHER SSH HOSTS HERE...]
[...SNIP...]
Die Theorie der wahren Ursache ist unbestätigt, da es schwierig ist, zu finden und zu beobachten, was tatsächlich passiert, ohne Zugriff auf interne Mac OS-Status- und Apple OS-Debugging-Tools auf niedriger Ebene. Die Interaktionen zwischen mdnsd, mDNSResponderund mDNSResponderHelpermit anderen Mac OS-Diensten oder sogar anderen Avahi-Dämonen im Netzwerk sind nicht gut dokumentiert oder können nicht leicht beobachtet werden. Der aktuelle Status einiger Formen der Netzwerkerkennung kann durch dns-sdund arp -aoder vielleicht angezeigt werden arp -a -n. Andere Theorien oder mögliche Orte, an denen diese Hostnameninformationen gespeichert werden können, könnten sein:
- Bluetooth-Gerätenamen werden vom Betriebssystem irgendwo beibehalten
- SMB-Informationen (Windows File Share), die regelmäßig vom Netzwerk zwischengespeichert werden von
smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
- AFP-Freigabeinformationen aus dem Netzwerk zwischengespeichert (vermutlich auch von
smbd?)
mDNS/ Avahireflector (oder eine andere Art der erneuten Übertragung von Bonjour / zero-conf-Paketen im Netzwerk durch einen Router oder ein anderes Gerät)?
- Kann zwischengespeichert werden von
mDNSResponderoder mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)
Lösung (Platzhalter)
Bis zum 6. Oktober 2017 gibt es noch keine vollständige Lösung von Apple oder ein Mittel, um ein erneutes Auftreten dieses Problems zu verhindern. Ich empfehle, einen Fehlerbericht bei Apple einzureichen, in dem dieses Problem beschrieben wird. Sie können sich auch an den Apple-Kundendienst wenden .
Je mehr Leute Lärm über dieses ärgerliche Problem machen, desto schneller werden Apple Product Manager Prioritäten setzen, damit Ingenieure es beheben können.
Debugging / Future Lines of Investigation
Diese MacRumors-Forumsdiskussion enthält einige nützliche Informationen sowie eine Theorie, dass Wake for Wi-Fi Network Accessund Gerät Wake / Sleep etwas mit diesem Problem zu tun hat. Andere vorgestellte Theorien beziehen sich auf die Verwendung mehrerer Netzwerkadapter (z. B. WiFi + Thunderbolt Ethernet), Router, bei denen mehrere Access Points auf mehreren Bändern angekündigt sind, z. B. auf 802.11 b/g/n(2,4 GHz) oder 802.11 a/ac(5 GHz). Diese Kombinationen können dazu führen, dass eine "Geister" -Version des Apple-Geräts vorübergehend im Netzwerk angezeigt wird und das Umbenennungsverhalten ausgelöst wird.
Es gab keine brauchbaren Protokollzeilen in /var/log/system.logdie erschienen im Zusammenhang mit dieser Umbenennung Verhalten ausgelöst wird. Angeblich mDNSResponderkann auf höhere Protokollebenen konfiguriert werden:
- Fehler - Fehlermeldungen
- Warnung - Vom Client initiierte Vorgänge
- Hinweis - Sleep-Proxy-Vorgänge
- Info - Informationsmeldungen
Es /Library/Preferences/com.apple.mDNSResponder.plistwar nicht klar, wie diese Debug-Ebenen anders als möglicherweise durch eine nicht vorhandene Datei festgelegt werden sollten . Ich hatte keine plist-Beispielkonfiguration zum Verwenden, daher konnte ich keine zusätzlichen Protokollinformationen abrufen mDNSResponder.
Tools wie Wireshark könnten nützlich sein, um mDNSPakete, die im Netzwerk gesendet werden, zusammen mit anderen potenziell relevanten ARP-Paketinformationen unter anderem Datenverkehr anzuzeigen.
Unter Mac OS dscacheutilgibt es möglicherweise andere Tools , um diese Informationen anzuzeigen. Es ist nicht gut dokumentiert oder klar, wie der endgültige Cache dieser Informationen angezeigt wird, die vom Umbenennungscode des Hostnamens verwendet werden. Als ich dieses Dienstprogramm getestet habe, hat es keine nützliche Ausgabe erzeugt, außer wenn der Abfragemodus für den genauen Hostnamen verwendet wurde (IPs wurden aus Datenschutzgründen gelöscht):
sudo dscacheutil -cachedump -entries host
Unable to get details from the cache node
sudo dscacheutil -cachedump
Unable to get details from the cache node
dscacheutil -cachedump
Unable to get details from the cache node
dscacheutil -cachedump -entries host
Unable to get details from the cache node
dscacheutil -q host -a name my-mbp-hostname.local
name: my-mbp-hostname.local
ipv6_address: fe80:4::1a:1234:abcd:ef01
ipv6_address: 2601:280:1b00:1234:567:abcd:ef01:1234
name: my-mbp-hostname.local
ip_address: 192.168.1.123