dapaul
Anmeldungsdatum: 2. Februar 2024
Beiträge: 6
|
Hallo zusammen, wie der Titel schon sagt, geht es darum, dass ich seit einigen Tagen das Problem habe, das ein Ubuntu Server einige Webseiten nicht mehr aufrufen kann. Einige Tage Internet durchforsten und Ideen ausprobieren brachten mich nicht weiter. Bevor ich nun die Kiste einfach neu aufsetze, würde ich gern das Problem verstehen und ggf. lösen, ich kann es mir nicht erklären.
Kurz zum Setup:
Heimnetz mit einer Fritzbox, dort hängt dran:
Arbeitslaptop mit Windows 10. (Alles läuft) Raspberry mit batocera drauf (Alles läuft) Server mir Unraid. (Alles läuft) Ein Thinclient mit Ubuntu Server 22.04.3 LTS (mein Problemkind)
Alle Geräte sind per WLAN mit der Fritzbox verbunden. Den Ubuntu Server (kurz: Server) konnte ich letzte Woche noch problemlos updaten, Software installieren und im Netz surfen. Anfang der Woche fiel mir auf, dass ich github.com nicht erreichen konnte, um per Git ein Repository dort hochzuladen. Ich bekam folgende Meldung dazu:
Failed to connect to github.com port 443: Time out Damit fing alles an. Dann habe ich folgende ping Tests gemacht:
| PING google.de(fra24s04-in-x03.1e100.net (2a00:1450:4001:827::2003)) 56 data bytes
64 bytes from fra24s04-in-x03.1e100.net (2a00:1450:4001:827::2003): icmp_seq=1 ttl=119 time=94.7 ms
64 bytes from fra24s04-in-x03.1e100.net (2a00:1450:4001:827::2003): icmp_seq=2 ttl=119 time=16.6 ms
64 bytes from fra24s04-in-x03.1e100.net (2a00:1450:4001:827::2003): icmp_seq=3 ttl=119 time=15.5 ms
|
| PING telekom.de (80.158.67.40) 56(84) bytes of data.
From 192.168.1.100 (192.168.1.100) icmp_seq=1 Destination Host Unreachable
From 192.168.1.100 (192.168.1.100) icmp_seq=2 Destination Host Unreachable
From 192.168.1.100 (192.168.1.100) icmp_seq=3 Destination Host Unreachable
|
| PING github.com (140.82.121.4) 56(84) bytes of data.
From 192.168.1.100 (192.168.1.100) icmp_seq=1 Destination Host Unreachable
From 192.168.1.100 (192.168.1.100) icmp_seq=2 Destination Host Unreachable
From 192.168.1.100 (192.168.1.100) icmp_seq=3 Destination Host Unreachable
|
| PING apple.com(apple.com (2620:149:af0::10)) 56 data bytes
64 bytes from apple.com (2620:149:af0::10): icmp_seq=1 ttl=60 time=12.8 ms
64 bytes from apple.com (2620:149:af0::10): icmp_seq=2 ttl=60 time=11.7 ms
64 bytes from apple.com (2620:149:af0::10): icmp_seq=3 ttl=60 time=11.3 ms
64 bytes from apple.com (2620:149:af0::10): icmp_seq=4 ttl=60 time=11.5 ms
|
Das kann beliebig weitergepielt werden. Interessanteweise bin ich der Meinung dass ich Anfag der Woche noch eine andere Fehlermeldung hatte. 😕
Verbunden ist der Server per WLAN Adapter von TP-Link, am Ethernetport hängt ein RJ54->ETH Adapter, der mir Daten vom Wechselrichter zur Verfügung stellt. Dieser hat eine feste IP-Adresse. Somit müssen alle Internetanfragen über die WLAN Karte laufen. Vllt. ist das auch das Hauptproblem? Nur wir könnte ich dem System beibringen, dass alle Anfragen über den WALN-Adapter zu laufen haben? Auszug ifconfig:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27 | enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.100 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 2003:ce:c72a:bc00:280:64ff:feb6:be9a prefixlen 64 scopeid 0x0<global>
inet6 fe80::280:64ff:feb6:be9a prefixlen 64 scopeid 0x20<link>
ether 00:80:64:b6:be:9a txqueuelen 1000 (Ethernet)
RX packets 10303 bytes 1820889 (1.8 MB)
RX errors 0 dropped 2288 overruns 0 frame 0
TX packets 1640 bytes 427558 (427.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 742 bytes 72467 (72.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 742 bytes 72467 (72.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlx30de4be0e290: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.6 netmask 255.255.255.0 broadcast 192.168.178.255
inet6 2003:ce:c72a:bc00:32de:4bff:fee0:e290 prefixlen 64 scopeid 0x0<global>
inet6 fe80::32de:4bff:fee0:e290 prefixlen 64 scopeid 0x20<link>
ether 30:de:4b:e0:e2:90 txqueuelen 1000 (Ethernet)
RX packets 10832 bytes 2726445 (2.7 MB)
RX errors 0 dropped 8 overruns 0 frame 0
TX packets 7505 bytes 1503452 (1.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
Was habe ich schon ohne Erfolg probiert?
Versuch IPV6 zu deaktivieren. Fritzbox neugestartet und aktuelles Update eingespielt. MTU Größe vom WLAN Adapter reduziert. Nameserver in resolvd.conf geändert und explizit die Fritzbox und 8.8.8.8 hinterlegt. Den systemd-resolved Dienst deaktiviert. dns=default in der Networkmanager.conf eingetragen.
Könnt ihr mir helfen das Problem zu finden und zu lösen? Die anderen Rechner im Netz funktionieren alle, deswegen kann die Fritzbox kein Problem sein. Meine Vermutung: Entweder ein DNS Auflösungsproblem in der Server Konfig, ein IPV6 Problem oder der Server versucht einiges über Ethernet zu Routen anstatt über WLAN. Danke vorab für eure Unterstützung. Gruß
Anbei noch ein paar Infos zum System: Ein "apt update" kann ich nicht ausführen, da die Ubuntu Repos ebenfalls nicht gefunden werden können, somit kann ich Pakete nicht nachinstallieren. Das Paket "traceroute" ist z. B. nicht installiert. | Linux wyse 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
|
IP-Link:
| 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:80:64:b6:be:9a brd ff:ff:ff:ff:ff:ff
3: wlx30de4be0e290: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 30:de:4b:e0:e2:90 brd ff:ff:ff:ff:ff:ff
|
Netplan Renderer:
| grep renderer /{lib,etc,run}/netplan/*yaml
grep: /lib/netplan/*yaml: No such file or directory
grep: /run/netplan/*yaml: Permission denied
|
NetworkManager Übersicht:
| nmcli general ; nmcli device ; nmcli connection
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
disconnected unknown enabled enabled enabled enabled
DEVICE TYPE STATE CONNECTION
enp4s0 ethernet unmanaged --
lo loopback unmanaged --
wlx30de4be0e290 wifi unmanaged --
NAME UUID TYPE DEVICE
Paul_5 0fbf37ec-2b3a-4652-9f36-5c24dd1f24f2 wifi --
|
Networkmanager Konfig:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30 | grep -r "" /etc/NetworkManager/NetworkManager.conf /{usr/lib,run,etc}/NetworkManager/conf.d/
/etc/NetworkManager/NetworkManager.conf:[main]
/etc/NetworkManager/NetworkManager.conf:plugins=ifupdown,keyfile
/etc/NetworkManager/NetworkManager.conf:dns=default
/etc/NetworkManager/NetworkManager.conf:
/etc/NetworkManager/NetworkManager.conf:[ifupdown]
/etc/NetworkManager/NetworkManager.conf:managed=false
/etc/NetworkManager/NetworkManager.conf:
/etc/NetworkManager/NetworkManager.conf:[device]
/etc/NetworkManager/NetworkManager.conf:wifi.scan-rand-mac-address=no
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:# Certain drivers are known not to support changing the MAC address.
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:# Disable touching the MAC address on such devices.
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:#
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:# See man NetworkManager.conf
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:#
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:# https://bugzilla.gnome.org/show_bug.cgi?id=777523
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:[device-31-mac-addr-change]
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:match-device=driver:eagle_sdio,driver:wl
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf:wifi.scan-rand-mac-address=no
/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf:[keyfile]
/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf:unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma
/usr/lib/NetworkManager/conf.d/10-dns-resolved.conf:[main]
/usr/lib/NetworkManager/conf.d/10-dns-resolved.conf:# We need to specify "dns=systemd-resolved" as for the time being our
/usr/lib/NetworkManager/conf.d/10-dns-resolved.conf:# /etc/resolv.conf points to resolvconf's generated file instead of
/usr/lib/NetworkManager/conf.d/10-dns-resolved.conf:# systemd-resolved's, so the auto-detection does not work.
/usr/lib/NetworkManager/conf.d/10-dns-resolved.conf:dns=systemd-resolved
grep: /run/NetworkManager/conf.d/: No such file or directory
/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf:[connection]
/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf:wifi.powersave = 3
|
Ping Anfragen vom Forum:
| ping -c 2 $(ip -4 route show default | grep -o '[0-9]*[.][.0-9]*' )
PING 192.168.178.6 (192.168.178.6) 56(124) bytes of data.
--- 192.168.178.6 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1024ms
|
| ping -c 2 $(ip -6 route show default |cut -d " " -f 3,5| sed s/\ /%/)
Usage
ping [options] <destination>
Options:
<destination> dns name or ip address
...
|
| ping -c 2 87.79.26.37 # UbuntuUsers.de
PING 87.79.26.37 (87.79.26.37) 56(84) bytes of data.
From 192.168.1.100 icmp_seq=1 Destination Host Unreachable
From 192.168.1.100 icmp_seq=2 Destination Host Unreachable
--- 87.79.26.37 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms
pipe 2
|
| ping -c 2 2001:4dd0:f100:0:dead:beef:cafe:1
PING 2001:4dd0:f100:0:dead:beef:cafe:1(2001:4dd0:f100:0:dead:beef:cafe:1) 56 data bytes
64 bytes from 2001:4dd0:f100:0:dead:beef:cafe:1: icmp_seq=1 ttl=54 time=15.1 ms
64 bytes from 2001:4dd0:f100:0:dead:beef:cafe:1: icmp_seq=2 ttl=54 time=13.2 ms
--- 2001:4dd0:f100:0:dead:beef:cafe:1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.222/14.183/15.144/0.961 ms
|
| ping -c 2 www.ubuntuusers.de
PING www.ubuntuusers.de(ha.ubuntu-de.org (2001:4dd0:f100:0:dead:beef:cafe:1)) 56 data bytes
64 bytes from ha.ubuntu-de.org (2001:4dd0:f100:0:dead:beef:cafe:1): icmp_seq=1 ttl=54 time=19.4 ms
64 bytes from ha.ubuntu-de.org (2001:4dd0:f100:0:dead:beef:cafe:1): icmp_seq=2 ttl=54 time=13.3 ms
--- www.ubuntuusers.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 13.346/16.360/19.374/3.014 ms
|
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 4488
|
Ist Dir aufgefallen, dass die URLs die mit IPv4 aufgelöst werden, diejenigen sind, bei denen "Destination Host Unreachable" ausgespuckt wird?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14206
|
dapaul schrieb: Nur wir könnte ich dem System beibringen, dass alle Anfragen über den WALN-Adapter zu laufen haben?
Wie sind jetzt die Ausgaben von:
ip a
ip r
ip n s
ip r g 1.1.1.1
?
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 18149
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Versuch IPV6 zu deaktivieren.
Fritzbox neugestartet und aktuelles Update eingespielt.
MTU Größe vom WLAN Adapter reduziert.
Nameserver in resolvd.conf geändert und explizit die Fritzbox und 8.8.8.8 hinterlegt.
Den systemd-resolved Dienst deaktiviert.
dns=default in der Networkmanager.conf eingetragen.
Das machst du jetzt bitte alles rückgängig und zeigst dann ip a
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 9424
Wohnort: Münster
|
dapaul schrieb: […] ein Ubuntu Server einige Webseiten nicht mehr aufrufen kann
Normalerweise ist ein Server ungeeignet zum Surfen. Welches ISO-Abbild hast Du bei der Installation benutzt,
entweder das für Server (gemäß Deiner Angabe) oder das für Desktops (nur solche erlauben Surfen)? Zeige bitte:
uname -a
cat /etc/lsb-release Welches Programm verwendest Du zur Konfiguration des Netzwerks, systemd-networkd oder NetworkManager oder was sonst? Zeige bitte:
networkctl
nmcli device | cat
|
dapaul
(Themenstarter)
Anmeldungsdatum: 2. Februar 2024
Beiträge: 6
|
Hallo zusammen, trollsportverein schrieb: Ist Dir aufgefallen, dass die URLs die mit IPv4 aufgelöst werden, diejenigen sind, bei denen "Destination Host Unreachable" ausgespuckt wird?
Nein, auf den ersten Blick nicht. Nach deinem Hinweis habe ich mir das mal angesehen. Interessanterweise werden die IPv4 URLs scheinbar alle über den Ethernet Port aufgelöst. Denn: Die IP 192.168.1.200 ist die Adresse vom RJ45 zu ETH Adapter von Waveshare, der am Ethernet Port hängt. Somit nutzt der Server den falschen Netzwerk Adapter, denn die Pings sollten ja ins Internet über WLAN laufen und nicht den Ethernet Adapter abfragen. Und selbst wenn dort keine Antwort kommt, sollte der Server dann den nächsten Adapter abfragen?
Ich habe das Netzwerkkabel abgezogen und wieder einen Ping ausgeführt, zu einer Webseite die nicht klappt. Ergebnis: Es passiert nichts! Nach Minuten des wartens bekomme ich kein Feedback im Terminal. Stecke ich das Netzwerkkabel wieder an, erhalte ich weiterhin die Meldung Destination Host Unreachable Die internen Aufrufe in meinem Heimnetz funktionieren alle und laufen auch über WLAN und IPv4. Aber: Nur per IP-Adresse! Sobald ich den Servernamen Verwende erhalte ich ebenfalls die Meldung Destination Host Unreachable. Irgendwo stimmt die DNS Auflösung nicht, nur wo? lubux schrieb: dapaul schrieb: Nur wir könnte ich dem System beibringen, dass alle Anfragen über den WALN-Adapter zu laufen haben?
Wie sind jetzt die Ausgaben von:
ip a
ip r
ip n s
ip r g 1.1.1.1
?
Anbei die Auszüge aus den genannten Befehlen:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 | ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
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: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:80:64:b6:be:9a brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global enp4s0
valid_lft forever preferred_lft forever
inet6 2003:ce:c74f:7c00:280:64ff:feb6:be9a/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7199sec preferred_lft 1369sec
inet6 fe80::280:64ff:feb6:be9a/64 scope link
valid_lft forever preferred_lft forever
3: wlx30de4be0e290: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 30:de:4b:e0:e2:90 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.6/24 metric 600 brd 192.168.178.255 scope global dynamic wlx30de4be0e290
valid_lft 864000sec preferred_lft 864000sec
inet6 fe80::32de:4bff:fee0:e290/64 scope link
valid_lft forever preferred_lft forever
|
| ip r
default via 192.168.1.200 dev enp4s0 proto static
default via 192.168.178.1 dev wlx30de4be0e290 proto dhcp src 192.168.178.6 metric 600
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.100
192.168.178.0/24 dev wlx30de4be0e290 proto kernel scope link src 192.168.178.6 metric 600
192.168.178.1 dev wlx30de4be0e290 proto dhcp scope link src 192.168.178.6 metric 600
|
| ip n s
192.168.178.1 dev wlx30de4be0e290 lladdr 50:e6:36:91:c8:2c REACHABLE
192.168.178.54 dev wlx30de4be0e290 lladdr 34:48:ed:9f:b2:a5 REACHABLE
192.168.1.200 dev enp4s0 FAILED
2003:ce:c74f:7c00:7e4d:8fff:fe4b:a22e dev wlx30de4be0e290 lladdr 7c:4d:8f:4b:a2:2e STALE
fe80::52e6:36ff:fe91:c82c dev wlx30de4be0e290 lladdr 50:e6:36:91:c8:2c router STALE
fe80::7e4d:8fff:fe4b:a22e dev wlx30de4be0e290 lladdr 7c:4d:8f:4b:a2:2e STALE
fe80::52e6:36ff:fe91:c82c dev enp4s0 lladdr 50:e6:36:91:c8:2c router STALE
|
| ip r g 1.1.1.1
1.1.1.1 via 192.168.178.1 dev wlx30de4be0e290 src 192.168.178.6 uid 1000
cache
|
Als Ergänzung: Für den Adapter am Ethernet Port benötige ich eine feste IP-Adresse. Diese ist am Server auf 192.168.1.100 gesetzt. Der Waveshare Adapter hat die 192.168.1.200. Die Verbindung dahin funktioniert auch Einwandfrei. DJKUhpisse schrieb: Versuch IPV6 zu deaktivieren.
Fritzbox neugestartet und aktuelles Update eingespielt.
MTU Größe vom WLAN Adapter reduziert.
Nameserver in resolvd.conf geändert und explizit die Fritzbox und 8.8.8.8 hinterlegt.
Den systemd-resolved Dienst deaktiviert.
dns=default in der Networkmanager.conf eingetragen.
Das machst du jetzt bitte alles rückgängig und zeigst dann ip a
Die Änderungen sind Rückgängig gemacht, ip a Ausgabe hängt oben an. kB schrieb: dapaul schrieb: […] ein Ubuntu Server einige Webseiten nicht mehr aufrufen kann
Normalerweise ist ein Server ungeeignet zum Surfen. Welches ISO-Abbild hast Du bei der Installation benutzt,
entweder das für Server (gemäß Deiner Angabe) oder das für Desktops (nur solche erlauben Surfen)? Zeige bitte:
uname -a
cat /etc/lsb-release Welches Programm verwendest Du zur Konfiguration des Netzwerks, systemd-networkd oder NetworkManager oder was sonst? Zeige bitte:
networkctl
nmcli device | cat
Es ist der Ubuntu Server 22.04.3 LTS installiert. Der erwähnte RJ45 zu ETH Adapter hat eine Weboberfläche zur Konfiguration. Aus diesem Grund ist xfce als Desktop nach installiert und der Chromium Browser. Darüber konnte ich die Webseiten Aufrufe ebenfalls testen. Das ist auch der einzige Grund für den "Notfall" Desktop, sonst würde die Server Version ausreichen.
Welches Programm verwendest Du zur Konfiguration des Netzwerks, systemd-networkd oder NetworkManager oder was sonst?
Genau das würde ich auch gern wissen. Ich habe keine eigene Anpassung oder Installation vorgenommen, außerhalb der Ubuntu Server Installation. In der xfce-Oberfläche kann ich keinerlei Konfiguration vornehmen, dort ist alles gesperrt oder nicht vorhanden, dies geschieht alles per SSH. Die Grundkonfiguration habe ich über netplan vorgenommen und dafür die Datei /etc/netplan/00-installer-config.yaml angepasst, diese sieht wie folgt aus:
network:
ethernets:
enp4s0:
dhcp4: false
addresses: [192.168.1.100/24]
gateway4: 192.168.1.200
version: 2
wifis:
wlx30de4be0e290:
dhcp4: true
optional: true
nameservers:
addresses:
- 192.168.178.1
- 8.8.8.8
access-points:
"WLAN":
password: "password" Anbei noch deine gewünschten infos: | uname -a
Linux wyse 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
|
| cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
|
| networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp4s0 ether routable configured
3 wlx30de4be0e290 wlan routable configured
3 links listed.
|
| nmcli device | cat
DEVICE TYPE STATE CONNECTION
enp4s0 ethernet unmanaged --
lo loopback unmanaged --
wlx30de4be0e290 wifi unmanaged --
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14206
|
dapaul schrieb: Denn: Die IP 192.168.1.200 ist die Adresse vom RJ45 zu ETH Adapter von Waveshare, der am Ethernet Port hängt. Somit nutzt der Server den falschen Netzwerk Adapter, denn die Pings sollten ja ins Internet über WLAN laufen und nicht den Ethernet Adapter abfragen.
ip n s
192.168.1.200 dev enp4s0 FAILED
fe80::52e6:36ff:fe91:c82c dev enp4s0 lladdr 50:e6:36:91:c8:2c router STALE
Über das enp4s0-Interface geht z. Zt. kein IPv4-Traffic. Installiere arping aus iputils-arping und mach mal einen arping zu der IPv4:
sudo arping -c 3 -I enp4s0 192.168.1.200
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 9424
Wohnort: Münster
|
dapaul schrieb: […]
Es ist der Ubuntu Server 22.04.3 LTS installiert. […] Ich habe keine eigene Anpassung oder Installation vorgenommen, außerhalb der Ubuntu Server Installation.
Dann verwendest Du systemd-networkd zur Konfiguration des Netzwerks, was ja networkctl auch anzeigt. Die Konfigurationsdateien dafür werden ggf. durch Netplan erstellt und finden sich dann unter /run/…. Checke das. Voraussetzung sind natürlich syntaktisch richtige Konfigurationsdateien. Checke das auch.
| networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp4s0 ether routable configured
3 wlx30de4be0e290 wlan routable configured
3 links listed.
|
systemd-networkd kann allerdings WLAN-Verbindungen nicht auf Layer-2 einrichten, das muss man selbst über wpa_supplicant machen. Das Paket sollte mit dem von Dir installierten Desktop bereits installiert sein. Bei Desktop-Installationen (beachte: Desktop-Installation ≠ Desktop nachträglich installiert) läuft die Einrichtung von WLAN-Verbindungen auf Layer-2 über NetworkManager , der dafür seinerseits mit wpa_supplicant spricht. NetworkManager scheint bei Dir zwar ebenfalls vorhanden zu sein, ist aber funktionslos. Eine auf Layer-2 eingerichtete WLAN-Verbindung kann per systemd-networkd weiter auf Layer-3 konfiguriert werden. Wenn Du einen Rechner mit mehr als einer Netzwerk-Schnittstelle (abgesehen von lo ) hast, ist das technisch auch ein Router. Du musst also die Leitwege Deinen Bedürfnissen entsprechend konfigurieren. Konsultiere das Wiki. PS: bemühe Dich bitte um bessere Übersichtlichkeit. Vermeide Vollzitate und Antworten auf mehrere Beiträge in einem Beitrag. Fasse Dich kurz.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 9424
Wohnort: Münster
|
dapaul schrieb: […]
ip r
default via 192.168.1.200 dev enp4s0 proto static
default via 192.168.178.1 dev wlx30de4be0e290 proto dhcp src 192.168.178.6 metric 600
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.100
192.168.178.0/24 dev wlx30de4be0e290 proto kernel scope link src 192.168.178.6 metric 600
192.168.178.1 dev wlx30de4be0e290 proto dhcp scope link src 192.168.178.6 metric 600
Das ist wohl Unfug. Entferne diesen Leitweg.
|
dapaul
(Themenstarter)
Anmeldungsdatum: 2. Februar 2024
Beiträge: 6
|
Hallo kB, kB schrieb: dapaul schrieb: […]
ip r
default via 192.168.1.200 dev enp4s0 proto static
default via 192.168.178.1 dev wlx30de4be0e290 proto dhcp src 192.168.178.6 metric 600
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.100
192.168.178.0/24 dev wlx30de4be0e290 proto kernel scope link src 192.168.178.6 metric 600
192.168.178.1 dev wlx30de4be0e290 proto dhcp scope link src 192.168.178.6 metric 600
Das ist wohl Unfug. Entferne diesen Leitweg.
Warum sollte ich das entfernen? Ich brauche eine statische IP-Adresse am Ethernet Port, da dort mein Waveshare RJ45->Eth Konnektor angebunden ist. Dafür benötige ich eine statische IP-Adresse im Bereich 192.168.1.xxx. Das habe ich definiert, sonst kann ich die Daten, die mir der Konnektor zur Verfügung stellt, nicht auswerten. Das auslesen und ggf. zurück schreiben von Daten über das Modbus Protokoll musss über enp4s0 laufen. Alles andere über WLAN. Das ist die eigentliche Aufgabe. Zur Besseren Übersicht habe ich euch ein Bild angehängt mit der Netzwerkübersicht. Gruß
- Bilder
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14206
|
dapaul schrieb: Warum sollte ich das entfernen?
Weil Du keine (zusätzliche) default route über das Lan-Interface brauchst, oder? Die definierte Route in das 192.168.1.0/24-Subnetz funktioniert z. Zt. aber nicht. Siehe:
arp -a EDIT: BTW: Bilder werden nicht downloadet.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 9424
Wohnort: Münster
|
dapaul schrieb: […] kB schrieb: dapaul schrieb: […]
ip r
default via 192.168.1.200 dev enp4s0 proto static
default via 192.168.178.1 dev wlx30de4be0e290 proto dhcp src 192.168.178.6 metric 600
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.100
192.168.178.0/24 dev wlx30de4be0e290 proto kernel scope link src 192.168.178.6 metric 600
192.168.178.1 dev wlx30de4be0e290 proto dhcp scope link src 192.168.178.6 metric 600
Das ist wohl Unfug. Entferne diesen Leitweg.
Warum sollte ich das entfernen?
Weil Du Dich hier darüber beschwerst, dass aller Verkehr fälschlicherweise über enp4s0 läuft. Du hast es aber selbst so konfiguriert.
Ich brauche eine statische IP-Adresse am Ethernet Port, da dort mein Waveshare RJ45->Eth Konnektor angebunden ist. Dafür benötige ich eine statische IP-Adresse im Bereich 192.168.1.xxx. Das habe ich definiert, sonst kann ich die Daten, die mir der Konnektor zur Verfügung stellt, nicht auswerten. Das auslesen und ggf. zurück schreiben von Daten über das Modbus Protokoll musss über enp4s0 laufen.
Mag sein. Die Vergabe einer Adresse und die Vergabe einer Route sind aber zwei unabhängige Vorgänge. Die Adresse mag richtig sein, eine Default-Route über enp4s0 ist definitiv falsch.
Alles andere über WLAN. Das ist die eigentliche Aufgabe.
Müsste ja auch funktionieren, sobald Du auf die falsche Default-Route verzichtest.
|
dapaul
(Themenstarter)
Anmeldungsdatum: 2. Februar 2024
Beiträge: 6
|
Hallo zusammen, ein kleines Update zum Problem. Die Route:
| default via 192.168.1.200 dev enp4s0 proto static
|
hatte ich entfernt. Damit kam ich zwar wieder ins Internet und die Pings liefen wieder. Aber der Connect zum WaveShare Connector klappte nicht mehr. Ich habe die feste IP in der Netplan Konfig wieder eingetragen und bis jetzt läuft weiterhin alles wie es eigentlich soll.
Per Ethernet komme ich an den WaveShare Connector und über WLAN ins Internet. 😳 Von daher habe ich Thread als gelöst markiert, aber ohne wirklich zu wissen was der Schluckauf war. 😬 Danke für eure Unterstützung. Gruß
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14206
|
dapaul schrieb: Ich habe die feste IP in der Netplan Konfig wieder eingetragen und bis jetzt läuft weiterhin alles wie es eigentlich soll. ..., aber ohne wirklich zu wissen was der Schluckauf war. 😬
Wie ist jetzt die Ausgabe von:
ip r
?
|
dapaul
(Themenstarter)
Anmeldungsdatum: 2. Februar 2024
Beiträge: 6
|
Hi lubux, anbei der Auszug:
| ip r
default via 192.168.178.1 dev wlx30de4be0e290
default via 192.168.178.1 dev wlx30de4be0e290 proto static metric 600
default via 192.168.178.1 dev wlx30de4be0e290 proto dhcp metric 600
169.254.0.0/16 dev enp4s0 scope link metric 1000
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.100 metric 100
192.168.178.0/24 dev wlx30de4be0e290 proto kernel scope link src 192.168.178.6 metric 600
|
Interessanterweise ist die static Route über 192.168.1.200 nicht mehr aufgelistet. Anbei die aktuelle Netplan Konfig, diese ist leicht modifiziert zum Startpost. Der ping ging erst raus, nachdem ich die Adresse bei enp4s0 raus genommen habe und am Ende wieder eingesetzt habe. Ich habe ein paar Tests mit den Routing ausprobiert. # This is the network config written by 'subiquity'
network:
ethernets:
enp4s0:
# dhcp4: no
addresses: [192.168.1.100/24]
version: 2
renderer: NetworkManager
wifis:
wlx30de4be0e290:
dhcp4: true
dhcp6: true
optional: true
routes:
- to: 0.0.0.0/0
via: 192.168.178.1
- to: ::/0
via: fd00::52e6:36ff:fe91:c82c/64
nameservers:
addresses:
- 192.168.178.1
# - 8.8.8.8
# - 1.1.1.1
access-points:
"WLAN":
password: ""
Gruß
|