Solución alterna
Al igual que otros usuarios, estoy molesto por esta molestia, pero he encontrado una solución poco satisfactoria:
my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done
Después de ejecutar este comando, puede verificar que todos los lugares donde almacenan el nombre de host sean los mismos con esta línea:
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Si el Macbook cambia de nombre inmediatamente ComputerNamecon un sufijo, puede detenerlo apagándolo Wake for Network Access.
System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked
Una vez apagado, cambie el nombre de su máquina utilizando los comandos anteriores para finalizar. También puede intentar ComputerNameretroceder utilizando la System Preferences→Sharing→Computer Namepreferencia de campo de texto.
Si esto no ayudó, intente vaciar su caché 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
Después de vaciar la caché mDNS, vuelva a intentar cambiar el nombre de su máquina con los comandos anteriores.
Si esto aún no funciona, intente eliminar el mDNSResponderservicio:
sudo killall -HUP mDNSResponder
Luego, vuelva a intentar restablecer el nombre de su computadora con los scutilcomandos anteriores .
Si encuentra que nada de esto está haciendo ningún bien, hay algunas otras soluciones reportadas que incluyen:
- Asegúrese de tener solo una conexión a la red local
Apague y vuelva a encender 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
Apague y restablezca TODO el hardware de red
Discusión del problema
En mi experiencia, configurar el nombre de host de esta manera, o mediante el estándar, System Preferences→Sharing→Computer Namesolo dura un corto período de tiempo. Esto suele ser <24 horas, pero a veces el ComputerNamepar cambia inmediatamente para tener un número con sufijo entre paréntesis (N). He observado que este número se establece inmediatamente en uno (4)o (5)recientemente después de usar los scutil --setcomandos anteriores.
La causa de este comportamiento se debe a que se está ejecutando algún código de daemon en Mac OS que intenta agregar un sufijo numerado (N)cada vez que se encuentra el mismo nombre de host en la red. En TODAS mis pruebas, los nombres de host que he elegido NUNCA se han utilizado antes en la red y, además, NUNCA se han utilizado para dispositivos Bluetooth.
La verdadera causa del "desencadenante" de este comportamiento es desconocida y no está verificada. Es decir: a través de toda mi investigación en línea y pruebas, no he podido determinar definitivamente por qué Mac OS decide que el nombre ya está en uso cuando claramente NO y nunca lo ha estado.
Mi teoría es que, de alguna manera, mDNStambién conocido como Bonjour( Avahipara usuarios de Linux, o usuarios de Zero-confNetworking to Windows) puede ser en parte el culpable. De alguna manera, el nombre de host anterior del dispositivo Macbook o Apple se conserva en algún lugar mDNS, o tal vez alguna forma de ARPinformación de tabla + nombre de host que es descubierta y almacenada por el dispositivo Macbook o Apple. Esto podría ser algún tipo de condición de carrera. De alguna manera, la entrada se ve como duplicada y desencadena el comportamiento de cambio de nombre del sufijo de Mac OS.
El número de nombres de host con sufijo es visible cuando se utiliza la utilidad de descubrimiento de servicios DNS proporcionada por Apple dns-sd:
Por ejemplo, usando el nombre de host my-mbp-hostname, puede aparecer como las siguientes entradas
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 teoría de la verdadera causa no está confirmada, ya que es difícil encontrar y observar lo que realmente está sucediendo sin acceso al estado interno de Mac OS y las herramientas de depuración de bajo nivel de Apple OS. Las interacciones entre mdnsd, mDNSRespondery mDNSResponderHelpercon otros servicios de Mac OS o incluso otros demonios de Avahi en la red no están bien documentados ni son fácilmente observables. El estado actual de algunas formas de descubrimiento de red se puede ver a través dns-sdy arp -ao tal vez arp -a -n. Otras teorías o lugares potenciales donde se puede almacenar esta información de nombre de host podrían ser:
- Los nombres de dispositivos Bluetooth persisten en algún lugar del sistema operativo
- Información SMB (recurso compartido de archivos de Windows) almacenada en caché de la red periódicamente por
smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
- AFP comparte información almacenada en caché de la red (¿también presumiblemente por
smbd?)
mDNS/ Avahireflector (u otro tipo de retransmisión de paquetes Bonjour / zero-conf en la red por un enrutador u otro dispositivo)?
- Podría ser almacenado en caché por
mDNSRespondero mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)
Solución (marcador de posición)
A partir del 6 de octubre de 2017, todavía no existe una solución completa de Apple o un remedio para evitar que este problema vuelva a ocurrir. Recomiendo presentar un informe de error con Apple que describa este problema. También puede ponerse en contacto con Atención al cliente de Apple .
Cuantas más personas hagan ruido sobre este molesto problema, más rápido se priorizarán los Gerentes de Producto de Apple para que los Ingenieros puedan solucionarlo.
Depuración / Líneas futuras de investigación
Esta discusión en el foro de MacRumors tiene información útil, además de agregar una teoría de que el Wake for Wi-Fi Network Accessdispositivo Wake / Sleep tiene algo que ver con este problema. Otras teorías presentadas tienen que ver con el uso de múltiples adaptadores de red (por ejemplo: WiFi + Thunderbolt Ethernet), enrutadores que tienen múltiples puntos de acceso anunciados en múltiples bandas como 802.11 b/g/n(2.4GHz) o 802.11 a/ac(5GHz). Estas combinaciones pueden provocar que una versión "fantasma" del dispositivo Apple aparezca en la red de alguna manera temporalmente, lo que desencadena el comportamiento de cambio de nombre.
Había no hay líneas de registro útiles en el /var/log/system.logque parecía relacionados con este comportamiento de cambio de nombre que se dispare. Supuestamente mDNSResponderse puede configurar para niveles de registro más altos:
- Error: mensajes de error
- Advertencia: operaciones iniciadas por el cliente
- Aviso: operaciones de proxy de suspensión
- Información: mensajes informativos
/Library/Preferences/com.apple.mDNSResponder.plistNo estaba claro cómo establecer estos niveles de depuración que no sean quizás a través de un archivo inexistente . No tenía una configuración de ejemplo de plist para usar, por lo que no pude obtener ninguna información de registro adicional mDNSResponder.
Herramientas como Wireshark podrían ser útiles para mostrar los mDNSpaquetes que se transmiten en la red junto con otra información de paquetes ARP potencialmente relevante entre otro tráfico.
En Mac OS, dscacheutilpueden existir otras herramientas como para ver esta información. No está bien documentado o claro cómo ver la memoria caché definitiva de esta información que utiliza el código de cambio de nombre del host. Cuando probé esta utilidad, no produjo ningún resultado útil, excepto cuando utilicé el modo de consulta para el nombre de host exacto (IPs depuradas por privacidad):
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