Solution de rechange
Comme d'autres utilisateurs, je suis gêné par cet inconvénient mais j'ai trouvé une solution de contournement 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 de l'hôte sont les mêmes avec cette seule ligne :
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Si le Macbook continue à renommer immédiatement ComputerName avec un suffixe, vous peut être en mesure de le faire cesser en l'éteignant Wake for Network Access .
System PreferencesEnergy SaverWake 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 ComputerName en utilisant le System PreferencesSharingComputer Name préférence pour les champs de texte.
Si cela ne vous a pas aidé, essayez 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, réessayez de renommer votre machine en utilisant les commandes ci-dessus.
Si cela toujours n'a pas fonctionné, essayez de tuer le mDNSResponder service :
sudo killall -HUP mDNSResponder
Ensuite, essayez à nouveau de réinitialiser le nom de votre ordinateur en utilisant l'option ci-dessus. scutil des commandes.
Si vous trouvez que tout cela ne sert à rien, il y a quelques autres solutions signalées qui comprennent :
-
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 TOUT le matériel de réseau
Discussion du problème
D'après mon expérience, la définition du nom d'hôte de cette manière, ou par le biais de l'option standard System PreferencesSharingComputer Name ne dure qu'une courte période de temps. Celle-ci est généralement < 24 heures, mais parfois le ComputerName même change immédiatement pour avoir un nombre suffixé entre parenthèses (N) . J'ai observé que ce numéro est immédiatement réglé sur soit (4) o (5) récemment après avoir utilisé le scutil --set les commandes ci-dessus.
La cause de ce comportement est due à un code démon exécuté dans 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 TOUTES de mes essais, les noms d'hôtes que j'ai choisis ont JAMAIS été utilisé auparavant sur le réseau et avait en outre JAMAIS a été utilisé pour tout dispositif Bluetooth également.
La véritable cause du "déclenchement" de ce comportement est inconnue et non vérifiée. C'est-à-dire que : A travers toutes mes recherches en ligne et mes tests, je n'ai pas été capable de déterminer définitivement pourquoi Mac OS décide que le nom est déjà utilisé alors que c'est clairement le cas. NO et ne l'a jamais été.
Ma théorie est que d'une manière ou d'une autre mDNS également connu sous le nom de Bonjour ( Avahi pour les utilisateurs de Linux, ou Zero-conf Mise en réseau aux utilisateurs de Windows) pourrait être en partie responsable. D'une manière ou d'une autre, le nom d'hôte précédent du Macbook ou de l'appareil Apple est conservé quelque part dans le système d'exploitation de l'entreprise. mDNS ou peut-être une forme de ARP table + informations sur le nom d'hôte qui sont découvertes et stockées par le Macbook ou l'appareil Apple. Il pourrait s'agir d'une sorte de condition de course. D'une manière ou d'une autre, l'entrée est considérée comme un doublon et déclenche le comportement de renommage du suffixe de Mac OS.
Le nombre de noms d'hôtes suffixés est visible lors de l'utilisation de l'application Apple. Découverte de services DNS utilitaire dns-sd :
Par exemple, en utilisant le nom d'hôte my-mbp-hostname il pourrait 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 avoir accès à l'état interne de Mac OS et aux outils de débogage de bas niveau d'Apple OS. Les interactions entre mdnsd , mDNSResponder et mDNSResponderHelper avec d'autres services Mac OS ou même d'autres démons Avahi sur le réseau ne sont pas bien documentés ou facilement observables. L'état actuel de certaines formes de découverte du réseau peut être visualisé grâce à dns-sd y arp -a ou peut-être arp -a -n . D'autres théories ou endroits potentiels où ces informations de nom d'hôte peuvent être stockées pourraient être :
- Noms des périphériques Bluetooth conservés par le système d'exploitation quelque part
- Les informations SMB (partage de fichiers Windows) sont mises en cache à partir du réseau de façon périodique par
smbd ( /System/Library/LaunchDaemons/com.apple.smbd.plist )
- Les informations de partage AFP sont mises en cache à partir du réseau (également probablement par
smbd ?)
-
mDNS / Avahi un réflecteur (ou un autre type de rediffusion des paquets Bonjour / zero-conf sur le réseau par un routeur ou un autre dispositif) ?
- Pourrait être mis en cache par
mDNSResponder o mdnsd ( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist )
Solution (placeholder)
En date du 6 octobre 2017, il n'y a toujours pas de solution complète de la part d'Apple ni de remède pour éviter que ce problème ne se reproduise. Je recommande de déposer une Rapport de bogue avec Apple décrivant ce problème. Vous pouvez également contacter Assistance clientèle Apple .
Plus il y a de personnes qui font du bruit à propos de ce problème ennuyeux, plus vite les chefs de produit d'Apple établiront des priorités afin que les ingénieurs puissent le résoudre.
Débogage / Pistes d'investigation futures
Ce site Forum de discussion MacRumors a quelques informations utiles et ajoute une théorie selon laquelle Wake for Wi-Fi Network Access et le dispositif Wake / Sleep a quelque chose à voir avec ce problème. D'autres théories présentées ont trait à l'utilisation de plusieurs adaptateurs réseau (par exemple : WiFi + Thunderbolt Ethernet), aux 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 (5GHz). Ces combinaisons mai faire en sorte qu'une version "fantôme" de l'appareil Apple apparaisse temporairement sur le réseau, déclenchant le changement de nom.
Il y avait aucune ligne de journal utile sur /var/log/system.log qui semblait lié au déclenchement de ce comportement de renommage. Apparemment, mDNSResponder peuvent être configurés à des niveaux de journalisation plus élevés :
- Erreur - Messages d'erreur
- Avertissement - Opérations initiées par le client
- Avis - Opérations de procuration de sommeil
- Info - Messages d'information
Comment définir ces niveaux de débogage autrement que par un fichier inexistant ? /Library/Preferences/com.apple.mDNSResponder.plist n'était pas clair. Je n'avais pas d'exemple de configuration plist à utiliser, donc je n'ai pas pu obtenir d'informations supplémentaires sur la journalisation à partir de mDNSResponder .
Des outils tels que Wireshark pourrait être utile pour montrer mDNS diffusés sur le réseau avec d'autres informations potentiellement pertinentes sur les paquets ARP parmi d'autres trafics.
Sur Mac OS, d'autres outils tels que dscacheutil peut exister pour visualiser ces informations. Il n'est pas bien documenté ou clair comment voir le cache définitif de ces informations qui est utilisé par le code de renommage des noms d'hôtes. Lorsque j'ai testé cet utilitaire, il n'a pas produit de résultat utile, sauf en utilisant le mode de requête pour le nom d'hôte exact (IPs nettoyés 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
