Skip to content

NanoPi R2S - OpenWRT

Verschoben NanoPi R2S
  • In diesem Beitrag habe ich ja was mit einem Router rum gespielt. So weit funktional, aber IPv6 fehlt 😞 Da ich damit nun mal gar nicht so richtig klar komme, muss was anderes her.

    Dazu ist mir eingefallen, das der Hersteller des NanoPi R2S ein Image für OpenWRT hat. Das habe ich heute mal installiert. Hatte am Anfang ein kleines Problem mit dem Root Passwort, das hatte ich dann per SSH gesetzt. Am Anfang ist keines gesetzt!

    Ok, die kleinen Startschwierigkeiten erledigt. Danach auf dem Webinterface eingeloggt.

    pic001.png

    Danach ist das dann die Übersicht.

    pic002.png

    Was ich aktuell nicht verstehe, wie bekommt man das System auf eine aktuelle Version?
    b37ef70c-db8a-4dd8-b484-f76d0d28e0d0-grafik.png

    Ich habe dann irgendwo im Netz, das hier gefunden.

    opkg list-upgradable | cut -f 1 -d ' ' | xargs opkg upgrade
    

    Ganz mutig 🙂 mal eingegeben, dann gewartet, danach neugestartet. Die Pakete sind aktualisiert worden, aber an der Versionsnummer hat sich nichts geändert. Meiner Meinung nach ist 19.07.5 aktuell. Ok, es läuft noch, das reicht ja erst mal zum Ausprobieren.

    Sollte hier jemand mitlesen, der weiß wie man OpenWRT auf die aktuellste Version bekommt, ich freue mich immer über Tipps 🙂

    Ich werde jetzt hier kurz ein paar Sachen zeigen, damit Leser die das noch nicht kennen, sich einen ungefähren Eindruck machen können. Für einen kompletten Überblick wird es nicht reichen, das Projekt ist sehr umfangreich.

    Ok, was interessiert?

    Schnittstellen

    pic003.png

    Hier sieht man die LAN Schnittstelle, die eine IPv4 und eine IPv6 Adresse hat. Dann die WAN Schnittstellen, einmal IPv4, einmal IPv6.

    Firewall

    pic004.png

    Hier die Grundeinstellungen.

    Wireguard

    eee94efb-5682-4233-8807-92f50f918b1e-grafik.png

    Da wird nicht viel angezeigt, so das ich mal auf der Konsole nachgeschaut habe.

    root@FriendlyWrt:~# wg version
    wireguard-tools v1.0.20191226 - https://git.zx2c4.com/wireguard-tools/
    

    Ziemlich altes Wireguard...

    Fazit

    Läuft auf dem kleinen R2S ganz flott, UI lässt sich gut bedienen. Das macht im Moment den Eindruck, das man sich damit mal beschäftigen könnte. Morgen mal VLANs testen 🙂

  • Ich bin kein vi Fan, also mal das Paket nano nachinstalliert. Die Datei angepasst.

    /etc/config/network

    config interface 'loopback'
            option ifname 'lo'
            option proto 'static'
            option ipaddr '127.0.0.1'
            option netmask '255.0.0.0'
    
    config globals 'globals'
            option ula_prefix 'fd4c:f40c:35e2::/48'
    
    config interface 'lan100'
            option type 'bridge'
            option ifname 'eth1.100'
            option proto 'static'
            option ipaddr '192.168.2.1'
            option netmask '255.255.255.0'
            option ip6assign '60'
    
    config interface 'lan200'
            option type 'bridge'
            option ifname 'eth1.200'
            option proto 'static'
            option ipaddr '192.168.3.1'
            option netmask '255.255.255.0'
            option ip6assign '60'
     
    config device
            option type '8021q'
            option ifname 'eth1.100'
            option vid '100'
            option name 'vlan1'
    
    config device
            option type '8021q'
            option ifname 'eth1.200'
            option vid '200'
            option name 'vlan2'
     
    config interface 'wan'
            option ifname 'eth0'
            option proto 'dhcp'
    
    config interface 'wan6'
            option ifname 'eth0'
    option proto 'dhcpv6'
    

    Schnittstelle im UI neugestartet und ausprobiert. Funktioniert so weit. Nicht ganz sicher, ob alles richtig ist, morgen noch mal intensiver ran.

    pic005.png

    Manche Dinge muss man direkt erledigen 🙂

  • Da stimmt einiges nicht, so das ich einen neuen Beitrag erstellt habe. Bitte beachten!

    https://forum.frank-mankel.org/topic/917/nanopi-r2s-openwrt-vlan

  • Hallo Frank, ich habe auch das NanoPI R2S und bin eigentlich sehr zufrieden. So wie du habe ich mit dem Friendly Build begonnen, und ja: es ist etwas outdated, ich habe allerdings noch keine Nachteile gefunden. Ich tunnele noch meinen ganzen Traffic durchs VPN, das geht auch orima mit dem Nanopi.
    Das 'echte' OpenWRT build hatte ich nicht zum Laufen bekommen, ging das bei dir einwandfrei? Vielleicht geb ich dem nochmal ne Chance, das Friendly soll angeblich nicht updatebar sein.
    Ich hab den kleinen übrigens nie in eine Gehäuse gesteckt und bekomm Ihn so eigentlich kaum über 49°C.
    VG Thrak

  • @thrakath1980 Hallo, Willkommen im Forum.

    Falls es so rüber gekommen ist, das ich den R2S nicht mag, ganz im Gegenteil. Absolut geile Baugröße. Mit dem Gehäuse, absolute Spitzenqualität, ein echter Hingucker.

    Das FriendlyArm wollte ich eigentlich nur loswerden, weil ich ja doch dann lieber auf's Original setze. Obwohl ich im Prinzip immer noch ein klein wenig am OpenWRT verzweifel, aber es wird besser 🙂

    Den OpenWRT Build habe ich einwandfrei drauf bekommen. Hier der Beitrag dazu.

    Ich habe ja auch noch einen R4S bestellt 😉 Mal schauen, wie der sich so macht. Durch einen Tipp habe ich aktuell an meiner Leitung ja den Ubiquiti ER-X und bin mehr als zufrieden. Das OpenWRT ist schon klasse, wenn man es mal verstanden hat. Ich vermisse ja so ein wenig meine pfSense 😢 Aber mit der stimmt was nicht, ich hatte immer massive Probleme bei Youtube und zuletzt auch an der PS4, seit dem der ER-X das managt alles volle Pulle!

  • @thrakath1980 Ich wollte noch auf ein Thema zurück kommen. Das Original OpenWRT auf dem R2S ist ja ein Snapshot. Den kann man ohne Probleme aktualisieren. Unten ist dann ein Haken mit "Keep settings...."

    Gerade probiert, ging einwandfrei. Netzwerkeinstellungen und Firewall Settings blieben erhalten.

  • NanoPi R4S - eingetroffen

    Verschoben NanoPi R4S
    3
    0 Stimmen
    3 Beiträge
    459 Aufrufe
    FrankMF

    Mal ein Screenshot von den Temperaturen mit OpenWrt.

    d086e090-9c05-4a9d-8a86-fcf5d423d4f6-grafik.png

  • NanoPi R2S - OpenWRT VLAN

    Verschoben NanoPi R2S
    11
    0 Stimmen
    11 Beiträge
    1k Aufrufe
    FrankMF

    @thrakath1980 Ok, du meinst die FriendlyArm Variante von OpenWRT. Ich denke, da sollte man besser alles neu machen. Leider ist das bei OpenWRT nicht so einfach zu updaten/upgraden wie z.B. bei einem Linux Kernel. Ich habe es mal runtergeladen, wenn ich mal Zeit habe, schau ich mal rein.

  • 0 Stimmen
    2 Beiträge
    722 Aufrufe
    FrankMF

    Nachdem ich die Tage feststellen musste, das irgendwas mit dem Gerät nicht stimmte, bekam keine DNS Auflösung über die Konsole, habe ich das heute mal eben neuinstalliert.

    Armbian ist ja immer was spezielles 🙂 Hat sich bis heute nix dran geändert.....

    Ok, dann heute mal eben ein neues Image erstellt. Download Gewählt habe ich das Armbian Buster.

    Image auf die SD-Karte, eingeloggt. Alles wie oben erstellt und abgespeichert. Neustart, geht wieder alles. 😍

    root@192.168.3.15's password: _ _ _ ____ ____ ____ | \ | | __ _ _ __ ___ _ __ (_) | _ \|___ \/ ___| | \| |/ _` | '_ \ / _ \| '_ \| | | |_) | __) \___ \ | |\ | (_| | | | | (_) | |_) | | | _ < / __/ ___) | |_| \_|\__,_|_| |_|\___/| .__/|_| |_| \_\_____|____/ |_| Welcome to Debian GNU/Linux 10 (buster) with Linux 5.9.11-rockchip64 System load: 2% Up time: 11 min Memory usage: 10% of 978M IP: 192.168.3.15 192.168.1.1 192.168.2.1 CPU temp: 61°C Usage of /: 5% of 29G Last login: Sun Dec 6 12:28:10 2020 from 192.168.3.213 Kernelversion root@nanopi-r2s:~# uname -a Linux nanopi-r2s 5.9.11-rockchip64 #20.11.1 SMP PREEMPT Fri Nov 27 21:59:08 CET 2020 aarch64 GNU/Linux ip a oot@nanopi-r2s:~# 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 b2:b5:10:38:9e:76 brd ff:ff:ff:ff:ff:ff inet 192.168.3.15/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 6360sec preferred_lft 6360sec inet6 2a02:908:xxxxxx/64 scope global dynamic mngtmpaddr valid_lft 7196sec preferred_lft 596sec inet6 fe80::b0b5:10ff:fe38:9e76/64 scope link valid_lft forever preferred_lft forever 3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff 4: lan0.100@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global lan0.100 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever 5: lan0.200@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.2.1/24 brd 192.168.2.255 scope global lan0.200 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever

    Vom Notebook aus funktioniert auch alles. So weit bin ich zufrieden. Jetzt mal langsam anfangen, der Kiste IPv6 beizubringen. Oje, nicht gerade mein Lieblingsthema...

    Bis der NanoPi R4S hier ankommt und ein vernünftiges Image hat, vergeht ja noch was Zeit...

  • NanoPi R2S

    Verschoben NanoPi R2S
    6
    0 Stimmen
    6 Beiträge
    1k Aufrufe
    FrankMF

    Ok, die Netwerkkonfiguration will nicht so wie ich. 😕

    Der Netzwerkmanager ist das Problem! Da ich den auf einem headless System nicht brauche, deaktivieren wir diesen.

    nano /etc/NetworkManager/NetworkManager.conf

    Da steht folgendes drin

    [main] dns=default rc-manager=file plugins=ifupdown,keyfile [ifupdown] managed=true

    Die letzte Zeile ändern wir in

    [ifupdown] managed=false

    Danach ein Neustart. Und siehe da, meine doppelten IP-Adressen sind auch weg.

    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether b2:b5:10:38:9e:76 brd ff:ff:ff:ff:ff:ff inet 192.168.3.12/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 7116sec preferred_lft 7116sec inet6 2a02:908:1268:1d50:b0b5:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 7185sec preferred_lft 585sec inet6 fe80::b0b5:10ff:fe38:xxxx/64 scope link valid_lft forever preferred_lft forever

    Zur Kontrolle, eben nochmal neugestartet und nachgeschaut. Perfekt, passt jetzt.

    Das Firewall Script in den Autostart und dann mal die Tage schaue, wie er sich so macht.

  • Nextcloud - Upgrade auf 19.0.1

    Nextcloud
    1
    0 Stimmen
    1 Beiträge
    213 Aufrufe
    Niemand hat geantwortet
  • Debian Buster 10 Release

    Linux
    3
    0 Stimmen
    3 Beiträge
    376 Aufrufe
    FrankMF

    Da man ja beim Login auswählen kann, mit was die Session startet, war ich doch jetzt etwas neugierig was überhaupt läuft.

    IMG_20190707_092217.jpg

    frank@debian:~$ echo $WAYLAND_DISPLAY frank@debian:~$ loginctl SESSION UID USER SEAT TTY 7 1000 frank seat0 tty2 c1 116 Debian-gdm seat0 tty1 2 sessions listed. frank@debian:~$ loginctl show-session c1 -p Type Type=x11 frank@debian:~$ loginctl show-session c1 Id=c1 User=116 Name=Debian-gdm Timestamp=Sat 2019-07-06 22:43:34 CEST TimestampMonotonic=30094837 VTNr=1 Seat=seat0 TTY=tty1 Remote=no Service=gdm-launch-environment Scope=session-c1.scope Leader=1015 Audit=4294967295 Type=x11 Class=greeter Active=no State=online IdleHint=yes IdleSinceHint=1562446130937731 IdleSinceHintMonotonic=346278596 LockedHint=yes

    Die Installation der Nvidia Treiber macht da wohl einen x11 Desktop raus. Aber auch nicht weiter schlimm, der Wayland lief ja hier überhaupt nicht. Würde mich aber über interessante Links zum Thema freuen 😉

  • Redis Replication

    Angeheftet Verschoben Redis
    4
    1 Stimmen
    4 Beiträge
    417 Aufrufe
    FrankMF

    Um die Verbindung zu testen, kann man folgende Befehle nutzen.

    redis-cli -h 10.1.1.0 -p 6379 -a <PASSWORD>

    und

    telnet 10.1.1.0 6379
  • Restic - Ein Backupkonzept

    Angeheftet Restic
    1
    0 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet