[Gelöst] Linux-Rechner zerhackt mein Netzwerk

[PeteMaravich]

netstat -ulpen ergibt:

udp 0 0 224.0.0.56:9875 0.0.0.0:* 1000 23806 1329/pulseaudio
udp 0 0 239.255.255.250:1900 0.0.0.0:* 1000 606506 9513/dleyna-server-
udp 0 0 192.168.1.2:1900 0.0.0.0:* 1000 606505 9513/dleyna-server-
udp 0 0 239.255.255.250:1900 0.0.0.0:* 1000 606501 9513/dleyna-server-
udp 0 0 127.0.0.1:1900 0.0.0.0:* 1000 606500 9513/dleyna-server-
udp 0 0 0.0.0.0:44181 0.0.0.0:* 105 14334 503/avahi-daemon: r
udp 0 0 127.0.0.1:37755 0.0.0.0:* 1000 606503 9513/dleyna-server-
udp 0 0 0.0.0.0:5353 0.0.0.0:* 105 14332 503/avahi-daemon: r
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 471624 8412/dhclient
udp 0 0 0.0.0.0:111 0.0.0.0:* 0 13596 443/rpcbind
udp 0 0 192.168.1.2:123 0.0.0.0:* 122 472054 710/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 0 19569 710/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 0 19565 710/ntpd
udp 0 0 192.168.1.2:32959 0.0.0.0:* 1000 606508 9513/dleyna-server-
udp 0 0 0.0.0.0:49523 0.0.0.0:* 1000 396563 1689/firefox-esr
udp 0 0 0.0.0.0:619 0.0.0.0:* 0 13597 443/rpcbind
udp 0 0 0.0.0.0:631 0.0.0.0:* 0 246558 6182/cups-browsed
udp6 0 0 :::52103 :::* 1000 396565 1689/firefox-esr
udp6 0 0 :::5353 :::* 105 14333 503/avahi-daemon: r
udp6 0 0 :::55559 :::* 105 14335 503/avahi-daemon: r
udp6 0 0 :::111 :::* 0 13599 443/rpcbind
udp6 0 0 ::1:123 :::* 0 19571 710/ntpd
udp6 0 0 :::123 :::* 0 18836 710/ntpd
udp6 0 0 :::619 :::* 0 13600 443/rpcbind

[PeteMaravich]

Und außerdem wäre endlich interessant, was mit dem "Problemkind" (Rechner B / Windows) durch die LAN-Verbindung des angeblich "zerhackenden" Linux-Rechners A passiert:

Rechner B (Windows) könnte mal mit einer Linux-Live-ISO und WLAN gebootet werden. Dann das Übliche (ifconfig -a, iwconfig, iw dev <Interface> scan, evtl. journalctl -f und alle Kommandos mit Ab- und Anstecken des Rechners A/Linux). Eine Beschreibung der aktuellen Konstellation (Kabelverbindung A) gehört unbedingt zu eventuell geposteten Ausgaben.

Windows selbst bietet eigene Diagnose-Möglichkeiten (wiederum nur sinnvoll im Vergleich ab- und angesteckter Linux-Rechner):
ipconfig /all
ipconfig /release
ipconfig /renew
route print
nslookup
netstat
Fällt das WLAN des Routers komplett aus (kein Empfang, keine Feldstärkeanzeige in Windows) oder nur Authentifizierung -> Widows-Ereignisanzeige/-protokoll?
Neuverbindung möglich?
Was reagiert ein Smartphone bei Verbindungsübersicht, was zeigt Android-App "WiFi Analyzer"? Oder das Windows-Programm Inssider? WLAN/SSID des Routers wirklich ausgefallen? Sehr unwahrscheinlich durch Clients.
Evtl. nur DNS-Problem? ping 8.8.8.8 vs. ping google.de
ping auf Gateway möglich?

Sehr dünne Angaben/Mitwirkung bisher! Dürfte die 3. Mahnung im Thread sein ....

Das Augenrollen kannst du dir sparen.

1. Ich habe das Problem exakt beschrieben. Warum also die Frage nach der "Feldstärkenanzeige"? Der Empfang ist super. Ich habe schon Tage vor der Eröffnung dieses Gesprächsfadens analysiert, mir extra einen WiFi-Analyzer für Android runtergeladen.
2. Mein Problem ist derart allgemein, dass ich nicht weiß, welche Log-Files ich denn posten möge. Ich erwähnte ja nicht umsonst, dass das Problem mit dem Upgrade auf Debian Stretch begann. Mein Vermutung ist, dass da irgendein Dienst hinzugekommen ist, der mir jetzt alles zerschießt.
3. Es steht hier niemanden zu, Mahnungen zu erteilen.
4. Wegen der "dünnen Mitwirkung": Ich habe auch noch andere Dinge zu tun, als tagtäglich hier ins Forum zu schauen. Tut mir wirklich leid.
5. Eine weitere Sache ist, dass die Android-Geräte keine gescheiten Log-Dateien produzieren. (Habe ich auch schon erwähnt.) Die Log-Dateien auf dem Router sind auch nichtssagend.

ping 8.8.8.8 und ping google.de funktionieren gleichermaßen.

Die Hinweise, mal den Windows-Rechner anzuwerfen und die genannten Befehle ausführen, werde ich aber ausführen.

[PeteMaravich]

route print auf Windows-Rechner ergibt:

===========================================================================
Schnittstellenliste
23...00 ff f2 d1 25 07 ......TAP-Windows Adapter V9
14...b0 05 94 ef af d7 ......Bluetooth-Gerät (PAN)
13...70 18 8b 12 d1 f6 ......Dell Wireless 1504 802.11b/g/n (2.4GHz)
12...f0 1f af 30 45 d2 ......Intel(R) 82579LM Gigabit Network Connection
1...........................Software Loopback Interface 1
11...00 00 00 00 00 00 00 e0 Microsoft-Teredo-Tunneling-Adapter
42...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #6
22...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #7
25...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #8
26...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #9
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.6 20
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
192.168.1.0 255.255.255.0 Auf Verbindung 192.168.1.6 276
192.168.1.6 255.255.255.255 Auf Verbindung 192.168.1.6 276
192.168.1.255 255.255.255.255 Auf Verbindung 192.168.1.6 276
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.1.6 276
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.1.6 276
===========================================================================
Ständige Routen:
Keine

IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 306 ::1/128 Auf Verbindung
1 306 ff00::/8 Auf Verbindung
===========================================================================
Ständige Routen:
Keine

Linux- und Windows-Rechner können sich gegenseitig anpingen.

Versuche ich es mit dem Windows-Rechner über WLAN ins Netz zu kommen, bekomme ich folgende Fehlermeldung in der Ereignisanzeige:

- EventData

InterfaceGuid {80F44B6F-F172-49EE-8A19-C1DF7B87B603}
InterfaceDescription Dell Wireless 1504 802.11b/g/n (2.4GHz)
ConnectionMode Automatische Verbindung mit einem Profil
ProfileName WLAN_PETEMARAVICH
SSID WLAN_PETEMARAVICH
BSSType Infrastructure
FailureReason Der dynamische Schlüsselaustausch wurde nicht innerhalb der konfigurierten Zeit erfolgreich abgeschlossen.
ReasonCode 294917
ConnectionId 0x16

[mat6937]

Code: Alles auswählen

  FailureReason Der dynamische Schlüsselaustausch wurde nicht innerhalb der konfigurierten Zeit erfolgreich abgeschlossen. 
  ReasonCode 294917 
  ConnectionId 0x16 

Hast Du evtl. noch einen 2. Linux-PC (oder gleichwertig) mit wlan-Interface? Wenn ja, dann versuch mal (... wenn der 1. Linux-PC per Kabel angeschlossen ist) mit:

Code: Alles auswählen

iwlist <wlan-Interface> scan

festzustellen ob dein WLAN-Router als AP angezeigt wird.

Versuch mal temporär bzw. als Test auf deinem 1. Linux-PC, wenn dieser per Kabel angeschlossen ist, Folgendes:

• IPv6 schon beim booten zu deaktivieren

• mit bereits deaktiviertem avahi-daemon zu starten

• für die Subnetze 224.0.0.0/8 und 239.0.0.0/8, abweisende Routen zu konfigurieren und mit dieser Konfiguration auch zu starten.

und danach testen, ob das WLAN deines Routers benutzt werden kann.

EDIT:

Besteht die Möglichkeit, deinen Linux-PC mit einem anderen WLAN-Router (anderer Hersteller) zu testen?

[killerbees19]

@PeteMaravich: Bitte verwende bei Terminalausgaben unbedingt [code]-Tags, dann bleiben die Leerzeichen erhalten. Dadurch sind viele Ausgaben deutlich besser lesbar, als es mit [quote] der Fall ist!

Ein zweiter DHCP-Server läuft jedenfalls nicht. Damit hätten wir das auch geklärt…


MfG Christian

[BenutzerGa4gooPh]

FailureReason Der dynamische Schlüsselaustausch wurde nicht innerhalb der konfigurierten Zeit erfolgreich abgeschlossen.

Rechner B (Windows) könnte mal mit einer Linux-Live-ISO und WLAN gebootet werden. Dann das Übliche (ifconfig -a, iwconfig, iw dev <Interface> scan, ...journalctl -f und alle Kommandos mit Ab- und Anstecken des Rechners A/Linux). Eine Beschreibung der aktuellen Konstellation (Kabelverbindung A) gehört unbedingt zu eventuell geposteten Ausgaben.

... zum 3. Mal.
(Wenn das funktioniert, ist es ein Windows-Problem. Wenn nicht haben wir weitere Logs.)

InterfaceDescription Dell Wireless 1504 802.11b/g/n (2.4GHz)

Mal im Router versuchsweise einstellen:
802.11g, 802.11n, g+n
WPA-TKIP (nach Tests auf WPA2-PSK AES-CCMP)
(Evtl. hat das Upgrade der WLAN-Treiber zu einer anderen/neueren Authentifizierung geführt.)

3. Es steht hier niemanden zu, Mahnungen zu erteilen.

Doch. Wenn Angaben trotz mehrfacher Nachfrage fehlen. Ich kann mich aber auch gern zurück halten, mein WLAN funktioniert bestens. Und ohne Log sind die anderen bald zur Zurückhaltung gezwungen oder stochern im Nebel.

Edit: Firmwareupdate des Routers oder/und Ruecksetzen auf Werkseinstellungen ratsam!

[mat6937]

(Evtl. hat das Upgrade der WLAN-Treiber zu einer anderen/neueren Authentifizierung geführt.)

Naja, er benutzt ja mit dem Gerät/OS für das das Upgrade gemacht worden ist, den WLAN-Treiber nicht bzw. das wlan-Interface ist ja auch down (... in der Ausgabe von ifconfig nicht sichtbar), wenn lediglich per Kabel mit dem Router verbunden.

[BenutzerGa4gooPh]

Naja, er benutzt ja mit dem Gerät/OS für das das Upgrade gemacht worden ist, den WLAN-Treiber nicht bzw. das wlan-Interface ist ja auch down ...

Hast Recht, Thread nicht nochmals gelesen
Aber die vorgeschlagenen Maßnahmen halte ich trotzdem für sinnvoll.

[mat6937]

Aber die vorgeschlagenen Maßnahmen halte ich trotzdem für sinnvoll.

Ja, das kann man machen, aber erst nach dem die Ursache geklärt/gefunden ist oder auch früher schon, wenn man nicht mehr wissen will oder evtl. auch nicht feststellen kann, was die Ursache für diese "Veränderung" ist.

[PeteMaravich]

Edit: Firmwareupdate des Routers oder/und Ruecksetzen auf Werkseinstellungen ratsam!

Habe ich schon vor zehn Tagen mal gemacht.

Aber mittlerweile funktioniert's. Beim Router den IP-Adressen einstellen, die er vergeben soll, von 192.168.1.X nach 192.168.1.Y.

X=1 reserviert er für sich selber
Das Pärchen X=2 bis Y=254 war voreingestellt. Ich habe es am Samstag probeweise das X auf 140 gestellt. Seitdem läuft's. Ich kann mir aber keinen Reim drauf machen. Ich werde aber auch noch X=3 ausprobieren. Ich kann mir vorstellen, dass 192.168.1.2 die Probleme verursacht hat.

[MSfree]

Das Pärchen X=2 bis Y=254 war voreingestellt. Ich habe es am Samstag probeweise das X auf 140 gestellt. Seitdem läuft's. Ich kann mir aber keinen Reim drauf machen. Ich werde aber auch noch X=3 ausprobieren. Ich kann mir vorstellen, dass 192.168.1.2 die Probleme verursacht hat.

Ich könnte mir vorstellen, daß irgendeiner deiner Rechner eine feste IP-Adresse konfiguriert hat, die dann mit dem DHCP-Server in Konflikt gerät. Durch das Einschränken des Adressbereiches im DHCP-Server hast du vermutlich genau die IP-Adresse von der dynamischen Adressvergabe ausgenommen.

Ich würde an deiner Stelle mal alle Rechner auf möglicherweise statisch konfigurierte IP-Adressen abklappern und dann diese entweder auf DHCP umstellen oder eben, wie du es ja bereits durch Versuch und Irrtum gemacht hast, von dem dynamischen Adressbereich ausnehmen.

[PeteMaravich]

Das Pärchen X=2 bis Y=254 war voreingestellt. Ich habe es am Samstag probeweise das X auf 140 gestellt. Seitdem läuft's. Ich kann mir aber keinen Reim drauf machen. Ich werde aber auch noch X=3 ausprobieren. Ich kann mir vorstellen, dass 192.168.1.2 die Probleme verursacht hat.

Ich könnte mir vorstellen, daß irgendeiner deiner Rechner eine feste IP-Adresse konfiguriert hat, die dann mit dem DHCP-Server in Konflikt gerät. Durch das Einschränken des Adressbereiches im DHCP-Server hast du vermutlich genau die IP-Adresse von der dynamischen Adressvergabe ausgenommen.

Ich würde an deiner Stelle mal alle Rechner auf möglicherweise statisch konfigurierte IP-Adressen abklappern und dann diese entweder auf DHCP umstellen oder eben, wie du es ja bereits durch Versuch und Irrtum gemacht hast, von dem dynamischen Adressbereich ausnehmen.

Ja, das habe ich auch schon geprüft. Das einzige Gerät, was ich mal bewusst mit einer statitischen IP-Adresse versehen habe, war mein Drucker. Der aber hängt nicht mehr Netz. Ich nutze den aber seit einem halben Jahr über die USB-Schnittstelle. Außerdem ist er die meiste Zeit abgeschaltet.

Ich habe mal nach der 192.168.1.2 gegreppt:

Code: Alles auswählen

cd /etc
grep "192.168.1.2" **/* 

Und auch tatsächlich zwei Einträge gefunden:

ppp/options:# ms-dns 192.168.1.2
sane.d/kodakaio.conf:#net 192.168.1.2 0x4041

Aber in beiden Fällen auskommentiert.

Ein weiteres Gerät, was mir immer dann Kummer bereitet, wenn ich konfigurieren muss, ist der Hama WLAN 2-in-1-Adapter (https://de.hama.com/webresources/articl ... _en_fr.pdf) Das Ding ist grauslich in der Bedienung, funktioniert. Aber selbst wenn dieses Gerät abgeknippst war, funktionierte das WLAN für Tablett und Smartphone nicht, sofern der Linux-Rechner angeschlossen war.

Eigentlich ist alles auf DHCP eingestellt. Ich werde aber weiter schauen, wenn ich wieder Zeit habe.

[mat6937]

Eigentlich ist alles auf DHCP eingestellt.

BTW: Zum Herstellen einer WLAN-Verbindung ist erstmal keine zugewiesene IP-Adresse erforderlich. Bei DHCP-Zuweisung wird ja auch erst nach dem Herstellen der _funktionierenden_ WLAN-Verbindung eine IP-Adresse per DHCP zugewiesen. Mit einem Rechner mit Linux (evtl. auch Live-CD oder -usb-Stick), kannst Du (als Test) z. B. manuell mit dem wpa_supplicant im debug-Modus, eine WLAN-Verbindung zum Router herstellen.

[BenutzerGa4gooPh]

Ich könnte mir vorstellen, daß irgendeiner deiner Rechner eine feste IP-Adresse konfiguriert hat, die dann mit dem DHCP-Server in Konflikt gerät. Durch das Einschränken des Adressbereiches im DHCP-Server hast du vermutlich genau die IP-Adresse von der dynamischen Adressvergabe ausgenommen.

Mein DHCP-Server (Router) pingt vorher die zu vergebende Adresse. Ist das nicht bei allen Routern/DHCPs der Fall? Wäre dann aber eine schlechte Implementierung des Protokolls. Mal gegoogelt und dazu gelernt:
ARP-Request clientseitig mit "sollte":

Bevor der Client sein Netzwerkinterface mit der zugewiesenen Adresse konfiguriert, sollte er noch prüfen, ob nicht versehentlich noch ein anderer Rechner die Adresse verwendet. Das geschieht üblicherweise durch einen ARP-Request mit der soeben zugeteilten IP-Adresse. Antwortet ein anderer Host im Netz auf diesen Request, so wird der Client die vorgeschlagene Adresse mit einer DHCPDECLINE-Nachricht zurückweisen.

https://de.m.wikipedia.org/wiki/Dynamic ... n_Protocol

Hier nennt einer Auszüge aus RFCs: https://networkengineering.stackexchang ... st-in-dhcp
(Beide Methoden mit "should" bzw. "may".)

@Peter: Mal sniffen (wireshark), ob eine der genannten Methoden greift.
Wobei DHCP erst nach WLAN-Authentifizierung erfolgen kann, wie mat6937 schon bemerkte. Und dort existiert schon ein Problem (Windows-Ereignisprotokoll).

[MSfree]

Mein DHCP-Server (Router) pingt vorher die zu vergebende Adresse. Ist das nicht bei allen Routern/DHCPs der Fall?

Der ISC-dhcpserver tut das, dnsmasq auch. Kann man aber wirklich sicher sein, daß das diese billigen 20-Euro-Router auch tun? Zumal hier so ein Hama-Dingens mit im Spiel ist.

Für mich riecht das ganze stark nach zwei gleichen IP-Adressen im selben Subnetz. Ob das nun durch manuelle Vergabe statischer IP-Adressen oder einer Überschneidung aus manuell gesetzter IP-Adresse und einer Zweitvergabe per DHCP, oder aber durch zwei konkurierende DHCP-Server im selben Subnetz passiert, gilt es noch herauszufinden.

[BenutzerGa4gooPh]

Kann man aber wirklich sicher sein, daß das diese billigen 20-Euro-Router auch tun? ...
Für mich riecht das ganze stark nach zwei gleichen IP-Adressen im selben Subnetz.

Die Windows-Firewall wird Methode 1 (Echo reply) verhindern. Dann sollte Windows jedoch Methode 2 (ARP request) durchführen.

[PeteMaravich]

Hallo, es gibt Neuigkeiten.

Nachdem meine Lösung (Änderung der IP-Range) nach zwei Tagen wieder scheiterte, habe ich noch einmal geschaut.

Was mir aufgefallen ist:

Es gibt zwei Verzeichnisse:

/var/lib/dhcp und /var/lib/NetworkManager

Beide enthalten sogenannte Lease-Dateien.

Code: Alles auswählen

root@js12:/var/lib/NetworkManager# ll
insgesamt 36
-rw-r--r-- 1 root root  742 Aug 15 13:15 dhclient-3756b051-07fe-31aa-8489-a19c5ffcc264-eth0.lease
-rw-r--r-- 1 root root   83 Aug 15 13:15 dhclient6-3756b051-07fe-31aa-8489-a19c5ffcc264-eth0.lease
-rw-r--r-- 1 root root   83 Aug 15 12:08 dhclient6-be462045-07e8-4505-bb05-9b5f797d8ac4-eth0.lease
-rw-r--r-- 1 root root  742 Aug 15 12:08 dhclient-be462045-07e8-4505-bb05-9b5f797d8ac4-eth0.lease
-rw-r--r-- 1 root root 2348 Aug 15 13:15 dhclient-eth0.conf
-rw-r--r-- 1 root root  939 Jun 30 00:07 NetworkManager-intern.conf
-rw-r--r-- 1 root root   68 Aug 15 13:15 NetworkManager.state
-rw------- 1 root root   32 Aug 15 12:20 secret_key
-rw-r--r-- 1 root root  157 Aug 15 13:15 timestamps

und:

Code: Alles auswählen

root@js12:/var/lib/dhcp$ ll
insgesamt 4
-rw-r--r-- 1 root root 371 Aug 15 12:31 dhclient.eth0.leases
-rw-r--r-- 1 root root   0 Dez 21  2015 dhclient.leases

Ich habe befolgt, was hier steht:

https://askubuntu.com/questions/151958/ ... dhcp-lease

Plötzlich ging es wieder. Plötzlich konnte ich mich wieder mit dem Tablett ins Netzwerk einklinken, während der Linux-Rechner an war.

Nach einem Systemneustart ging es aber nicht wieder. /var/lib/dhcp war leer. Unter welchen Umständen werden da lease-Dateien reingekloppt. Welcher Prozess macht sowas?

Der Network-Manager scheint irgendwie falsch konfiguriert zu sein. Ich plötztlich hatte ich auch zwei Konfigurationen:

Code: Alles auswählen

root@js12:/etc/NetworkManager/system-connections# ll
insgesamt 8
-rw------- 1 root root 357 Aug 15 13:45 Kabelgebundene Verbindung 1
-rw------- 1 root root 269 Aug 15 12:18 Wired connection 1

Meine NetworkManager.conf:

Code: Alles auswählen

[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false

Meine /etc/network/interfaces:

Code: Alles auswählen

auto lo
iface lo inet loopback

Ein bisschen aus der Syslog. Der Linux-Rechner hat die 192.168.1.146 erhalten.

Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1144] NetworkManager (version 1.6.2) is starting...
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1145] Read config: /etc/NetworkManager/NetworkManager.conf
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1187] manager[0x55dc8368b040]: monitoring kernel firmware directory '/lib/firmware'.
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1188] monitoring ifupdown state file '/run/network/ifstate'.
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1209] dns-mgr[0x55dc8367f180]: init: dns=default, rc-manager=resolvconf
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1472] init!
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1475] management mode: unmanaged
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1480] devices added (path: /sys/devices/pci0000:00/0000:00:06.0/0000:03:00.0/net/eth0, iface: eth0)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1480] device added (path: /sys/devices/pci0000:00/0000:00:06.0/0000:03:00.0/net/eth0, iface: eth0): no ifupdown configuration found.
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1480] devices added (path: /sys/devices/virtual/net/lo, iface: lo)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1480] device added (path: /sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration found.
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1480] end _init.
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1480] settings: loaded plugin ifupdown: (C) 2008 Canonical Ltd. To report bugs please use the NetworkManager mailing list. (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-settings-plugin-ifupdown.so)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1481] settings: loaded plugin keyfile: (c) 2007 - 2016 Red Hat, Inc. To report bugs please use the NetworkManager mailing list.
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1481] (-2090104256) ... get_connections.
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1481] (-2090104256) ... get_connections (managed=false): return empty list.
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.1482] get unmanaged devices count: 0
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3191] settings: hostname: using hostnamed
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3192] settings: hostname changed from (none) to "js12"
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3194] dhcp-init: Using DHCP client 'dhclient'
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3194] manager: WiFi enabled by radio killswitch; enabled by state file
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3194] manager: WWAN enabled by radio killswitch; enabled by state file
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3194] manager: Networking is enabled by state file
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3194] Loaded device plugin: NMBondDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMBridgeDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMEthernetDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMInfinibandDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMIPTunnelDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMMacsecDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMMacvlanDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMTunDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMVethDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3195] Loaded device plugin: NMVlanDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3196] Loaded device plugin: NMVxlanDeviceFactory (internal)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3200] Loaded device plugin: NMAtmManager (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-adsl.so)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3215] Loaded device plugin: NMBluezManager (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-bluetooth.so)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3225] Loaded device plugin: NMTeamFactory (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-team.so)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3227] Loaded device plugin: NMWwanFactory (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-wwan.so)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3269] Loaded device plugin: NMWifiFactory (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-wifi.so)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3281] device (lo): link connected
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3291] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/1)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3322] device (eth0): link connected
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3334] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3363] keyfile: add connection in-memory (3756b051-07fe-31aa-8489-a19c5ffcc264,"Kabelgebundene Verbindung 1")
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3371] settings: (eth0): created default wired connection 'Kabelgebundene Verbindung 1'
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3402] manager: (eth0): found matching connection 'Kabelgebundene Verbindung 1'
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3403] device (eth0): state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3406] device (eth0): state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3424] device (eth0): Activation: starting connection 'Kabelgebundene Verbindung 1' (3756b051-07fe-31aa-8489-a19c5ffcc264)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.3722] ModemManager available in the bus
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.4258] manager: startup complete
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.4266] device (eth0): state change: disconnected -> prepare (reason 'none') [30 40 0]
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.4277] device (eth0): state change: prepare -> config (reason 'none') [40 50 0]
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.4738] device (eth0): state change: config -> ip-config (reason 'none') [50 70 0]
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.4760] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.4783] dhcp4 (eth0): dhclient started with pid 4207
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5244] dhcp4 (eth0): address 192.168.1.146
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5244] dhcp4 (eth0): plen 24 (255.255.255.0)
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5244] dhcp4 (eth0): gateway 192.168.1.1
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5244] dhcp4 (eth0): server identifier 192.168.1.1
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5244] dhcp4 (eth0): lease time 86400
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5244] dhcp4 (eth0): nameserver '192.168.1.1'
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5245] dhcp4 (eth0): state changed unknown -> bound
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5253] device (eth0): state change: ip-config -> ip-check (reason 'none') [70 80 0]
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5256] device (eth0): state change: ip-check -> secondaries (reason 'none') [80 90 0]
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5259] device (eth0): state change: secondaries -> activated (reason 'none') [90 100 0]
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5259] manager: NetworkManager state is now CONNECTED_LOCAL
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5445] manager: NetworkManager state is now CONNECTED_GLOBAL
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5447] policy: set 'Kabelgebundene Verbindung 1' (eth0) as default for IPv4 routing and DNS
Aug 15 19:28:07 js12 NetworkManager[4190]: <info> [1502818087.5468] device (eth0): Activation: successful, device activated.

Ich weiß nicht, warum er WLAN aktiviert. Mein Linux-Rechner hat kein WLAN, sondern ist per Kabel verbunden.

[mat6937]

Code: Alles auswählen

Aug 15 19:28:07 js12 NetworkManager[4190]: <info>  [1502818087.3194] manager: WiFi enabled by radio killswitch; enabled by state file
Aug 15 19:28:07 js12 NetworkManager[4190]: <info>  [1502818087.3194] manager: WWAN enabled by radio killswitch; enabled by state file
Aug 15 19:28:07 js12 NetworkManager[4190]: <info>  [1502818087.3194] manager: Networking is enabled by state file

Ich weiß nicht, warum er WLAN aktiviert. Mein Linux-Rechner hat kein WLAN, ...

Kann es evtl. sein, dass dein Linux-Rechner im BIOS (oder gleichwertig) etwas bzgl. Wifi aktiviert hat?

OK, dein Linux-Rechner hat z. Zt. kein WLAN, aber wäre er WLAN-fähig?

[PeteMaravich]

Ich bin jetzt auch auf den Avahi-Daemon gestoßen. Benötigt man diesen? Kann es Probleme geben, wenn man den NetworkManager nutzt? Der Daemon hat zudem Probleme, die resolv.conf zu öffnen:

Aug 15 15:29:44 js12 avahi-daemon[491]: Failed to open /etc/resolv.conf: Invalid argument
Aug 15 15:29:44 js12 avahi-daemon[491]: No service file found in /etc/avahi/services.
Aug 15 15:29:44 js12 avahi-daemon[491]: Network interface enumeration completed.
Aug 15 15:29:44 js12 avahi-daemon[491]: Server startup complete. Host name is js12.local. Local service cookie is 2039496353.
Aug 15 15:29:47 js12 avahi-daemon[491]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.146.
Aug 15 15:29:47 js12 avahi-daemon[491]: New relevant interface eth0.IPv4 for mDNS.
Aug 15 15:29:47 js12 avahi-daemon[491]: Registering new address record for 192.168.1.146 on eth0.IPv4.
Aug 15 15:29:48 js12 avahi-daemon[491]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::76d4:35ff:fe9e:2d0e.
Aug 15 15:29:48 js12 avahi-daemon[491]: New relevant interface eth0.IPv6 for mDNS.
Aug 15 15:29:48 js12 avahi-daemon[491]: Registering new address record for fe80::76d4:35ff:fe9e:2d0e on eth0.*.
Aug 15 15:40:04 js12 avahi-daemon[490]: Found user 'avahi' (UID 105) and group 'avahi' (GID 112).
Aug 15 15:40:04 js12 avahi-daemon[490]: Successfully dropped root privileges.
Aug 15 15:40:04 js12 avahi-daemon[490]: avahi-daemon 0.6.32 starting up.
Aug 15 15:40:04 js12 avahi-daemon[490]: Successfully called chroot().
Aug 15 15:40:04 js12 avahi-daemon[490]: Successfully dropped remaining capabilities.
Aug 15 15:40:04 js12 avahi-daemon[497]: chroot.c: open() failed: No such file or directory
Aug 15 15:40:04 js12 avahi-daemon[490]: Failed to open /etc/resolv.conf: Invalid argument
Aug 15 15:40:04 js12 avahi-daemon[490]: No service file found in /etc/avahi/services.
Aug 15 15:40:04 js12 avahi-daemon[490]: Network interface enumeration completed.
Aug 15 15:40:04 js12 avahi-daemon[490]: Server startup complete. Host name is js12.local. Local service cookie is 2155865919.
Aug 15 15:40:06 js12 avahi-daemon[490]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.146.
Aug 15 15:40:06 js12 avahi-daemon[490]: New relevant interface eth0.IPv4 for mDNS.
Aug 15 15:40:06 js12 avahi-daemon[490]: Registering new address record for 192.168.1.146 on eth0.IPv4.
Aug 15 15:40:08 js12 avahi-daemon[490]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::76d4:35ff:fe9e:2d0e.
Aug 15 15:40:08 js12 avahi-daemon[490]: New relevant interface eth0.IPv6 for mDNS.
Aug 15 15:40:08 js12 avahi-daemon[490]: Registering new address record for fe80::76d4:35ff:fe9e:2d0e on eth0.*.
Aug 15 18:06:37 js12 avahi-daemon[490]: Withdrawing address record for fe80::76d4:35ff:fe9e:2d0e on eth0.
Aug 15 18:06:37 js12 avahi-daemon[490]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::76d4:35ff:fe9e:2d0e.
Aug 15 18:06:37 js12 avahi-daemon[490]: Interface eth0.IPv6 no longer relevant for mDNS.
Aug 15 18:06:37 js12 avahi-daemon[490]: Withdrawing address record for 192.168.1.146 on eth0.
Aug 15 18:06:37 js12 avahi-daemon[490]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.146.
Aug 15 18:06:37 js12 avahi-daemon[490]: Interface eth0.IPv4 no longer relevant for mDNS.
Aug 15 18:06:43 js12 avahi-daemon[490]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::adc2:127d:39b:adf7.
Aug 15 18:06:43 js12 avahi-daemon[490]: New relevant interface eth0.IPv6 for mDNS.
Aug 15 18:06:43 js12 avahi-daemon[490]: Registering new address record for fe80::adc2:127d:39b:adf7 on eth0.*.
Aug 15 18:07:12 js12 avahi-daemon[490]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.146.
Aug 15 18:07:12 js12 avahi-daemon[490]: New relevant interface eth0.IPv4 for mDNS.
Aug 15 18:07:12 js12 avahi-daemon[490]: Registering new address record for 192.168.1.146 on eth0.IPv4.
Aug 15 19:49:46 js12 firefox-esr.desktop[1637]: c/<@https://www.google.de/search?q=avahi-da ... YBg:53:103
Aug 15 19:52:56 js12 avahi-daemon[490]: Got SIGTERM, quitting.
Aug 15 19:52:56 js12 avahi-daemon[490]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::adc2:127d:39b:adf7.
Aug 15 19:52:56 js12 avahi-daemon[490]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.146.

Ich habe den avahi-Daemon gestoppt, was keine Abhilfe geschafft hat.

Die resolv.conf ist anscheined auch korrekt verlinkt:

lrwxrwxrwx 1 root root 35 Aug 15 19:28 /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf

[mat6937]

Ich bin jetzt auch auf den Avahi-Daemon gestoßen. Benötigt man diesen? Kann es Probleme geben, wenn man den NetworkManager nutzt?

Schau mal betr. wifi, im BIOS nach.

Wenn Du dir das zutraust, dann deinstalliere (evtl. auch nur temporär) NetworkManager, dhclient und avahi-daemon und konfiguriere die Netzanbindung (statisch zugewiesene IP-Adresse) mit systemd-networkd.

[PeteMaravich]

Ich bin jetzt auch auf den Avahi-Daemon gestoßen. Benötigt man diesen? Kann es Probleme geben, wenn man den NetworkManager nutzt?

Schau mal betr. wifi, im BIOS nach.

Wenn Du dir das zutraust, dann deinstalliere (evtl. auch nur temporär) NetworkManager, dhclient und avahi-daemon und konfiguriere die Netzanbindung (statisch zugewiesene IP-Adresse) mit systemd-networkd.

Dass das Motherboard WiFi unterstützt, kann ich ausschließen. Habe ich selber auch mal geschaut. Fände ich aus seltsam, weil ich nun schon mindestens zwei Jahre nichts mehr am BIOS gefummelt habe, aber erst seit wenigen Wochen habe ich die geschilderten Probleme.

[mat6937]

Fände ich aus seltsam, weil ich nun schon mindestens zwei Jahre nichts mehr am BIOS gefummelt habe, aber erst seit wenigen Wochen habe ich die geschilderten Probleme.

Naja, im BIOS nicht, aber ein release-upgrade hast Du gemacht und da könnte die Interaktion mit dem BIOS evtl. anders sein. Aber das ist jetzt nur Spekulation.

[PeteMaravich]

Es wird kurioser. Ich habe gerade festgestellt, dass das WLAN erst dann kaputt ist, wenn ich mich mit meinem normalen Nutzernamen in grafischen Benutzeroberfläche einlogge. Logge ich mich wieder aus, dann läuft's wieder.

Bin gerade dabei, den Network-Manager rauszuoperieren und den systemd-networkd-Dämonen zu nehmen. Dumm nur, dass der im Autostart nicht funktioniert. Ich bekomme folgende Fehlermeldung:

Aug 16 00:00:41 js12 systemd-networkd[251]: Could not connect to bus: Permission denied
Aug 16 00:00:41 js12 systemd[1]: systemd-networkd.service: Main process exited, code=exited, status=1/FAILURE
Aug 16 00:00:41 js12 systemd[1]: Failed to start Network Service.
Aug 16 00:00:41 js12 systemd[1]: systemd-networkd.service: Unit entered failed state.
Aug 16 00:00:41 js12 systemd[1]: systemd-networkd.service: Failed with result 'exit-code'.

Dabei wird der dbus viel später gestartet:

Aug 16 00:00:43 js12 dbus[500]: [system] Successfully activated service 'org.freedesktop.systemd1'
Aug 16 00:00:43 js12 avahi-daemon[496]: Successfully called chroot().
Aug 16 00:00:43 js12 avahi-daemon[496]: Successfully dropped remaining capabilities.
Aug 16 00:00:43 js12 avahi-daemon[511]: chroot.c: open() failed: No such file or directory
Aug 16 00:00:43 js12 avahi-daemon[496]: Failed to open /etc/resolv.conf: Invalid argument
Aug 16 00:00:43 js12 avahi-daemon[496]: No service file found in /etc/avahi/services.
Aug 16 00:00:43 js12 systemd[1]: Started RealtimeKit Scheduling Policy Service.
Aug 16 00:00:43 js12 avahi-daemon[496]: Network interface enumeration completed.
Aug 16 00:00:43 js12 avahi-daemon[496]: Server startup complete. Host name is js12.local. Local service cookie is 1151953364.
Aug 16 00:00:43 js12 systemd[1]: Started Avahi mDNS/DNS-SD Stack.
Aug 16 00:00:43 js12 systemd[1]: Starting LSB: SANE network scanner server...
Aug 16 00:00:43 js12 dbus[500]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'

Ich bin nun kein dbus-Experte, aber für mich sieht das so aus, als ob der erst zusammen mit der grafischen Benutzeroberfläche gestartet wird.

Als Zwischenlösung habe ich nun die Datei /lib/systemd/system/systemd-networkd.service

editiert. Dort gibt es einen Parameter, den ich fünf Sekunden gesetzt habe:

Code: Alles auswählen

RestartSec=5
[code]

Funktioniert, ist aber doof. Da müsste ich mich noch einlesen, wie die Abhängigkeiten korrekt formuliert werden. Mir wird ein ähnlich angst und bange: Wie will man networkd auf einem Server nutzen, wenn es mal keinen dbus gibt? Da wird doch der zweite vor dem ersten Schritt gemacht. Oder bin ich da komplett auf dem Holzweg?

Es kann ja natürlich auch sein, dass meine Config-Dateien es auch nicht mehr mit einer frischen Installation aufnehmen können. Ich habe das System 2009 installiert und seitdem immer schön ein dist-upgrade gemacht.

[mat6937]

Ich bin nun kein dbus-Experte, aber für mich sieht das so aus, als ob der erst zusammen mit der grafischen Benutzeroberfläche gestartet wird.

Als Zwischenlösung habe ich nun die Datei /lib/systemd/system/systemd-networkd.service

editiert.

In der [Unit]-section der systemd-networkd.service sollte es die Zeile:

Code: Alles auswählen

After=dbus.service ...

geben. Poste mal die Ausgabe von:

Code: Alles auswählen

systemctl cat systemd-networkd.service

Es kann ja natürlich auch sein, dass meine Config-Dateien es auch nicht mehr mit einer frischen Installation aufnehmen können. Ich habe das System 2009 installiert und seitdem immer schön ein dist-upgrade gemacht.

M. E. sollte man beim Übergang von SysVinit zu systemd kein dist-upgrade mehr machen, sondern eine Neuinstallation.

[BenutzerGa4gooPh]

Ich möchte mal festhalten:
Ein Linux-Rechner angeblich ohne WLAN (!) verhindert angeblich die Authentifizierung anderer WLAN-Clients.
(Es könnte durchaus sein, dass Spanning Tree oder Routen oder (doppelte) IP-Adressen/DHCP oder ZeroConfig/Avahi bei Anstecken eines schlecht konfigurierten Netzwerkgerätes "durcheinander gebracht"werden. Aber doch keine WLAN-Authentifizierung anderer Geräte durch einen Linux-Host ohne WLAN! Oder wir wissen nichts von WLAN im Linux-Rechner und entsprechenden Authentifizierungsmethoden?)

Umkonfigurationen am Router helfen jedoch kurzzeitig, WLAN-Clients zu authentifizeiren.
Logische Folge: Kann nur am Linux-Rechner ohne WLAN liegen!

Ich habe das System 2009 installiert und seitdem immer schön ein dist-upgrade gemacht.

3 x angeforderte Logs des Windows-Rechners mit Linux-Live-ISO und aktiviertem WLAN werden nicht geliefert. Willkommen auf meiner Ignorier-Liste!
Wir haben bisher eine einzige konkrete Fehlermeldung (Windows-Ereignisprotokoll, Authentifizierungsfehler) aufgrund meiner Rückfrage!
Letzter Beitrag bezüglich Peter.

@mat6397: Warum "basteln" am Linux-Rechner (2009 aufgesetzt) und angeblich ohne WLAN?