Raspberry Pi 4 // OpenVPN

matahari · Nov 18th 2021

Hallo zusammen,

ich verzweifele gerade ein wenig am Upgrade von Raspbian und / oder der Model 4... Vielleicht kann mir jemand helfen.

Situation: Ich habe vor ein paar Jahren unter Jessie transparente VPN-Tunnel-Endpunkte gebaut. Die liefen auch im Grunde ohne Probleme, allerdings war die sichere Stromversorgung ab und an ein Problem. Es konnte also passieren, das der Strom ausfiel - und das resultierte ab und an in korrupten SD-Karten.

Nun wollte ich mir das Overlay-Filesystem zunutze machen und habe mir 2 RP 4 Model B besorgt. Die konnten mit meiner Jessie-Version natürlich nichts anfangen. Also habe ich zuerst auf Stretch und dann auf Buster aktualisiert. Das zog sich recht lange hin, funktioniert unterm Strich aber ohne Fehlermeldung. Dann habe ich die SD-Karte in den 4er gesteckt, der bootet dann aber mit dem Regenbogen-Vollbild (vorher war eine Meldungsfenster "This board requires newer software"). boot_delay steht auf 30

Testweise habe ich die SD-Karte in einem RP 3 Model B+ getestet, da läuft sie auch durch. Da werde ich mit dem 1GB Arbeitsspeicher aber wohl nicht auskommen...

Ich bin ratlos was es sein kann. Ein Original-Netzteil war nicht zu bekommen und ich habe keines mehr. Ich habe einen Schnellader mit 2,4A, mein Oneplus Nord WarpCharger mit 2,1 und eine Powerbank mit 2,1A versucht. Was mich stutzig macht ist, dass das Ding mit einem falschen Image durchaus ein Bild zeigt, mit dem Image aber nicht. Es hängen keine weiteren Geräte am Pi, nichtmal Tastatur oder Maus. Ein zweiter Versuch mit einem anderen Image und einer anderen Karte war seltsamerweise erfolgreich. Blöde ist, eine Intenso-Billo-Karte tut es, eine Sandisk Ultra leider nicht. Bisher habe ich nie Probleme mit den Dingern gehabt, aber die 4er scheinen mich nicht zu mögen.

Kann die Karte das Problem sein? Es geht um diese Karte (Affiliate-Link). Oder hat vielleicht jemand eine andere Idee?

Danke!

Matze

fred0815 · Nov 18th 2021

Bullseye ist das aktuelle Image:

https://www.raspberrypi.com/software/operating-systems/

schlizbäda · Nov 18th 2021

Entgegen anderslautender Aussagen hatte ich noch nie Probleme, die auf einen bestimmten Typ SD-Karte zurückzuführen war. Gut, ich verwende nur namhafte SD-Karten (Sandisk, Kingston, Samsung, ~~Intenso~~* ) aus vertrauenswürdigen Läden , keine obskuren China-Fakes. Daher glaube ich nicht, dass es an der verlinkten SD-Karte liegt (wenn sie auch wirklich aus dieser Quelle stammt).

Probiere anstatt eines aufwändigen Updates Jessie-->Stretch-->Buster(-->Bullseye) lieber mal, das aktuelle Image von der Foundation herunterzuladen und auf die SD-Karte (z.B. mit dem Raspberry Pi Imager der Foundation) zu flashen.

Netzteil:

Bei Handyladegeräten (Zitat: "... Charger") ist das Mysterium™ aller Ausreden zum Trotz nicht zu vermeiden! Am Originalnetzteil führt in Fällen wie Deinem kein Weg vorbei!

(so nix für ungut, jetzt bin ich meinen üblichen Klugschiss mal wieder losgeworden )

*) EDIT 04.02.2022:

Mit den Intenso-Karten bin ich durch!
Die intenso SD HC 32GB Class 10 ist dermaßen drexlangsam, dass du dem RPi unterm Betrieb ~~die Schuhsohlen~~ das RAM aufdoppeln kannst! Sie haben mich damit (anstelle von Sandisk Extrme) in der Firma beglückt, weil die einen Euro billiger waren

Wir hatten zwei: Die eine ist nach wirklich wenigen Schreibzugriffen verreckt, d.h. sie war nicht mehr beschreibbar. Und das, obwohl ich das System rechtzeitig (ganz großes ) auf ein overlay-fs umgestellt habe.
Die andere funzt zwar noch, aber da schläft man ein

fred0815 · Nov 18th 2021

Nachtrag: Wenn du ein aktuelles OS hast, kannst du das OS, das EEPROM und die Firmware des Pi4 auch gleich noch mit sudo apt-update && apt dist-upgrade auf den neuesten Stand bringen.

Quote from schlizbäda

Netzteil:

Bei Handyladegeräten (Zitat: "... Charger") ist das Mysterium™ aller Ausreden zum Trotz nicht zu vermeiden! Am Originalnetzteil führt in Fällen wie Deinem kein Weg vorbei!

Das kann man meist so unterschreiben. Man kann aber auch Glück haben.

So wie bei meinem Handyladegerät, da läuft der Pi4 mit Touchscreen, Maus und Tastatur problemlos.

hyle · Nov 18th 2021

Quote from matahari

Ein Original-Netzteil war nicht zu bekommen und ich habe keines mehr.

https://www.amazon.de/-/en/Ras…ower-supply/dp/B07TMPC9FG

https://buyzero.de/products/ra…pi-15-w-usb-c-netzteil-eu

https://www.berrybase.de/detail/index/sArticle/5924

https://www.reichelt.de/raspbe…NTRY=445&LANGUAGE=de&&r=1

etc.

RTFM · Nov 18th 2021

Es kann auch an einer zu kleinen Boot-Partition liegen. Ab Buster sind 256 MB erforderlich, damit alle Binarys für diverse Prozessoren/SoCs Platz haben.

Servus !

framp · Nov 18th 2021

Quote from matahari

Also habe ich zuerst auf Stretch und dann auf Buster aktualisiert.

Das wird nicht offiziell von der Foundation unterstuetzt und nicht empfohlen. Es kann klappen - aber eben auch Probleme hervorrufen die Du sonst nicht haettest. Und dann suchst Du Dir den Wolf ... Ich upgrade deshalb nie sondern installiere immer das neue OS Release von Scratch. Das ist zwar i.d.R. etwas aufwaendiger wenn alle moeglichen installierten Applikationen und Dienste wieder neu aufgesetzt und konfiguriert werden muessen. Aber man hat nicht das Risiko Probleme zu bekommen die man sonst nicht haette

matahari · Nov 18th 2021

Ok, ich lade mir mal auf eine Karte ein frisches OS und versuche das openVPN-Gelumpe identisch draufzubekommen. Bis die neuen Netzteile am Sonnabend kommen kann ich da ja schon mal eine Testumgebung basteln Und dann darf ich das Gehäusedesign auch noch ändern, weil´s ja usb-c sein muss *grr*

Mal sehen wie sich das entwickelt...

matahari · Nov 19th 2021

Erwartungsgemäß geht es nicht mehr. Nachdem meine Anleitung für OpenVPN nicht mehr passt habe ich pivpn versucht. Naja, ich ziehe mir jetzt noch einmal das Image frisch auf die Karte. Offensichtlich hat pivpn meine Netzwerkschnittstellen verändert, da ist jetzt keine mehr :i

Hat jemand eine Seite mit einer aktuellen Anleitung für OpenVPN die funktioniert?

rpi444 · Nov 19th 2021

Quote from matahari

Hat jemand eine Seite mit einer aktuellen Anleitung für OpenVPN die funktioniert?

Als ich noch OpenVPN u. a. auch mit meinen PIs benutzt habe, bin ich immer wie im Wiki von UU vorgegangen:

https://wiki.ubuntuusers.de/OpenVPN/

matahari · Nov 22nd 2021

Vielen Dank rpi444, das hat prinzipiell schon mal funktioniert. Der Tunnel wird aufgebaut, nur Daten gehen keine drüber. Ich bekomme die Meldung

Code

WRR2021-11-22 18:31:29 us=721849 antenne1/192.168.101.64:48514 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> antenne1/192.168.101.64:48514
2021-11-22 18:31:30 us=723033 antenne1/192.168.101.64:48514 MULTI: Outgoing TUN queue full, dropped packet len=17
R2021-11-22 18:31:36 us=10420 antenne1/192.168.101.64:48514 MULTI: Learn: 02:00:50:b6:28:0f@0 -> antenne1/192.168.101.64:48514
2021-11-22 18:31:37 us=11580 antenne1/192.168.101.64:48514 MULTI: Outgoing TUN queue full, dropped packet len=71

Die Meldung TUN quere full kommt sobald Daten fließen wollen - also PING genügt.

Meine Server-Konfiguration ist im großen und ganzen vom alten übernommen

Code

dev tap
proto tcp
port 24365

#files
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/openvpn-server.crt
key /etc/openvpn/pki/private/openvpn-server.key
dh /etc/openvpn/pki/dh.pem
user nobody
group nogroup
#allow-compression yes          #obsolet
#comp-lzo

server-bridge 10.10.10.254 255.255.255.0 10.10.10.200 10.10.10.230
persist-key
#persist-tun
status openvpn-status.log
verb 5

#client-to-client
push "redirect-gateway def1"
#set the dns servers
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

#script on change
script-security 3 #system
up "/etc/openvpn/up"
down "/etc/openvpn/down"

Display More

Ich finde meinen Fehler nicht, und die gefundenen Lösungsansätze konnten mir auch nicht helfen.

Der Client bricht dann nach relativ kurzer Zeit entnervt ab...

Code

2021-11-22 17:28:04 us=575901 Preserving previous TUN/TAP instance: tap0
2021-11-22 17:28:04 us=575941 Initialization Sequence Completed
WWWWWW2021-11-22 17:29:04 us=705045 [vpnserver] Inactivity timeout (--ping-restart), restarting
2021-11-22 17:29:04 us=705626 TCP/UDP: Closing socket
2021-11-22 17:29:04 us=705887 SIGUSR1[soft,ping-restart] received, process restarting

Da scheint noch irgendwas zu fehlen was früher nicht notwendig war - oder ich finde es nicht mehr.

Hat jemand dazu eine Idee?

Nachtrag: Die Meldung variiert...

Code

R2021-11-22 18:50:04 us=424090 antenne1/192.168.101.64:48558 Can't learn ff:00:50:b6:28:0f@0: network is a multicast address
2021-11-22 18:50:04 us=424198 antenne1/192.168.101.64:48558 MULTI: bad source address from client [ff:00:50:b6:28:0f@0], packet dropped
R2021-11-22 18:50:05 us=444488 antenne1/192.168.101.64:48558 Can't learn ff:00:50:b6:28:0f@0: network is a multicast address
2021-11-22 18:50:05 us=444695 antenne1/192.168.101.64:48558 MULTI: bad source address from client [ff:00:50:b6:28:0f@0], packet dropped

rpi444 · Nov 22nd 2021

Quote from matahari

Da scheint noch irgendwas zu fehlen was früher nicht notwendig war - oder ich finde es nicht mehr.

Wie sind auf Server und Client, die Ausgaben von:

Code

ip a
route -n
arp -av
sudo iptables -nvx -L
sudo iptables -nvx -L POSTROUTING -t nat

, wenn openvpn und das bridge-Script gestartet sind.

BTW: Gibt es einen bestimmten Grund, warum Du ethernet-bridging mit OpenVPN benutzt?

matahari · Nov 22nd 2021

Ja, die Geräte die ich verbinde reden Broadcast. Das kann ich leider nicht ändern. Ich muss also auf beiden Seiten das gleiche Netz haben.

Hier die Ausgaben:

Code

SERVER
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:5f:01:71:b0:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.66/24 brd 192.168.101.255 scope global dynamic noprefixroute eth0
       valid_lft 6885sec preferred_lft 5582sec
    inet6 fe80::195d:f33e:7c4a:f839/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether e4:5f:01:71:b0:0d brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 00:50:b6:28:14:b6 brd ff:ff:ff:ff:ff:ff
    inet 169.254.237.152/16 brd 169.254.255.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:50:b6:28:14:b6 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.253/24 brd 10.10.10.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::250:b6ff:fe28:14b6/64 scope link
       valid_lft forever preferred_lft forever

route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.101.1   0.0.0.0         UG    202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     204    0        0 eth1
192.168.101.0   0.0.0.0         255.255.255.0   U     202    0        0 eth0

arp -av
? (10.10.10.252) at <incomplete> on br0
? (192.168.101.1) at c0:c9:e3:da:06:24 [ether] on eth0
? (192.168.101.84) at 30:05:5c:79:e6:22 [ether] on eth0
? (192.168.101.64) at e4:5f:01:71:af:bb [ether] on eth0
Entries: 4      Skipped: 0      Found: 4







CLIENT

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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:5f:01:71:af:bb brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.64/24 brd 192.168.101.255 scope global dynamic noprefixroute eth0
       valid_lft 6892sec preferred_lft 5722sec
    inet6 fe80::9b2a:b744:7029:dc95/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether e4:5f:01:71:af:bc brd ff:ff:ff:ff:ff:ff
4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    link/ether 00:50:b6:28:0f:1b brd ff:ff:ff:ff:ff:ff
5: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:50:b6:28:0f:1b brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.252/24 brd 10.10.10.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::250:b6ff:fe28:f1b/64 scope link
       valid_lft forever preferred_lft forever

route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.101.1   0.0.0.0         UG    202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.101.0   0.0.0.0         255.255.255.0   U     202    0        0 eth0

arp -av
? (192.168.101.1) at c0:c9:e3:da:06:24 [ether] on eth0
? (192.168.101.84) at 30:05:5c:79:e6:22 [ether] on eth0
? (192.168.101.118) at c8:60:00:6e:51:f1 [ether] on eth0
? (192.168.101.66) at e4:5f:01:71:b0:0c [ether] on eth0
Entries: 4      Skipped: 0      Found: 4

Display More

iptables gibt nichts, bei der alten Version habe ich etwas in sudo iptables -nvx -L POSTROUTING -t nat, das stand

Code

Chain POSTROUTING (policy ACCEPT 89 packets, 7301 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 MASQUERADE  all  --  *      eth0    10.0.0.0/8          !10.0.0.0/8

Ich kann mich daran nicht mehr erinnern, allerdings kommt mir "out eth0" seltsam vor - aber wie gesagt, das war auf dem alten funktionierenden RP 2 Model B...

Physikalisch sieht es so aus, das die onboard-Netzwerkkarte per DHCP mit dem Internet verbunden ist und eine USB-Netzwerkkarte an die beiden Geräte angeschlossen ist die kommunizieren sollen. Das lokale Gerät hat eine feste IP-Adresse 10.10.10.10. Wenn der Tunnel steht, also der Server kann den Client pingen, dann wird noch folgendes Python-Script gestartet

Code

os.system("sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to 10.10.10.10:80")
os.system("sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.10.10.10:80")
os.system("sudo iptables -t nat -A POSTROUTING -p tcp -d 10.10.10.10 --dport 80 -j MASQUERADE")

Das war bisher aber noch nicht der Fall

rpi444 · Nov 22nd 2021

Quote from matahari

Ja, die Geräte die ich verbinde reden Broadcast. Das kann ich leider nicht ändern. Ich muss also auf beiden Seiten das gleiche Netz haben.

Hier die Ausgaben:

Code

SERVER
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:50:b6:28:14:b6 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.253/24 brd 10.10.10.255 scope global br0

10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 br0

arp -av
? (10.10.10.252) at <incomplete> on br0

CLIENT

5: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:50:b6:28:0f:1b brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.252/24 brd 10.10.10.255 scope global br0
      
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 br0

arp -av
? (192.168.101.1) at c0:c9:e3:da:06:24 [ether] on eth0
? (192.168.101.84) at 30:05:5c:79:e6:22 [ether] on eth0
? (192.168.101.118) at c8:60:00:6e:51:f1 [ether] on eth0
? (192.168.101.66) at e4:5f:01:71:b0:0c [ether] on eth0
Entries: 4      Skipped: 0      Found: 4

Display More

Konfiguriere dann mal manuell, den statischen arp-cache-Eintrag beim Server und Client, für das br0-Interface.

BTW: Weil ich keinen Einfluss auf die Subnetze der Clients (peers) habe, benutze ich WireGuard.

Als noch kein WireGuard gegeben hat, habe ich vtun mit tap-Interfaces benutzt.

matahari · Nov 22nd 2021

Code

Konfiguriere dann mal manuell, den statischen arp-cache-Eintrag beim Server und Client, für das br0-Interface.

Öhm, das überfordert mich gerade... Bitte wie mache ich das?

Im Grunde ist es mir egal ob ich openvpn oder irgendetwas anderes nehme. Ich habe die Geräte vor knapp 5 Jahren gebaut, da hat sich die Frage nicht gestellt. Wenn es für Wireguard ein einfacheren Installationsleitfaden gibt kann ich auch wechseln.

rpi444 · Nov 22nd 2021

Quote from matahari
Code
Konfiguriere dann mal manuell, den statischen arp-cache-Eintrag beim Server und Client, für das br0-Interface.
Öhm, das überfordert mich gerade... Bitte wie mache ich das?

Auf dem Server:

Code

sudo arp -i br0 -d 10.10.10.252
sudo arp -i br0 -s 10.10.10.252 00:50:b6:28:0f:1b
arp -av

Auf dem Client:

Code

sudo arp -i br0 -s 10.10.10.253 00:50:b6:28:14:b6
arp -av
ping -c 3 10.10.10.253

Installiere auf Client und Server:

Code

sudo apt update
sudo apt-get install iputils-arping
sudo dpkg --configure -a

Wenn der Ping nicht funktioniert, dann versuch den arping auf dem Client mit:

Code

sudo arping -c 3 -I br0 10.10.10.253
ping -c 3 10.10.10.253

matahari · Nov 22nd 2021

Ändert nichts. Kommt auf dem Server weiterhin

Code

R2021-11-22 21:27:38 us=426003 antenne1/192.168.101.64:36000 Can't learn fb:0a:e7:ed:c6:3e@0: network is a multicast address
2021-11-22 21:27:38 us=426127 antenne1/192.168.101.64:36000 MULTI: bad source address from client [fb:0a:e7:ed:c6:3e@0], packet dropped
R2021-11-22 21:27:39 us=519210 antenne1/192.168.101.64:36000 MULTI: Outgoing TUN queue full, dropped packet len=71
R2021-11-22 21:27:39 us=607231 antenne1/192.168.101.64:36000 Can't learn fb:0a:e7:ed:c6:3e@0: network is a multicast address
2021-11-22 21:27:39 us=607332 antenne1/192.168.101.64:36000 MULTI: bad source address from client [fb:0a:e7:ed:c6:3e@0], packet dropped
R2021-11-22 21:27:50 us=717483 antenne1/192.168.101.64:36000 MULTI: Outgoing TUN queue full, dropped packet len=17

Ich verstehe das nicht. Selbst ohne irgendeine Konfiguration müssten sich Client und Server doch erreichen...

rpi444 · Nov 22nd 2021

Quote from matahari

Ändert nichts. Kommt auf dem Server weiterhin
Ich verstehe das nicht. Selbst ohne irgendeine Konfiguration müssten sich Client und Server doch erreichen...

Dann poste von Server und Client, die Ausgaben von:

Code

ip a s br0
route -n
arp -av

matahari · Nov 22nd 2021

Sehr gerne

Server

Code

ip a s br0
route -n
arp -av
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:50:b6:28:14:b6 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.253/24 brd 10.10.10.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::250:b6ff:fe28:14b6/64 scope link
       valid_lft forever preferred_lft forever
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.101.1   0.0.0.0         UG    202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     204    0        0 eth1
192.168.101.0   0.0.0.0         255.255.255.0   U     202    0        0 eth0
? (192.168.101.84) at 30:05:5c:79:e6:22 [ether] on eth0
? (192.168.101.64) at e4:5f:01:71:af:bb [ether] on eth0
? (10.10.10.252) at 00:50:b6:28:0f:1b [ether] PERM on br0
? (192.168.101.1) at c0:c9:e3:da:06:24 [ether] on eth0
Entries: 4      Skipped: 0      Found: 4

Display More

Client

Code

ip a s br0
route -n
arp -av
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:50:b6:28:0f:1b brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.252/24 brd 10.10.10.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::250:b6ff:fe28:f1b/64 scope link
       valid_lft forever preferred_lft forever
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.10.254    128.0.0.0       UG    0      0        0 br0
0.0.0.0         192.168.101.1   0.0.0.0         UG    202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 br0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 tap0
128.0.0.0       10.10.10.254    128.0.0.0       UG    0      0        0 br0
192.168.101.0   0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.101.66  192.168.101.1   255.255.255.255 UGH   0      0        0 eth0
? (10.10.10.254) at <incomplete> on br0
? (10.10.10.252) at 00:50:b6:28:0f:1b [ether] PERM on br0
? (192.168.101.84) at 30:05:5c:79:e6:22 [ether] on eth0
? (192.168.101.118) at c8:60:00:6e:51:f1 [ether] on eth0
? (192.168.101.1) at c0:c9:e3:da:06:24 [ether] on eth0
? (192.168.101.66) at e4:5f:01:71:b0:0c [ether] on eth0
Entries: 6      Skipped: 0      Found: 6

Display More

rpi444 · Nov 22nd 2021

Quote from matahari

Client

Code

5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:50:b6:28:0f:1b brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.252/24 brd 10.10.10.255 scope global br0
      
? (10.10.10.254) at <incomplete> on br0
? (10.10.10.252) at 00:50:b6:28:0f:1b [ether] PERM on br0

Auf dem Client ist ein Fehler mit dem arp-cache-Eintrag für das br0-Interface.

10.10.10.252 ist doch die IP-Adresse vom Client. Auf dem Client ist kein arp-cache-Eintrag für den server, oder?

BTW: Welches Gerät hat die IP 10.10.10.254?

Raspberry Pi 4 // OpenVPN

matahari Nov 22nd 2021

Similar Threads

Update von Buster auf Bullseye bei Desktop Pi funktioniert nicht

Auf einer SDKarte PyQt5 mit viel rumgespiele ans laufen gebracht, neue Karte und ich bekomme es nicht mehr hin

sudo apt-get upgrade nicht möglich, /dev/root Ordner voll

Installation MotionEye auf Pi4 8GB; Buster Version 10

UPNP DLNA Server Alternative. Der MinimServer - Installation und Betrieb auf dem RasPi (HOWTO)

RPI3B+ von nach normalem Reboot "tot"?

Users Viewing This Thread