Obejście
Podobnie jak inni użytkownicy, nękają mnie te irytacje, ale znalazłem częściowo zadowalające obejście:
my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done
Po uruchomieniu tego polecenia możesz sprawdzić, czy wszystkie miejsca, w których przechowują nazwę hosta, są takie same za pomocą tego linku:
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Jeśli Macbook od razu zmienia nazwę ComputerNamez przyrostkiem, być może uda się go zatrzymać, wyłączając Wake for Network Access.
System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked
Po wyłączeniu zmień nazwę komputera za pomocą powyższych poleceń, aby zakończyć. Możesz także spróbować wymusić ComputerNameodpowiedź za pomocą System Preferences→Sharing→Computer Namepreferencji pola tekstowego.
Jeśli to nie pomogło, spróbuj wyczyścić pamięć podręczną 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
Po opróżnieniu pamięci podręcznej mDNS spróbuj ponownie zmienić nazwę komputera, korzystając z powyższych poleceń.
Jeśli to nadal nie działało, spróbuj zabić mDNSResponderusługę:
sudo killall -HUP mDNSResponder
Następnie spróbuj ponownie, aby zresetować nazwę komputera za pomocą powyższych scutilpoleceń.
Jeśli okaże się, że nic z tego nie działa, istnieje kilka innych zgłoszonych rozwiązań, które obejmują:
- Upewnij się, że masz tylko jedno połączenie z siecią lokalną
Wyłącz Bonjour i włącz go ponownie
# 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
Zamknij i zresetuj CAŁY sprzęt sieciowy
Dyskusja o problemie
Z mojego doświadczenia wynika, że ustawienie nazwy hosta w ten sposób lub poprzez standard System Preferences→Sharing→Computer Nametrwa tylko przez krótki czas. Zazwyczaj jest to <24 godziny, ale czasami ComputerNamenawet parzystość zmienia się natychmiast, tak aby liczba w nawiasach była powiększona (N). Zauważyłem, że po użyciu powyższych poleceń liczba ta została natychmiast ustawiona na jedną (4)lub (5)niedawno scutil --set.
Przyczyna tego zachowania wynika z działania jakiegoś kodu demona w systemie Mac OS, który próbuje dodać numeryczny sufiks za (N)każdym razem, gdy w sieci zostanie znaleziona ta sama nazwa hosta. We WSZYSTKICH moich testach wybrane przeze mnie nazwy hostów NIGDY nie były wcześniej używane w sieci, a ponadto NIGDY nie były używane również w przypadku jakichkolwiek urządzeń Bluetooth.
Prawdziwa przyczyna „wyzwalacza” tego zachowania jest nieznana i niezweryfikowana. Innymi słowy: przez wszystkie moje badania online i testy nie byłem w stanie definitywnie ustalić, dlaczego Mac OS decyduje, że nazwa jest już używana, kiedy wyraźnie NIE jest i nigdy nie była.
Moja teoria jest taka, że jakoś ( mDNSjak dla użytkowników Linuksa lub Networking dla użytkowników Windows) można częściowo winić. W jakiś sposób wcześniejsza nazwa hosta Macbooka lub urządzenia Apple zostaje utrwalona gdzieś w innym miejscu , a może jakaś forma tabeli i informacji o nazwie hosta, które są wykrywane i przechowywane przez Macbooka lub urządzenie Apple. To może być jakiś warunek wyścigu. W jakiś sposób pozycja jest postrzegana jako zduplikowana i wyzwala zachowanie zmiany nazwy sufiksu Mac OS.BonjourAvahiZero-confmDNSARP
Liczba przyrostek nazwy hostów są widoczne podczas używania Jabłko warunkiem DNS Service Discovery narzędzia dns-sd:
Na przykład przy użyciu nazwy hosta my-mbp-hostnamemoże wyglądać jak poniższe wpisy
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...]
Teoria prawdziwej przyczyny jest niepotwierdzona, ponieważ trudno jest znaleźć i zaobserwować, co się właściwie dzieje bez dostępu do wewnętrznych narzędzi do debugowania stanu systemu Mac OS i niskiego poziomu systemu Apple OS. Interakcje pomiędzy mdnsd, mDNSResponderoraz mDNSResponderHelperz innymi usługami Mac OS lub nawet innych demonów avahi w sieci nie są dobrze udokumentowane i łatwo obserwowalne. Obecny stan niektórych form wykrywania sieci może być przeglądany przez, dns-sda arp -amoże i arp -a -n. Inne teorie lub potencjalne miejsca, w których mogą być przechowywane te informacje o nazwie hosta, mogą być:
- Nazwy urządzeń Bluetooth utrwalone gdzieś w systemie operacyjnym
- Informacje SMB (udostępnianie plików systemu Windows) okresowo buforowane z sieci przez
smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
- Informacje o udostępnianiu AFP buforowane z sieci (prawdopodobnie także przez
smbd?)
mDNS/ Avahireflektor (lub inny rodzaj ponownej emisji pakietów Bonjour / zero-conf w sieci przez router lub inne urządzenie)?
- Może być buforowany przez
mDNSResponderlub mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)
Rozwiązanie (symbol zastępczy)
Na dzień 6 października 2017 r. Nadal nie ma pełnego rozwiązania ze strony Apple ani rozwiązania, które zapobiegałoby ponownemu wystąpieniu tego problemu. Polecam złożenie raportu o błędach w Apple opisującego ten problem. Możesz również skontaktować się z obsługą klienta Apple .
Im więcej osób będzie hałasować z powodu tego irytującego problemu, tym szybciej menedżerowie produktów Apple będą traktować priorytetowo, aby inżynierowie mogli to naprawić.
Debugowanie / Przyszłe linie dochodzenia
Ta dyskusja na forum MacRumors zawiera kilka użytecznych informacji, a także dodanie teorii, że Wake for Wi-Fi Network Accessi urządzenie Wake / Sleep ma coś wspólnego z tym problemem. Inne przedstawione teorie dotyczą używania wielu kart sieciowych (np .: WiFi + Thunderbolt Ethernet), routerów z wieloma punktami dostępu reklamowanymi w wielu pasmach, takich jak 802.11 b/g/n(2,4 GHz) lub 802.11 a/ac(5 GHz ). Te kombinacje mogą spowodować, że „widmowa” wersja urządzenia Apple pojawi się w sieci w jakiś sposób tymczasowo, powodując zachowanie zmiany nazwy.
Nie było żadnych użytecznych wiersze dziennika w /var/log/system.logktóry pojawił związane z tym zachowanie zmiana nazwy jest wyzwalany. Podobno mDNSRespondermożna go skonfigurować na wyższe poziomy dziennika:
- Błąd - komunikaty o błędach
- Ostrzeżenie - operacje inicjowane przez klienta
- Uwaga - Operacje proxy uśpienia
- Informacje - wiadomości informacyjne
Sposób ustawienia tych poziomów debugowania innych niż być może przez nieistniejący plik /Library/Preferences/com.apple.mDNSResponder.plistnie był jasny. Nie miałem do użycia przykładowej konfiguracji plist, więc nie mogłem uzyskać żadnych dodatkowych informacji logowania mDNSResponder.
Narzędzia takie jak Wireshark mogą być przydatne do pokazywania mDNSpakietów transmitowanych w sieci wraz z innymi potencjalnie istotnymi informacjami o pakietach ARP między innymi ruchem.
W systemie Mac OS dscacheutilmogą być dostępne inne narzędzia do wyświetlania tych informacji. Nie jest dobrze udokumentowane ani jasne, jak wyświetlić ostateczną pamięć podręczną tych informacji, które są używane przez kod zmiany nazwy hosta. Kiedy przetestowałem to narzędzie, nie wygenerowało ono żadnych użytecznych danych wyjściowych, z wyjątkiem trybu zapytania o dokładną nazwę hosta (adresy IP oczyszczone w celu zachowania prywatności):
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