solution de contournement
Comme d'autres utilisateurs, je suis en proie à cette gêne, mais j'ai trouvé une solution semi-satisfaisante:
my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done
Après avoir exécuté cette commande, vous pouvez vérifier que tous les endroits où ils stockent le nom d'hôte sont les mêmes avec ce one-liner:
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Si le Macbook continue de renommer immédiatement ComputerNameavec un suffixe, vous pourrez peut-être l' arrêter en le désactivant Wake for Network Access.
System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked
Une fois éteint, renommez votre machine en utilisant les commandes ci-dessus pour terminer. Vous pouvez également essayer de forcer le ComputerNameretour en utilisant la System Preferences→Sharing→Computer Namepréférence de champ de texte.
Si cela n'a pas aidé, essayez de vider votre cache mDNS :
# 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
Après avoir vidé le cache mDNS, essayez de renommer votre ordinateur à l'aide des commandes ci-dessus.
Si cela ne fonctionne toujours pas, essayez de tuer le mDNSResponderservice:
sudo killall -HUP mDNSResponder
Ensuite, réessayez pour réinitialiser le nom de votre ordinateur à l'aide des scutilcommandes ci-dessus .
Si vous constatez que rien de tout cela ne sert à rien, il existe d' autres solutions signalées, notamment:
- Assurez-vous que vous n'avez qu'une seule connexion au réseau local
Désactiver et réactiver Bonjour
# 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
Arrêtez et réinitialisez TOUS les matériels réseau
Discussion du problème
D'après mon expérience, définir le nom d'hôte de cette façon, ou via la norme, System Preferences→Sharing→Computer Namene dure que peu de temps. Ceci est généralement <24 heures, mais parfois ComputerNamemême les changements immédiatement pour avoir un nombre suffixé entre parenthèses (N). J'ai observé que ce nombre était immédiatement défini sur (4)ou (5)récemment après avoir utilisé les scutil --setcommandes ci-dessus.
La cause de ce comportement est due à l'exécution de code démon sous Mac OS qui tente d'ajouter un suffixe numéroté (N)chaque fois que le même nom d'hôte est trouvé sur le réseau. Dans TOUS mes tests, les noms d'hôtes que j'ai choisis n'ont JAMAIS été utilisés auparavant sur le réseau et n'ont en outre JAMAIS été utilisés pour des appareils Bluetooth.
La véritable cause du «déclencheur» de ce comportement est inconnue et non vérifiée. C'est-à-dire: à travers toutes mes recherches en ligne et mes tests, je n'ai pas pu déterminer définitivement pourquoi Mac OS décide que le nom est déjà utilisé alors qu'il n'est clairement PAS et qu'il ne l'a jamais été.
Ma théorie est qu'en quelque sorte mDNSégalement connu sous le nom de Bonjour( Avahipour les utilisateurs de Linux ou pour les utilisateurs de Zero-confréseau pour Windows) peut être en partie à blâmer. D'une manière ou d'une autre, le nom d'hôte précédent du Macbook ou du périphérique Apple est conservé quelque part mDNS, ou peut-être une forme d' ARPinformations de table + nom d'hôte qui est découverte et stockée par le Macbook ou le périphérique Apple. Cela pourrait être une sorte de condition de concurrence. D'une manière ou d'une autre, l'entrée est considérée comme dupliquée et déclenche le comportement de changement de nom du suffixe Mac OS.
Le nombre de noms d'hôtes suffixés est visible lorsque vous utilisez l' utilitaire de découverte de service DNS fourni par Apple dns-sd:
Par exemple, en utilisant le nom d'hôte my-mbp-hostname, il peut apparaître comme les entrées suivantes
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...]
La théorie de la véritable cause n'est pas confirmée car il est difficile de trouver et d'observer ce qui se passe réellement sans accès à l'état interne de Mac OS et aux outils de débogage Apple OS de bas niveau. Les interactions entre mdnsd, mDNSResponderet mDNSResponderHelperavec d'autres services Mac OS ou même d'autres démons Avahi sur le réseau ne sont pas bien documentées ou facilement observables. L'état actuel de certaines formes de découverte de réseau peut être visualisé à travers dns-sdet arp -aou peut-être arp -a -n. D'autres théories ou lieux potentiels où ces informations de nom d'hôte peuvent être stockées pourraient être:
- Les noms des appareils Bluetooth sont conservés quelque part par le système d'exploitation
- Informations SMB (partage de fichiers Windows) mises en cache périodiquement à partir du réseau par
smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
- Informations de partage AFP mises en cache depuis le réseau (également probablement par
smbd?)
mDNS/ Avahiréflecteur (ou autre type de rediffusion de paquets Bonjour / zero-conf sur le réseau par un routeur ou un autre appareil)?
- Pourrait être mis en cache par
mDNSResponderou mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)
Solution (espace réservé)
Au 6 octobre 2017, il n'y avait toujours pas de solution complète d'Apple ni de solution pour éviter que ce problème ne se reproduise. Je recommande de déposer un rapport de bogue auprès d'Apple décrivant ce problème. Vous pouvez également contacter le service client Apple .
Plus il y a de gens qui font du bruit à propos de ce problème ennuyeux, plus les chefs de produit Apple accordent la priorité aux ingénieurs afin qu'ils puissent le résoudre.
Débogage / Lignes d'investigation futures
Cette discussion du forum MacRumors contient des informations utiles ainsi que l'ajout d'une théorie selon laquelle le Wake for Wi-Fi Network Accessréveil / sommeil de l'appareil a quelque chose à voir avec ce problème. Les autres théories présentées concernent l'utilisation de plusieurs adaptateurs réseau (par exemple: WiFi + Thunderbolt Ethernet), des routeurs qui ont plusieurs points d'accès annoncés sur plusieurs bandes, comme sur 802.11 b/g/n(2,4 GHz) ou 802.11 a/ac(5 GHz). Ces combinaisons peuvent provoquer une version "fantôme" de l'appareil Apple sur le réseau temporairement, déclenchant le comportement de changement de nom.
Il n'y avait pas de lignes de journaux utiles dans /var/log/system.logqui semblaient liés à ce comportement de changement de nom déclenchée. Soi-disant mDNSResponderpeut être configuré à des niveaux de journal plus élevés:
- Erreur - Messages d'erreur
- Avertissement - Opérations initiées par le client
- Remarque - Opérations du proxy de mise en veille
- Info - Messages d'information
Comment définir ces niveaux de débogage autrement que peut-être via un fichier inexistant /Library/Preferences/com.apple.mDNSResponder.plistn'était pas clair. Je n'avais pas d'exemple de configuration plist à utiliser, donc je n'ai pas pu obtenir d'informations de journalisation supplémentaires mDNSResponder.
Des outils tels que Wireshark pourraient être utiles pour montrer les mDNSpaquets diffusés sur le réseau avec d'autres informations de paquets ARP potentiellement pertinentes parmi d'autres trafics.
Sous Mac OS, d'autres outils tels que ceux dscacheutilqui existent peuvent afficher ces informations. Il n'est pas bien documenté ou clair comment afficher le cache définitif de ces informations qui est utilisé par le code de changement de nom d'hôte. Lorsque j'ai testé cet utilitaire, il n'a produit aucune sortie utile, sauf lors de l'utilisation du mode de requête pour le nom d'hôte exact (adresses IP nettoyées pour la confidentialité):
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