systemd-networkd, Erreichbarkeit der Rechner im Netz

[halo44]

Hallo,

benötige mal wieder Hilfe in Sachen lokales Netzwerk.

Ich habe schon vor einiger Zeit meinen Desktoprechner, der per LAN am Router hängt, auf systemd-networkd umgestellt.
Die zugehörigen Dienste laufen, NetworkMananger und networking sind deaktiviert. Alles läuft wie es soll.

So habe ich mich nun entschlossen nach dem gleichen Verfahren meinen Notebook ebenfalls auf systemd-networkd umzustellen.
Der Notebook hängt auch direkt an einem LAN-Port des Routers, kann aber auch über WLAN ins Netz gehen, wobei ich WLAN nur
selten nutze.

Da ich aber keine halben Sachen machen wollte, habe ich sowohl LAN als auch WLAN auf systemd-networkd nach gleichem Schema
eingerichtet.

In der Folge können sich beide Rechner nur dann noch per ssh erreichen, wenn WLAN am Router eingeschaltet und der Dienst
wpa_supplicant@wlp7s0 auf dem Notebook gestartet ist.

Auch ein ping auf die IP des LAN-Anschlusses des Notebooks scheitert, obwohl die IP richtig ist und der Notebook per LAN ins Internet kann. Auch kann der Notebook die IP des Desktoprechners nicht anpingen, obwohl auch der mit der richtigen IP im Netz ist.

Muß ich wirklich WLAN aktivieren, damit die Rechner sich erreichen können, obwohl eigentlich LAN genügen müßte. Was muß ich noch an Infos liefern, um einer Lösung näher zu kommen?

Vielen Dank für jede Unterstützung.

Gruss H.

[mat6937]

Da ich aber keine halben Sachen machen wollte, ...

Durch die gleichzeitige Verbindung per Kabel und per WLAN, _mit IP-Adressen_ aus einem Subnetz, hast Du schon eine "halbe Sache" gemacht:

Muß ich wirklich WLAN aktivieren, damit die Rechner sich erreichen können, obwohl eigentlich LAN genügen müßte. Was muß ich noch an Infos liefern, um einer Lösung näher zu kommen?

Poste mal von beiden Geräten, die Ausgaben von:

Code: Alles auswählen

arp -av
ip n s
route -n
ip a

[halo44]

Durch die gleichzeitige Verbindung per Kabel und per WLAN, _mit IP-Adressen_ aus einem Subnetz, hast Du schon eine "halbe Sache" gemacht:

Ohne systemd-networkd hatte ich damit nie Probleme. Wenn ich das hier anders handeln soll, muß ich das wohl ins Auge fassen.

Poste mal von beiden Geräten, die Ausgaben von:

Code: Alles auswählen

arp -av
ip n s
route -n
ip a

Hier die Ausgaben auf dem Desktoprechner:

Code: Alles auswählen

arp -av
fritz.box (192.168.2.1) auf 9c:c7:a6:55:d5:49 [ether] auf enp1s0
Mediareceiver.fritz.box (192.168.2.29) auf ac:6f:bb:48:77:cc [ether] auf enp1s0
Einträge: 2   Ignoriert: 0   Gefunden: 2

ip n s
192.168.2.1 dev enp1s0 lladdr 9c:c7:a6:55:d5:49 REACHABLE
192.168.2.29 dev enp1s0 lladdr ac:6f:bb:48:77:cc REACHABLE

route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 enp1s0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 enp1s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d8:cb:8a:c0:ae:72 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.201/24 brd 192.168.2.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::dacb:8aff:fec0:ae72/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:b6:dd:7b brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:b6:dd:7b brd ff:ff:ff:ff:ff:ff

Und hier die vom Notebook ohne aktives WLAN, also die Situation, die vor systemd-networkd immer funktionierte:

Code: Alles auswählen

arp -av
? (192.168.2.201) auf d8:cb:8a:c0:ae:72 [ether] auf enp9s0
? (192.168.2.1) auf <unvollständig> auf wlp7s0
? (192.168.2.201) auf <unvollständig> auf wlp7s0
? (192.168.2.1) auf 9c:c7:a6:55:d5:49 [ether] auf enp9s0
Einträge: 4   Ignoriert: 0   Gefunden: 4

ip n s
192.168.2.201 dev enp9s0 lladdr d8:cb:8a:c0:ae:72 STALE
192.168.2.1 dev wlp7s0  FAILED
192.168.2.201 dev wlp7s0  INCOMPLETE
192.168.2.1 dev enp9s0 lladdr 9c:c7:a6:55:d5:49 REACHABLE

route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 wlp7s0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 enp9s0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wlp7s0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 enp9s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e0:69:95:6e:b1:36 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.205/24 brd 192.168.2.255 scope global enp9s0
       valid_lft forever preferred_lft forever
    inet6 fe80::e269:95ff:fe6e:b136/64 scope link 
       valid_lft forever preferred_lft forever
3: wlp7s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether ec:55:f9:75:3b:92 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.204/24 brd 192.168.2.255 scope global wlp7s0
       valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:da:03:29 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:da:03:29 brd ff:ff:ff:ff:ff:ff

Gruss H.

[mat6937]

Und hier die vom Notebook ohne aktives WLAN, also die Situation, die vor systemd-networkd immer funktionierte:

Code: Alles auswählen

arp -av
? (192.168.2.201) auf d8:cb:8a:c0:ae:72 [ether] auf enp9s0
? (192.168.2.1) auf <unvollständig> auf wlp7s0
? (192.168.2.201) auf <unvollständig> auf wlp7s0
? (192.168.2.1) auf 9c:c7:a6:55:d5:49 [ether] auf enp9s0
Einträge: 4   Ignoriert: 0   Gefunden: 4

route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 wlp7s0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 enp9s0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wlp7s0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 enp9s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Naja, das ist auch keine saubere Konfiguration (auch wenn diese mal funktioniert hat). Kein vollständiger arp-cache-Eintrag, 2 default routen mit identischer metric, usw.

Die jetzige Konfiguration mit aktivem WLAN willst Du nicht zeigen? Oder meinst Du mit "ohne aktiv", dass es so nicht richtig funktioniert?

[TomL]

Muß ich wirklich WLAN aktivieren, damit die Rechner sich erreichen können, obwohl eigentlich LAN genügen müßte. Was muß ich noch an Infos liefern, um einer Lösung näher zu kommen?

Ich habe auch so einen Kandidaten... meinen Reise-Laptop. Unterwegs ist der WLAN-Zugang (oft mit tägl. wechselnden WLAN-APs) natürlich obligatorisch, aber zuhause verwende ich völlig willkürlich Kabel oder Funk... ganz nach Lust und Laune. Meine Erfahrung ist, dass systemd-networkd für solche Einstäze eher weniger gut geeignet ist. Ich glaube, seine Stärken hat es bei der Handhabung statischer Netzwerkeinstellungen. Und weil ich auf meinem Laptop zudem auch noch ebenso flexibel meine Server-Mounts verfügbar haben will, zuhause direkt und unterwegs via OpenVPN, scheiden natürlich auch solche Lösungen wie diese Networkmanager aus, die dabei mehr Probleme verursachen, als das sie hilfreich sind.

Ich habe mir das mit einem Script mit Menüsteuerung erleichtert. Damit kann ich einfach zwischen WLAN und ETH switchen, bei Bedaf OpenVPN hinzuschalten, und wenn gewünscht auch die Mounts. Und was auch problemlos möglich ist, ich kann auch beide NIC gleichzeitig aktivieren. Der Rechner ist via SSH gleichzeitig über beide NIC mit der jeweiligen IP erreichbar. Ums kurz zu sagen, ich glaube nicht, dass systemd-networkd an dieser Stelle eine gute Wahl ist.

[halo44]

Die jetzige Konfiguration mit aktivem WLAN willst Du nicht zeigen? Oder meinst Du mit "ohne aktiv", dass es so nicht richtig funktioniert?

Das liegt nicht darin begründet, daß ich dies nicht zeigen will. Ich habe die Konfiguration ohne aktives WLAN gezeigt, weil es die ist, die nicht funktioniert. Aktiviere ich WLAN, dann finden die Rechner einander ja. Insofern habe ich vermutet, daß diese Konfiguration nicht gefragt war.

Gruss H.

[halo44]

... Ich habe mir das mit einem Script mit Menüsteuerung erleichtert. Damit kann ich einfach zwischen WLAN und ETH switchen, bei Bedaf OpenVPN hinzuschalten, und wenn gewünscht auch die Mounts. Und was auch problemlos möglich ist, ich kann auch beide NIC gleichzeitig aktivieren. Der Rechner ist via SSH gleichzeitig über beide NIC mit der jeweiligen IP erreichbar. Ums kurz zu sagen, ich glaube nicht, dass systemd-networkd an dieser Stelle eine gute Wahl ist.

Sollte ich daher systemd-networkd auf dem Notebook für beide Übertragungswege deinstallieren, was am einfachsten über Rückspielen der entsprechenden Systemsicherung geht oder kann ich systemd-networkd über LAN betreiben und WLAN dem NetworkManager bzw. networking überlassen?

Gruss H.

[mat6937]

[..., weil es die ist, die nicht funktioniert.

Installiere mal:

Code: Alles auswählen

apt-get install iputils-arping

und versuch mit deaktiviertem WLAN von deinem Notebook aus:

Code: Alles auswählen

arping -c 3 -I enp9s0 -s 192.168.2.205 192.168.2.201

Poste danach von deinem Notebook, die Ausgaben von arping und die von:

Code: Alles auswählen

ping -c 3 -W 2 192.168.2.201
arp -av

[BenutzerGa4gooPh]

Netzwerkmanager: Verschiedene Prioritäten beider Verbindungen (mittels GUI bereits konfigurierbar) testen. Beide "automatisch verbinden".
Teste ansonsten Bridging von LAN und WLAN. Durch Spanning Tree Protocol ist nur eine Verbindung aktiv. Beide IFs sind ja im gleichen Subnetz.
Anmerkung: Ich betreibe einen Homeserver und einen Laptop mit aktivem LAN und WLAN in verschiedenen Subnetzen. Homeserver per SSH problemlos erreichbar. (Mit Fritzbox verschiedene Subnetze kaum möglich.)

[mat6937]

... kann ich systemd-networkd über LAN betreiben und WLAN dem NetworkManager bzw. networking überlassen?

Willst Du immer beide Verbindungen aktiv haben oder die LAN-Verbindung evtl. nur als fallback-Lösung (wenn das WLAN nicht funktioniert) benutzen?

[halo44]

... und versuch mit deaktiviertem WLAN von deinem Notebook aus:

Code: Alles auswählen

arping -c 3 -I enp9s0 -s 192.168.2.205 192.168.2.201

Poste danach von deinem Notebook, die Ausgaben von arping und die von:

Code: Alles auswählen

ping -c 3 -W 2 192.168.2.201
arp -av

Hier die Ausgaben:

Code: Alles auswählen

arping -c 3 -I enp9s0 -s 192.168.2.205 192.168.2.201
ARPING 192.168.2.201 from 192.168.2.205 enp9s0
Unicast reply from 192.168.2.201 [D8:CB:8A:C0:AE:72]  1.219ms
Unicast reply from 192.168.2.201 [D8:CB:8A:C0:AE:72]  1.114ms
Unicast reply from 192.168.2.201 [D8:CB:8A:C0:AE:72]  1.083ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)

Code: Alles auswählen

ping -c 3 -W 2 192.168.2.201
PING 192.168.2.201 (192.168.2.201) 56(84) bytes of data.
From 192.168.2.204 icmp_seq=1 Destination Host Unreachable
From 192.168.2.204 icmp_seq=2 Destination Host Unreachable
From 192.168.2.204 icmp_seq=3 Destination Host Unreachable

--- 192.168.2.201 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2045ms
pipe 3

Code: Alles auswählen

arp -av
? (192.168.2.1) auf 9c:c7:a6:55:d5:49 [ether] auf enp9s0
? (192.168.2.1) auf <unvollständig> auf wlp7s0
? (192.168.2.29) auf ac:6f:bb:48:77:cc [ether] auf enp9s0
? (192.168.2.201) auf d8:cb:8a:c0:ae:72 [ether] auf enp9s0
? (192.168.2.29) auf <unvollständig> auf wlp7s0
? (192.168.2.201) auf <unvollständig> auf wlp7s0
Einträge: 6   Ignoriert: 0   Gefunden: 6

Willst Du immer beide Verbindungen aktiv haben oder die LAN-Verbindung evtl. nur als fallback-Lösung (wenn das WLAN nicht funktioniert) benutzen?

Eigentlich arbeite ich ausschließlich über die Kabelverbindung. WLAN nutze ich recht selten.

Gruss H.

[TomL]

Sollte ich daher systemd-networkd auf dem Notebook für beide Übertragungswege deinstallieren, was am einfachsten über Rückspielen der entsprechenden Systemsicherung geht oder kann ich systemd-networkd über LAN betreiben und WLAN dem NetworkManager bzw. networking überlassen?

Nein, Du brauchst nix zu deinstallieren. Es reicht im Fall der Fälle ganz einfach aus, systemd-networkd zu disablen. Aber soweit sind wir doch noch gar nicht. Mein Rat wäre, warte erst Mal ab, was mat6937 noch für Vorschläge hat und triff erst dann eine Entscheidung. Wenn Du WLAN allerdings wirklich nur sehr selten brauchst, würde ich das vielleicht einfach von Fall zu Fall manuell starten... soll heissen, der reguläre LAN-Zugriff findet wie gehabt via systemd-networkd statt, und wenn WLAN wirklich mal notwendig ist, dann eben schnell manuell hinzugeschaltet. Viel ist dafür nicht notwendig.... und das funktioniert imho auch konfliktfrei mit dem Kabel-Connect via systemd-networkd.

Bei Beginn öffnen (Achtung: hier ist die korrekte conf einzutragen):

Code: Alles auswählen

/sbin/ip link set dev wlp7s0 up
/sbin/wpa_supplicant -B -i wlp7s0 -c /etc/wpa_supplicant/MeinAP.conf
/sbin/dhclient wlp7s0 

und bei Arbeitsende wieder schließen:

Code: Alles auswählen

/sbin/ip link set dev wlp7s0 down
/sbin/dhclient -r wlp7s0
/usr/bin/pkill -f MeinAP.conf

Das lässt sich in ein einfachstes Script packen... in der Mitte ein

Code: Alles auswählen

read -p "Enter zum Schließen des WLAN-NIC"

platziert, und alles via Desktopstarter... dann kann man es nutzen, wenn mans braucht, ansonsten ignoriert man es einfach.

[halo44]

... Wenn Du WLAN allerdings wirklich nur sehr selten brauchst, würde ich das vielleicht einfach von Fall zu Fall manuell starten... soll heissen, der reguläre LAN-Zugriff findet wie gehabt via systemd-networkd statt, und wenn WLAN wirklich mal notwendig ist, dann eben schnell manuell hinzugeschaltet. Viel ist dafür nicht notwendig.... und das funktioniert imho auch konfliktfrei mit dem Kabel-Connect via systemd-networkd ...

Ebendas funktioniert ja nicht. Ich bekomme über systemd-networkd keine LAN-Verbindung zum jeweils anderen Rechner, wenn WLAN nicht läuft, was ja i.d.R. bei mir der Fall ist. Das war ja auch mein Anliegen beim Start des Themas.

Gruss H.

[TomL]

... Wenn Du WLAN allerdings wirklich nur sehr selten brauchst, würde ich das vielleicht einfach von Fall zu Fall manuell starten... soll heissen, der reguläre LAN-Zugriff findet wie gehabt via systemd-networkd statt, und wenn WLAN wirklich mal notwendig ist, dann eben schnell manuell hinzugeschaltet. Viel ist dafür nicht notwendig.... und das funktioniert imho auch konfliktfrei mit dem Kabel-Connect via systemd-networkd ...

Ebendas funktioniert ja nicht. Ich bekomme über systemd-networkd keine LAN-Verbindung zum jeweils anderen Rechner, wenn WLAN nicht läuft, was ja i.d.R. bei mir der Fall ist. Das war ja auch mein Anliegen beim Start des Themas.

Äh... hasst Du es mit meinem Vorschlag versucht? Wenn beide NIC von systemd-networkd gehandhabt werden, wie das bei Dir eingestellt war, ist das was anderes, als mein Beispiel, wo systemd-networkd nur das Kabel-Nic anpackt und das WLAN-NIC dabei gar nicht beachtet. Probiers einfach....

1. Wlan-NIC in systemd-networkd rausnehmen
2. Rechner durchstarten, so das er das Kabel-NIC wie gehabt via systemd-network öffnet und das Netz verbindet
3. die paar Script-Befehle für den manuellen WLAN-Start ausführen...

...dann siehst Du, obs geht oder nicht. BTW... was mir gerade so einfällt... ein weiterer Problemverursacher ist der dhcp-Daemon, den man eigentlich gar nicht braucht, wenn man das Netz via systemd verbindet. Den würde ich zum Testen einfach mal stoppen und vielleicht sogar disablen. Wieder in Betrieb nehmen ist ja mit einem einfachen "enable" jeder Zeit möglich.

[halo44]

... 1. Wlan-NIC in systemd-networkd rausnehmen

Wenn das heissen soll, daß die Dienste wpa_supplicant und wpa_supplicant@wlp7s0 disabled sein sollen, so ist das schon bei mir der Fall. Oder muß ich da etwas anderes unternehmen?

Code: Alles auswählen

iwconfig wlp7s0 txpower off

?

Gruss H.

[TomL]

Wenn das heissen soll, daß die Dienste wpa_supplicant und wpa_supplicant@wlp7s0 disabled sein sollen, so ist das schon bei mir der Fall. Oder muß ich da etwas anderes unternehmen?

Keine Ahnung... ich weiss nicht, wie Du das eingerichtet hast, dass das WLAN-NIC bei Systemstart automatisch geöffnet wird und ein Connect-Versuch unternommen wird.... genau diese Schritte würde ich testweise wieder zurücknehmen... eben damit es nicht automatisch gestartet wird.

[halo44]

... ich weiss nicht, wie Du das eingerichtet hast, dass das WLAN-NIC bei Systemstart automatisch geöffnet wird ...

Anscheinend belässt Debian den Status des WLAN-NIC bei dem, der beim letzten Shutdown/Reboot aktuell war.

Schalte ich das WLAN-NIC aus:

Code: Alles auswählen

iwconfig wlp7s0 txpower off

dann ist es beim nächsten Systemstart abgeschaltet und die beiden Rechner erreichen einander mittels systemd-networkd über LAN-Kabel. Das ist im Grunde, was ich erreichen will.

Ich werde also den Zustand des NIC, der sich leider über Fn+F3 auf meinem Notebook fast nie umstellen lässt, künftig über o.a. Befehl in einem Skript steuern, welches auch die erforderlichen Dienste schaltet.

Danke an alle Helfer.

Gruss H.

[mat6937]

Ich bekomme über systemd-networkd keine LAN-Verbindung zum jeweils anderen Rechner, wenn WLAN nicht läuft, ...

Lt. der arping-Ausgabe funktioniert die LAN-Verbidung:

Code: Alles auswählen

arping -c 3 -I enp9s0 -s 192.168.2.205 192.168.2.201
ARPING 192.168.2.201 from 192.168.2.205 enp9s0
Unicast reply from 192.168.2.201 [D8:CB:8A:C0:AE:72]  1.219ms
Unicast reply from 192.168.2.201 [D8:CB:8A:C0:AE:72]  1.114ms
Unicast reply from 192.168.2.201 [D8:CB:8A:C0:AE:72]  1.083ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)

War zum Zeitpunkt des arpings, das WLAN aktiv oder war das WLAN deaktiviert? Wenn aktiviert, dann versuch mal den arping, wenn das WLAN deaktiviert ist.

[halo44]

... Lt. der arping-Ausgabe funktioniert die LAN-Verbidung ...

Ja, arping kann das anscheinend, ping und ssh aber nicht.

War zum Zeitpunkt des arpings, das WLAN aktiv oder war das WLAN deaktiviert? Wenn aktiviert, dann versuch mal den arping, wenn das WLAN deaktiviert ist.

WLAN war nicht aktiv.

Gruss H.

[mat6937]

Ja, arping kann das anscheinend, ping und ssh aber nicht.

WLAN war nicht aktiv.

Wenn arping das kann, dann muss es auch mit icmp und tcp/udp funktionieren, wenn das Routing OK ist.

Und lt. einem deiner Beiträge (siehe oben) ist das auch der Fall, wenn Du:

Code: Alles auswählen

iwconfig wlp7s0 txpower off

ausgeführt hast.

Poste mal die Ausgaben von:

Code: Alles auswählen

route -n
arp -av

wenn Du "iwconfig wlp7s0 txpower off" ausgeführt hast und die LAN-Verbindung funktioniert.

[halo44]

... Poste mal die Ausgaben von:

Code: Alles auswählen

route -n
arp -av

wenn Du "iwconfig wlp7s0 txpower off" ausgeführt hast und die LAN-Verbindung funktioniert.

Gerne, hier die Ausgaben:

Code: Alles auswählen

route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 enp9s0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 enp9s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

arp -av
? (192.168.2.1) auf 9c:c7:a6:55:d5:49 [ether] auf enp9s0
? (192.168.2.201) auf d8:cb:8a:c0:ae:72 [ether] auf enp9s0
Einträge: 2   Ignoriert: 0   Gefunden: 2

Gruss H.

[mat6937]

... hier die Ausgaben:

Code: Alles auswählen

route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 enp9s0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 enp9s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

arp -av
? (192.168.2.1) auf 9c:c7:a6:55:d5:49 [ether] auf enp9s0
? (192.168.2.201) auf d8:cb:8a:c0:ae:72 [ether] auf enp9s0
Einträge: 2   Ignoriert: 0   Gefunden: 2

Das sieht ganz anders aus. D. h., nur am deaktivieren des WLANs lag es nicht, sondern auch am fehlerhaften Routing und den fehlerhaften arp-cache-Einträgen (... für ein WLAN-Interface das noch up war aber keine Verbindung mehr hatte), nach dem Du das WLAN deaktiviert hast.