[gelöst] Rechner wird nicht über Hostname im Netz gefunden

[TomL]

Moin @ all

Was könnte es für weitere Ursachen haben, die dafür sorgen, dass mein Laptop nicht mehr über seinen Namen im Netz gefunden wird. Das folgende habe ich bereits alles geprüft:

Auf dem Laptop:
1. systemd-networkd = status fehlerfrei
2. systemd-resolved = status fehlerfrei
3. avahi-daemon = status fehlerfrei
4. Netzwerkverbindung an sich = fehlerfrei
5. avahi lauscht lt netstat planmäßig auf Port 5353
6. iptables sind deaktiviert
7. der nameserver in der resolv.conf ist korrekt
8. vom Laptop ausgehend funktioniert die Namensauflösung (beides: wan und lan) einwandfrei
9. ip a = eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>

Von meinem PC:
1. ip n und arp n finden die aktuelle IP (10.10.1.48) des Laptops
2. host 10.10.1.48 zeigt mir den hostnamen des laptops: dell-e6320 plus ".fritz.box"
3. ssh dell-e6320 = erfolgreich (wird via IPv4 verbunden)
4. ping 10.10.1.48 = erfolgreich
5. ping dell-e6320 = Destination Host Unreachable
6. vncviewer dell-e6320:99999 = No route to host

ssh geht, ping und vncviewer gehen nicht. Anfangs dachte ich, die Ursache wäre, weil ich das Netzwerk nicht mehr via systemd-netword gestartet habe, sondern kurzerhand über eine Service-Unit. Ich hatte also diese Service-Uni in Verdachtt. Aber nachdem ich jetzt wieder das Netz wie zuvor starte, finde ich den Laptop immer noch nicht via Hostname.

Was könnte noch eine Ursache sein? Im Netz kann ich dazu nix mehr zu finden.... 99% der Funde behandeln das aus Sicht des Hosts und dessen fehlende Namensauflösung.... aber das funktioniert ja tadellos.

Das war beispielsweise die kurze Service-Unit, mit der ich vorübergehend das Netzwerk gestartet habe... so spielend einfach, dass ich das künftig für alle unsere Kabel-PC nutzen wollte. Aber die scheint wohl auch nicht die Problemquelle zu sein:

Code: Alles auswählen

[Unit]
Description=Start network connectivity (Interface=eth0)
After=basic.target
Before=network.target shutdown.target
Wants=network.target
Conflicts=shutdown.target

[Service]
Type=simple
RemainAfterExit=yes

ExecStartPre=/sbin/ip link set dev eth0 up
ExecStart=/sbin/dhclient eth0
ExecStop=/sbin/dhclient -r eth0
ExecStopPost=/sbin/ip link set dev eth0 down

[Install]
WantedBy=multi-user.target

Hat jemand noch ne andere Idee?

[mat6937]

..., ping und vncviewer gehen nicht.

Poste mal die Ausgabe von:

Code: Alles auswählen

cat /etc/nsswitch.conf | grep -i resolve

[rendegast]

2. host 10.10.1.48 zeigt mir den hostnamen des laptops: dell-e6320 plus ".fritz.box"
3. ssh dell-e6320 = erfolgreich (wird via IPv4 verbunden)

Dann wird
host dell-e6320.fritz.box
host dell-e6320
auch funktionieren?

5. ping dell-e6320 = Destination Host Unreachable

ping ermittelt die IP wohl anders als 'host'.

strace -f:
'host' + 'ssh' machen sendmsg resp. sendmmsg
'ping' macht sendto

[Lord_Carlos]

Geht ping dell-e6320.local?
Ich vermute das bei mir im Netzwerk es ohne .local nur geht wenn mein Windows Rechner an ist. Kann sein das ich mir das einbilde.

[mat6937]

.... im Netzwerk es ohne .local nur geht wenn mein Windows Rechner an ist. Kann sein das ich mir das einbilde.

Nein, das muss nicht an deiner Einbildung liegen. Möglich wäre so etwas schon, ... z. B. wegen avahi oder NetBIOS oder ...
Wie ist auf deinem Linux Rechner, die Ausgabe von:

Code: Alles auswählen

cat /etc/nsswitch.conf

?

[Lord_Carlos]

Nichts veraendert. 39724

[mat6937]

Nichts veraendert.

OK, dann teste mal ohne die Zeile 5 (d. h. kommentiert) und mit neuer Zeile 6 in dieser Datei. Z. B.:

Code: Alles auswählen

# hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
hosts:          files dns

[TomL]

Moin @ all

Dank eurer Hinweise habe ich das Problem erkannt, aber ich weiss es nicht zu lösen ...

Der Laptop ist jetzt mit Patchkabel via eth0 angeschlossen:

Code: Alles auswählen

ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 55:25:05:65:d5:55 brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.48/24 brd 10.10.1.255 scope global eth0

Die IP 48 ist jetzt die aktuelle, die hier folgende angezeigte IP 51 war die, die er zuletzt via WLAN-NIC erhalten hat und die jetzt natürlich noch in der FritzBox (nicht verbunden) gelistet wird

Das sind die Ausgaben, mit denen man das Problem erkennen kann:

Code: Alles auswählen

$ host dell-e6320.fritz.box
dell-e6320.fritz.box has address 10.10.1.51
dell-e6320.fritz.box has address 10.10.1.48

$ host dell-e6320
dell-e6320 has address 10.10.1.51
dell-e6320 has address 10.10.1.48

$ ping dell-e6320.local
ping: unknown host dell-e6320.local

$ ping dell-e6320
PING dell-e6320 (10.10.1.51) 56(84) bytes of data.
From thomaspc.fritz.box (10.10.1.41) icmp_seq=1 Destination Host Unreachable

Sowohl ping als anscheinend auch vncviewer versuchen es über die (WLAN-) IP 51, die derzeit aber nicht verbunden ist. Die nsswitch.conf hab ich auch mal wie vorgeschlagen geändert, ohne Auswirkung. Möglicherweise -so kommt es mir gerade in den Sinn- ist es auch ein vom Router verursachtes Problem.

[mat6937]

Sowohl ping als anscheinend auch vncviewer versuchen es über die (WLAN-) IP 51, die derzeit aber nicht verbunden ist. Die nsswitch.conf hab ich auch mal wie vorgeschlagen geändert, ohne Auswirkung. Möglicherweise -so kommt es mir gerade in den Sinn- ist es auch ein vom Router verursachtes Problem.

Versuch mal mit nsupdate (oder gleichwertig) den z. Zt. unerwünschten A-record für die IP 51 in der FritzBox zu löschen und teste, was ping danach macht.

EDIT:

Für dich gab es doch noch gar keinen Vorschlag, die nsswitch.conf zu ändern. BTW: Was hast Du an deinem 1. Beitrag geändert?

[TomL]

Versuch mal mit nsupdate (oder gleichwertig)

Tja... das ist leider alles nicht so einfach. Mein Debian ist zwar noch ein Standard-Debian, aber eben weitestgehend ohne Standard-Desktop-Environment-Werkzeuge. Das heisst, bei mir ist der ganze typische dem DE beigelegte Overhead nicht installiert. Ich verzichte weitestgehend auf alle Dienste und Programme, die nicht fürs Funktionieren notwendig sind. Selbst das Netzwerk wird mehr oder weniger "unmittelbar" (s.o.) gestartet, ohne Networkmanager und so'n überflüssiges Zeug. Und bisher gabs ja da auch keine Probleme.

Aber ich glaube, ich habe den Verursacher entdeckt. Nach Deinem Hinweis habe ich in der Fritte den Laptop mit beiden IPs komplett gelöscht und die Wifi-MAC als "bekanntes Gerät" neu eingerichtet und somit erlaubt. Und hurra, der Laptop ist wieder mit Namen erreichbar. Aber jetzt die Überraschung, die möglicherweise für das Problem verantwortlich war... auf einmal listet die Fritzbox das WLAN-NIC wieder als 5Ghz-Nic... "häh???" war ich einigermaßen verblüfft... da stand doch gerade vor dem Löschen noch 2,4 Ghz. Jetzt vermute ich, dass das die Ursache war. Vielleicht klappte das deshalb nicht, weil Band und Name schlichtweg nicht übereinstimmten bzw. nicht zueinander passten.

Für dich gab es doch noch gar keinen Vorschlag, die nsswitch.conf zu ändern. BTW: Was hast Du an deinem 1. Beitrag geändert?

*lacht* .... nee, ich weiss, aber in meiner Not dachte ich mir, wenns dem einen vielleicht hilft, dann mir auch.... und mal testen schadet nicht. Ich habe da schon drüber nachgedacht, habe mir das genau angesehen und bin dann zu dem Schluss gekommen, dass mehr Parameter ganz sicher mehr Möglichkeiten eröffnen können. Aber andersrum ist es auch möglich, das weniger Parameter sich vielleicht auch weniger einschränkend auswirken können. Aber weils ohne Wirkung war, habe ich das wieder rückgängig gemacht. Ein Versuch wars jedenfalls wert.

BTW: Was hast Du an deinem 1. Beitrag geändert?

Die Service-Unit... ich hatte zuvor irrtümlich die falsche kopiert, eine die Probleme verursacht hätte.

Danke für Eure Ratschläge, die mir dabei geholfen haben, das Problem erst mal zu lösen.

[mat6937]

Tja... das ist leider alles nicht so einfach. Mein Debian ist zwar noch ein Standard-Debian, aber eben weitestgehend ohne Standard-Desktop-Environment-Werkzeuge. ...

OK, aber nsupdate (mit dig und nslookup) ist im package dnsutils und dafür braucht man kein Desktop-Environment. Und btw. nützlich ist dieses package auch auf reinen Servern.

Aber jetzt die Überraschung, die möglicherweise für das Problem verantwortlich war... auf einmal listet die Fritzbox das WLAN-NIC wieder als 5Ghz-Nic... "häh???" war ich einigermaßen verblüfft... da stand doch gerade vor dem Löschen noch 2,4 Ghz. Jetzt vermute ich, dass das die Ursache war.

Solche Probleme können auftreten, wenn der WLAN-Client (wpa_supplicant) nicht "richtig"/ausreichend konfiguriert ist und es zu einem "Roaming" zwischen dem 2,4GHz und 5GHz kommen kann, ... evtl. auch durch eine "nicht ganz fehlerfreie/perfekte" Firmware des WLAN-Routers (hier eine FritzBox) begünstigt/ermöglicht/erlaubt.

[TomL]

OK, aber nsupdate (mit dig und nslookup) ist im package dnsutils und dafür braucht man kein Desktop-Environment. Und btw. nützlich ist dieses package auch auf reinen Servern.

"dnsutils" hatte ich gestern abend auch im Web gefunden, als Paket mit diversen Tools. Die Sache ist nur die, dass ich das bisher noch nie gebraucht habe. Und der nächste Aspekt ist, dass mir schlichtweg weitere technische Probeme fehlen, die ich mit diesen Tools lösen müsste oder könnte, oder wo ich mich mit deren Funktionen vertraut machen könnte oder wo ich darüber den Sinn einer Installation bestätigen könnte. Was mein Debian angeht...*hmmm*... es läuft einfach.... und auch jetzt wars wohl eine außerhalb von Debian liegende Ursache.

Solche Probleme können auftreten, wenn der WLAN-Client (wpa_supplicant) nicht "richtig"/ausreichend konfiguriert ist und es zu einem "Roaming" zwischen dem 2,4GHz und 5GHz kommen kann, ... evtl. auch durch eine "nicht ganz fehlerfreie/perfekte" Firmware des WLAN-Routers (hier eine FritzBox) begünstigt/ermöglicht/erlaubt.

Hast Du eine Idee, was ich da tun müsste, um vielleicht solchen Problemen vorzubeugen? Das die wpa-supplicant.conf nicht komplett durchkonfiguriert ist, will ich nicht ausschließen. Bislang war für mich bei WLAN-Verbindungen "es läuft" der Marker für ausreichend konfiguriert.

[TomL]

Die obige service-unit zum Start des Netzwerks war anfangs nur ein Schnellschuss, ein Test, wie weit man auf den Standardkram verzichten kann und ob das überhaupt funktioniert. Und weil das richtig gut geht, habe ich die Unit jetzt noch mal überarbeitet, in der Form, das ich meine, so ist es richtig. Ich habe die Unit oben noch mal ausgetauscht.... für unsere Kabel-PCs ist das zu Networkmanager, systemd-networkd oder /etc/networking ein echte Alternative..... kürzer und prägnanter und mit noch weniger Ballast gehts wirklich nicht mehr. Und das beste ist, es funktioniert

[mat6937]

Hast Du eine Idee, was ich da tun müsste, um vielleicht solchen Problemen vorzubeugen? Das die wpa-supplicant.conf nicht komplett durchkonfiguriert ist, will ich nicht ausschließen. Bislang war für mich bei WLAN-Verbindungen "es läuft" der Marker für ausreichend konfiguriert.

Du kannst im network-Block der wpa_supplicant.conf, z. B. die zu berücksichtigende Frequenz/Kanal konfigurieren:

Code: Alles auswählen

frequency=2437
scan_freq=2437
freq_list=2437

(ein Beispiel mit Kanal 6).

Wenn Du das roaming komplett verbannen/deaktivieren willst, dann könntest Du den wpa_supplicant mit folgender Option kompilieren:

Code: Alles auswählen

# Disable roaming in wpa_supplicant
CONFIG_NO_ROAMING=y

[TomL]

Jetzt bin ich noch mehr irritiert als zuvor Weil ich momentan überhaupt nicht mehr den Zusammenhang mit dem Problem verstehe. Soweit ich das verstanden habe, wechselt doch meist die Fritzbox automatisch zu einem in der Umgebung eher gering frequentierten Kanal. Und irgendwie stimmen sich Client und AP darauf ab, ob sie 2,4 oder 5 Ghz verwenden ... kein Ahnung nach welchen Kriterien. Also läuft der ganze Connect ziemlich dynamisch ab. Würde ich das nicht genau aushebeln, wenn ich das auf einen festen Kanal fixiere? Mit ist auch nicht klar, welchen Einfluss die Frequenz auf die IP-Vergabe bzw. der Hostname-Bekanntgabe zu tun haben könnte. Die Leitung zu "ziehen" ist doch eine Sache, die Verbindung über die Leitung logisch zu etablieren imho eine ganz andere.

Und der Zusammenhang zum Roaming ist mir auch völlig unklar. Ich habe ja hier nur ein einziges Netz.... eben meinen eigenen AP... und dementsprechend auch eine Unique-wpasupplicant.conf für genau diesen AP. Vor dem Hintergrund ist doch Roaming eh nicht möglich. Wie kann das Einfluss auf den nicht gefundenen Hostnamen haben?

Du kannst im network-Block der wpa_supplicant.conf, z. B. die zu berücksichtigende Frequenz/Kanal konfigurieren:
::::::
Wenn Du das roaming komplett verbannen/deaktivieren willst, dann könntest Du den wpa_supplicant mit folgender Option kompilieren:

[mat6937]

Soweit ich das verstanden habe, wechselt doch meist die Fritzbox automatisch zu einem in der Umgebung eher gering frequentierten Kanal.

Naja, das ist eine Frage der Konfiguration. Bei meiner FritzBox ist der Kanal 6 (2.4 GHz) fest konfiguriert und in den WLAN-Clients ist diese Frequenz/Kanal auch fest konfiguriert.

Und irgendwie stimmen sich Client und AP darauf ab, ob sie 2,4 oder 5 Ghz verwenden ...

Ja, aber problematisch wird es, wenn Client und AP, zwischen 2,4 und 5 GHz hin- und herspringen.

Also läuft der ganze Connect ziemlich dynamisch ab. Würde ich das nicht genau aushebeln, wenn ich das auf einen festen Kanal fixiere?

Ja, aber das kann auch Vorteile haben.

Mit ist auch nicht klar, welchen Einfluss die Frequenz auf die IP-Vergabe bzw. der Hostname-Bekanntgabe zu tun haben könnte.

Nicht direkt, aber es geht um eine stabile/zuverlässige WLAN-Verbindung zwischen Client und AP.

Und der Zusammenhang zum Roaming ist mir auch völlig unklar. Ich habe ja hier nur ein einziges Netz....

Naja, es geht nicht um das klassische Roaming mit mehreren APs/Repeater. Das hin und her wechseln von 2.4 zu 5 GHz ist auch ein Roaming.

Aber OK, wenn es bei dir mit der aktuellen Konfiguration, zu deiner Zufriedenheit funktioniert, musst Du nichts ändern.

[rendegast]

Das wlan-Zeug hat auf IP keinen Einfluß,
ein eth-kabel ja auch nicht.

[scientific]

Ich frag mich immer, warum der NetworkManager im Einsatzgebiet mit wechselnden LAN/WLAN-Verbindungen unnütz sein soll... Genau dafür wurde er gemacht, und das kann er gut...

[TomL]

Ich frag mich immer, warum der NetworkManager im Einsatzgebiet mit wechselnden LAN/WLAN-Verbindungen unnütz sein soll... Genau dafür wurde er gemacht, und das kann er gut...

Eigentlich wäre er genau vor diesem Hintergrund nicht unnütz... wenn er denn nicht häufig für Probleme bei Remote-Mounts sorgen würde.... und zwar in dem er die WLAN-Verbindung kappt, bevor unmounted wurde - was dann in der Folge zu diesen nervigen 90-Stop-Jobs geführt hat. Das Problem hatte ich ständig und es war zuverlässig reproduzierbar. Das Problem ist m.M.n., dass er sich wie zu Zeiten sysvinit als Herr des Netzwerkes aufspielt. Aber das funktioniert m.E. nicht mehr unter dem Umstand "Parallelisierung von Boot und Shutdown-Prozessen". Er muss sich beim Kappen der Verbindung beim Shutdown an gewisse Regeln halten.... einfach wegkloppen geht nicht... und solange er das tut, ist er halt unnütz.

Wer jedoch keine Remote-Mounts nutzt, ist wahrscheinlich mit dem Network-Manager gut bedient. Wobei ich heute definitiv aber wicd vorziehen würde. Da weiss ich, dass es auch funktioniert, wenn ich ihn und das GUI erst bei Bedarf manuell starte und das ich ansonsten im Regelbetrieb auf den Daemon verzichten kann. Und selbst Wicd ist für mich nur eine Notlösung, da ich heute fast alles mit einem eigenen kleinen Network-Manager mache, ein einfaches Dialog-Bash-Programm, welches in aktueller Version sogar die Netzwerkverbindung bei Systemstart (kurz via service-unit gestartet, ohne ein Daemon zu sein) zuverlässig herstellt.