¿Cómo detengo el cambio automático e incorrecto del nombre de mi computadora?

Desde que actualicé mi iMac 2009 a Mavericks, a menudo recibo un mensaje que dice 'El nombre de su computadora "Foo" ya está en uso en esta red. El nombre ha sido cambiado a "Foo (2)". '. El número al final se incrementará continuamente con el tiempo a medida que el mismo error continúa ocurriendo.

Es bastante trivial cambiar el nombre de la computadora, pero ¿hay alguna manera de evitar que esto suceda en el futuro? Tenía un viejo Macbook Pro (con Mountain Lion) que tenía el mismo problema, pero mi MBP de principios de 2013 con Mavericks no parece estar sufriendo este problema.

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

¿Está utilizando dos dispositivos de red que están en la misma LAN? Por ejemplo, wifi y ethernet con cable? Intenta desactivar uno de ellos. Solía ​​tener ese problema y lo solucioné de esta manera.

El mismo problema aqui. Pero parece que la máquina del tiempo acepta el nombre foo (2) y todavía hace la copia de seguridad en el mismo lugar (no parece rehacer toda la copia de seguridad, continúa). Así que no hay daño, no hay falta. Creo que está relacionado con múltiples interfaces activas, abrí el ethernet para acelerar mi copia de seguridad.

No hay una buena manera de detener esto. Apple tendría que reemplazar el código del nombre de host para que a los usuarios (personas y programas) siempre se les presente el nombre de host establecido scutily hagan todo el cambio de nombre / traducción bajo el capó.

Dado que esto ha estado sucediendo en todas las líneas de productos de Apple (Apple TV, iPhone, Mac y, presumiblemente, incluso en el Apple Watch) desde 2012 al menos, no está claro que Apple vea que esto es un problema a solucionar.

Esto probablemente tenga que ver con el usuario que está activo cuando se une a la red y configura la máquina por primera vez. Es probable que cuando construye estas máquinas siempre lo hace como el mismo usuario

Si crea un usuario, por ejemplo, dave on, por ejemplo, un MacBook Pro, la máquina configurará automáticamente los nombres de la siguiente manera:

Nombre de la computadora: dave's MacBook Pro

nombre de host local: daves-MacBook-Pro.local

y en Terminal, el nombre de host se mostrará como: daves-mbp

Suponiendo que la próxima máquina que inicie sesión como 'dave' también sea una MacBook Pro, establecerá exactamente los mismos detalles: se conecta a la red y recibe el mensaje sobre el nombre duplicado.

Donde trabajo, cambiamos el nombre en Compartir, luego abrimos un terminal y ejecutamos el siguiente comando: sudo scutil –-set HostName new_hostname

(donde new_hostname es su nombre elegido)

Luego salga y reinicie la terminal y verá el nuevo nombre de host.

También obtendrá este problema al migrar usuarios a nuevas máquinas: el asistente de migración / Time Machine cambiará el nombre de la nueva máquina

alguna información típicamente débil sobre nombres: http://support.apple.com/kb/PH13790

Esto ocurre cuando se ejecutan dos servidores DHCP superpuestos. Si está utilizando más de un enrutador (modo puente), asegúrese de que solo uno de ellos ejecute DHCP sin una IP estática.