ich habe das Problem noch etwas weiter untersucht:
Bei einem Domänenbenutzer erfolgt wie gesagt KEINE Wiederherstellung der Netzwerkverbindung nach Wiedereinstecken des Netzwerkkabels.
Beim LINUXADMIN und bei meinem lokalen Benutzer KEINNETZ, der eine Profilkopie vom Linuxadmin beim Anmelden erhält, FUNKTIONIERT die Wiederherstellung der Netzwerkverbindung nach Wiedereinstecken des Netzwerkkabels.
Könnte Hilfe brauchen, was ich untersuchen könnte.
im Dezember 2015 schrieb Dominik in der damaligen Mailingliste das unten
angehängte.
Ich hatte das selbe Problem: so hab ich es gelößt.
Tut mir Leid, dass ich jetzt 4 Tage gebraucht habe, um das endlich raus
zu suchen.
LG
Holger
ich habe dieses Problem nicht!? …oder nicht mehr!
Habe es gerade heute nochmal mit Schüler- und Lehreraccount geprüft; es
dauert zwar nach Reaktivierung des Netzwerks ca. 10-15 sec aber dann ist
die Verbindung wieder da…das klappt reproduzierbar und zuverlässig!
Das von euch beschriebene Problem hatte ich so ähnlich bei meinen
Standalone-Laptops (mit Trusty-image drauf) und der
WLAN-Verbindung…die wollten sich einfach nicht zuverlässig über den
Networkmanager verbinden lassen…nach langer Recherche konnte ich das
Problem in der Schlüsselverwaltung von Ubuntu finden…folgendes hat
dann die Sache beseitigt:
Ich habe in Seahorse (Passwort- und Schlüsselverwaltung) bei “Login” ein
leeres Passwort gesetzt. Standardmäßig ist da das Passwort vom
linuxadmin vergeben…dann durften eben alle Benutzer auf alle Netzwerk-
credentials und Einstellungen zugreifen (mir ist immer noch nicht klar
welche das genau wo sein sollen aber so stand es in irgendeiner
Mailingliste…)
…lange Rede kurzer Sinn…vielleicht habe ich ja deswegen das Problem
auch nicht bei LAN-Verbindungen
Danke für den Tipp. Leider hat es nichts geändert.
Zuerst hat das setzen des leeres Passworts als linuxadmin nicht so funktioniert:
“seahorse” kann ich über das Terminal starten.
Ich habe als linuxadmin mit dem linuxadmin-Passwort ein leeres Kennwort gesetzt unter Passwörter-Anmeldung…
… und mich dann als Domänenbenutzer angemeldet und “seahorse” über das Terminal gestartet um das Passwort zu kontrollieren. Es ist nun das Passwort des Domänenbenutzers nötig!
Daraufhin habe ich mich abgemeldet und wieder als linuxadmin “seahorse” über das Terminal gestartet um das Passwort zu kontrollieren. Es ist nun das Passwort des linuxadmin nötig!
Es scheint also so, dass das Passwort beim Anmelden wieder zurückgesetzt wird.
Aber um es einmal als Domänenbenutzer durch zuspielen:
Anmelden als Domänenbenutzer, das passwort in seahorse leeren, Netzwerkkabel ziehen, Benachrichtigung abwarten, Netzwerkkabel wieder einstecken… nix passiert.
Und unter dem grafischen Tool Netzwerkverbindungen wird keine Verbindung mehr angezeigt.
ich habe weitere Test gemacht und folgendes heraus gefunden:
Wenn ich als Domänenbenutzer, welcher sudo-Rechte erhalten kann (weil in Projektgruppe p_sudo)
mir ein Terminal öffne und mit sudo -i Superuser-Rechte sichere (*)
das Netzwerkkabel ziehe
Benachrichtigung abwarte
den NetzwerkManager beende mit sudo pkill NetworkManager
sich dieser automatisch neu startet
Benachrichtigung abwarte
das Netzwerkkabel wieder einstecke
verbindet sich der Rechner wieder mit dem Netzwerk! Und nach weiteren Netzwerktrennungen klappt das Wiederverbinden auch ohne Neustart des NetzwerkManagers.
Auch, wenn der Domänenbenutzer abgemeldet und wieder angemeldet wird, funktioniert das Wiederverbinden problemlos. (Bei uns werden die Reste des lokale Home eines Domänenbenutzers bei der Abmeldung gelöscht.)
Selbst bei einem andern Domänenbenutzer funktioniert nun das Wiederverbinden problemlos!?
Nach einem ungesyncten Neustart funktioniert das problemlose Wiederverbinden aber nicht mehr.
Eine fertige Lösung ist das ja noch nicht, aber vielleicht nahe dran.
Vielleicht hat jemand eine Idee?
Gruß
Stefan
(*) Das muss ich vor dem Trennen der Netzwerkverbindung tun, weil sonst das Passwort nicht akzeptiert wird bei sudo -i !?
Hier noch einige syslog-Dateien zum Vergleichen.
Im Syslog werden ständig folgende 2 Zeilen wiederholt, was aber mit dem Problem wohl nichts zu tun hat:
Jan 30 18:23:59 adm-p01iii kernel: [ 178.152025] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
Jan 30 18:23:59 adm-p01iii kernel: [ 178.152034] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
Syslog beim ersten Netzwerkkabelziehen: disonnect.txt (3,2 KB)
Syslog beim ersten Wiederverbinden - ohne Erfolg: reconnect1.txt (6,8 KB)
Syslog beim zweiten Netzwerkkabelziehen: disonnect2.txt (552 Bytes)
Syslog beim zweiten Wiederverbinden - ohne Erfolg: reconnect2.txt (592 Bytes)
Syslog beim dritten Wiederverbinden - mit Erfolg - nach Neustart des NetzwerkManagers: reconnect.txt (8,4 KB)
Beim Vergleich von 1. Syslog beim ersten Wiederverbinden - ohne Erfolg
mit 3. Syslog beim dritten Wiederverbinden - mit Erfolg - nach Neustart des NetzwerkManagers
fällt mir ein DHCP-Problem auf:
Während bei diese Fehlermeldung bei 1. auftaucht: CIFS VFS: Server 10.16.1.1 has not responded in 120 seconds. Reconnecting…
vermisse ich bei 1. folgende Einträge, die bei 3. zu finden sind: NetworkManager[5960]: (eth0): DHCPv4 state changed nbi -> preinit dhclient: DHCPOFFER of 10.16.11.1 from 10.16.1.1 NetworkManager[5960]: (eth0): DHCPv4 state changed preinit -> bound
ich habe nun die Datei /etc/network/interfaces , welche folgenden Inhalt besaß
auto lo
iface lo inet loopback
um diese zwei Zeilen erweitert:
auto eth0
iface eth0 inet dhcp
Nun wird die Netzwerkverbindung von eth0 nicht mehr vom nm-applet verwaltet und beim Ziehen des Netzwerkkabels kommt im syslog nur noch die Meldung “NIC Link is Down”, beim Wiederverbinden “NIC Link is Up 1000Mbs Full Duplex…” und “NetworkManager Unmanaged Device found; state CONNECTED forced”
Jetzt kann man das Netzwerkkabel für einige Minuten ausstecken und bekommt danach sofort wieder den Zugriff z.B. auf das Home_auf_Server.
Danke Holger für den Support!
Gruß Stefan
P.S: Außerdem habe ich in den Netzwerkverbindungen IPv6 auf ignorieren gestellt. (Das hatte als alleinige Maßnahme keinen Effekt bzgl. des Problems.)
