Statische IP einrichten

  • Ich wünsche euch einen schönen Tag.

    Ich fasse die vorherigen Antworten zur Einrichtung einer statischen IP für eth0 (LAN) unter JESSIE ein bisserl zusammen und werde dies dann mit euren Bemerkungen erweitern:

    Dasselbe soll nämlich auch fürs wlan erstellt werden, denn ich kenn mich schön langsam gar nicht mehr aus!

    Grund: Seit JESSIE soll man die Einstellungen fürs Netzwerks über systemd machen


    Möglichkeit 01:

    Voraussetzungen:

    das aktuelle JESSIE auf einer SD-Karte
    alle update und upgrade ausgeführt

    /etc/network/interfaces noch original
    /etc/wpa_supplicant/wpa_supplicant.conf noch original
    /etc/dhcpcd.conf noch original

    Erstellen einer eigenen network-Datei:

    sudo nano /etc/systemd/network/eth0.network
      
    mit folgendem Inhalt:

    [Match]
    Name=eth0

    [Network]
    DHCP=none # ansonst ohne "=none", wenn dynamische IP gewuenscht ist
    IPv4LL=false # ansonst "=true", wenn dynamische IP gewuenscht ist
    Address=http://192.168.xxx.xxx/24 # diese Zeile mit # auskommentieren, , wenn dynamische IP gewuenscht ist
    Gateway=192.168.xxx.xxx # diese Zeile mit # auskommentieren, , wenn dynamische IP gewuenscht ist


    anschliessend in der Datei "/etc/rc.local" am Ende folgendes hinzufuegen, außer wenn dynamische IP gewuenscht ist:

    sudo nano /etc/rc.local

    mit folgender Inhaltsergaenzung vor letzten Zeile mit "exit 0":

    #!/bin/bash -e
    ##
    IP_ADDRESS_ETH0="192.168.xxx.xxx" # selbe IP-Adresse wie in eth0.network nur ohne /24
    IP_ADDRESS_AKT_ETH0="$(ip -4 a show eth0 | grep inet | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}/' | cut -d/ -f1)"
    ##/bin/echo $IP_ADDRESS_ETH0
    ##/bin/echo $IP_ADDRESS_AKT_ETH0

    if [ "$IP_ADDRESS_ETH0" != "$IP_ADDRESS_AKT_ETH0" ]; then {
    /bin/systemctl restart systemd-networkd.service
    ##/bin/echo "systemd-networkd.service was restarted"
    /bin/echo "$IP_ADDRESS_AKT_ETH0" >> /home/pi/log_restart_networkd.txt
    /bin/echo "systemd-networkd.service was restarted" >> /home/pi/log_restart_networkd.txt
    exit 0
    }
    else {
    ##/bin/echo "systemd-networkd.service was not restarted"
    /bin/echo "$IP_ADDRESS_AKT_ETH0" >> /home/pi/log_restart_networkd.txt
    ##/bin/echo "systemd-networkd.service was not restarted" >> /home/pi/log_restart_networkd.txt
    exit 0
    }
    fi


    nun im Terminal folgende Befehle eingeben:

    sudo ifdown eth0
    sudo systemctl enable systemd-networkd.service
    sudo systemctl start systemd-networkd.service
    systemctl status systemd-networkd.service
    ip a
    ip r

    Dort sollten dann die IP-Adresse zu sehen sein.

    Nun nur noch den Router konfigurieren, falls notwendig.


    Möglichkeit 02:

    Voraussetzungen:

    das aktuelle JESSIE auf einer SD-Karte
    alle update und upgrade ausgeführt

    etc....


    So, in dieser Anleitung sind mit Sicherheit jede Menge Fehler. Bitte daher um eure konstruktiven Bemerkungen. Klugscheisser bin ich selber.

    Danke und schöne Grüße

    willi

  • Ein paar Anmerkungen:
    1. Die rc.lokal-Kiste ist nicht nur völlig unnötig, sondern möglicherweise sogar wirkungslos, weil sie vor dem Netzwerk gestartet werden kann.... was ja auch aus dem Namensteil "local" hervorgeht.
    2. Bei einer Static-IP würde ich den dhcp-daemon disable'n
    3. wpasupplicant hat nichts mit eth0 zu tun
    4. bei starten des Netzwerkes über systemd-networkd muss vorher /etc/init.d/networking disabled werden, wodurch zeitgleich die /etc/network/interfaces eine bedeutungslose Leiche wird.
    5. mit dem start von systemd-networkd würde ich auch systemd-resolved enablen
    6. statt dem veralteten "sudo ifdown eth0" würde ich das NIC mit "ip link set dev eth0 down" abschalten und und statt jedesmal "sudo" vorher für alle Befehl einmal mit "su" zu root werden.

    Einmal editiert, zuletzt von WinterUnit16246 (2. Februar 2017 um 21:37)


  • Ich habe letztens auch mein Jessie auf systemd.networkd umgestellt weil ich die Faxen dicke hatte mit dem ganzen dhcp Kuddelmuddel auf Jessie. Dabei hat mir diese Seite sehr geholfen

    Ich halte die Seite für ein wenig kompliziert... gerade auch dann, wenn man NUR ne Static-IP haben will... das geht wahrlich einfacher:

    Code
    nano /etc/systemd/network_eth0.service

    Um einem stationären PC eine dhcp-Adresse zu vergeben tauscht man einfach den Exec*-Block aus:

    Code
    ExecStartPre=/sbin/ip link set dev eth0 up
    ExecStart=/sbin/dhclient eth0
    ExecStop=/sbin/dhclient -r eth0
    ExecStopPost=/sbin/ip link set dev eth0 down

    Dann die Unit enablen und noch die beiden überflüssigen Daemons dhcp und networking deaktivieren und gut is...und systemd-networkd braucht man hier auch nicht.

    Einmal editiert, zuletzt von WinterUnit16246 (2. Februar 2017 um 21:40)


  • ..., weil sie vor dem Netzwerk gestartet werden kann.... was ja auch aus dem Namensteil "local" hervorgeht.

    Hast Du mal mit z. B. "systemd-analyze plot" aufzeichnen lassen, wann systemd-networkd gestartet wird ond wann rc-local.service gestartet wird?


    4. bei starten des Netzwerkes über systemd-networkd muss vorher /etc/init.d/networking disabled werden, wodurch zeitgleich die /etc/network/interfaces eine bedeutungslose Leiche wird.

    Nein, /etc/init.d/networking muss nicht disabled werden. Es gibt Systeme ohne NetworkManager und ohne service-unit für den wpa_supplicant, auf denen der wpa_supplicant mit Hilfe der interfaces-Datei (networking) gestartet wird. D. h., networking, systemd-networkd und dhcpcd können ohne Probleme (wenn richtig konfiguriert) gleichzeitig genutzt werden.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hast Du mal mit z. B. "systemd-analyze plot" aufzeichnen lassen, wann systemd-networkd gestartet wird ond wann rc-local.service gestartet wird?


    Als wenn der Zeitpunkt, wann es gestartet wird, eine Bedeutung hat.... und das, wo in der rc-local-Unit sogar noch "After=network.target" drinsteht. Mehr, als man hier erkennen kann, muss ich nicht wissen, um zu erkennen, wo Probleme entstehen können: Plot Und für die Konsequenzen bei einem Pi3 mit WLAN muss man nicht mal Hellseher sein.

    Nein, /etc/init.d/networking muss nicht disabled werden.


    Ja, ist mir klar... Du brauchst ja auch eine Aufgabe, wenn Du mit Problemen auf Grund konkurrierender Services irgendwelche Newbies tagelang beschäftigen kannst....

    Einmal editiert, zuletzt von WinterUnit16246 (2. Februar 2017 um 22:18)


  • Als wenn der Zeitpunkt, wann es gestartet wird, eine Bedeutung hat.... und das, wo in der rc-local-Unit sogar noch "After=network.target drinsteht". Mehr, als man hier erkennen kann, muss ich nicht wissen, um zu erkennen, wo Probleme entstehen können


    Es geht ja nicht um das network.target. Es geht lediglich darum, dass systemd-networkd vor der rc.local ausgeführt wird und man mit Hilfe der rc.local feststellen kann, ob systemd-networkd dem Interface eine IP-Adresse zugewiesen hat oder nicht zugewiesen hat.

    ... mit Problemen auf Grund konkurrierender Services ...

    Die Services konkurieren überhaupt nicht. Ganz im Gegenteil es werden erforderliche Abhängigkeiten berücksichtigt bzw. brauchbare log-Eintragungen generiert, was man mit selbst gebastelten service-units evtl. erstmal testen/eruieren muss.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • man mit Hilfe der rc.local feststellen kann


    Und das vor dem Hintergrund, dass die rc.local als File in Stretch erst mal gar nicht mehr vorhanden ist... zwar noch im Kompatibiltätsmodus mit dem Autogen für die Unit, aber erst mal nicht mehr als File. Und auch vor dem Hintergrund, dass systemd sowieso die Zielsetzung hat, auf diese überflüssigen Startskripte vollständig zu verzichten. Und genau das ist die rc.local... schlichtweg überflüssig. Ich mag es lieber eindeuting und geradlinig. Das ist auch genau das, was man Anfängern näher bringen kann. Wie ich an anderer Stelle schon mal gesagt habe, Fedora 25 hat nicht mal mehr die networking, weil die auch heute schon total überflüssig ist. Und ich gehe davon aus, dass die Lebenszeit dieses historischen Mülls in Debian spätestens in der Version nach Stretch auch endet. Aber egal, jeder wie er mag... mir ist das nicht nur egal, sondern geradezu totalscheissegal ...*lol*... und das noch weiter zu erörtern ist nur Zeitverschwendung.... wie ich sagte... jeder wie er mag.

    Einmal editiert, zuletzt von WinterUnit16246 (2. Februar 2017 um 22:49)


  • Und das vor dem Hintergrund, dass die rc.local als File in Stretch erst mal gar nicht mehr vorhanden ist... zwar noch im Kompatibiltätsmodus mit dem Autogen für die Unit, aber erst mal nicht mehr als File.

    Darum geht es doch gar nicht. Auslöser für diese Diskussion war, von dir:

    Zitat


    ... sondern möglicherweise sogar wirkungslos, weil sie vor dem Netzwerk gestartet werden kann.... was ja auch aus dem Namensteil "local" hervorgeht.


    ... und das ist nicht richtig.

    Dass es Alternativen zur rc.local gibt, war und ist doch jedem klar. Und betr. deine Meinung zur rc.local:

    Code
    ... die rc.local... schlichtweg überflüssig.


    , da hätte ich doch gar nichts geschrieben bzw. nichts gesagt, weil mich das nicht interessiert.


    ...mal mehr die networking, weil die heute auch total überflüssig ist. ...

    Auch hier, der Auslöser für die Diskussion war, von dir:

    Zitat


    4. bei starten des Netzwerkes über systemd-networkd muss vorher /etc/init.d/networking disabled werden ...


    ... was auch dann falsch ist, wenn networking überflüssig ist.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Sorry ... Aber Deine Antwort verstehe ich nicht


    Derzeit geht die m.E. einzig wahrnehmbare Linux-Distributions-Innovation faktisch nur von RedHat aus.... dabei betrachte ich nur die wirklich ernstzunehmenden Linux-Distris, also z. B. Debian und Fedora. Den buntu-Kram (Mint incl.) und diverse Nischen-Distris zähle ich nicht dazu.

    Von RedHat kommt z.B. (bzw. wird irgendwann kommen):

    • Polkit - entwickelt von David Zeuthen, RedHat
    • Pulseaudio, von Lennart Poettering, RedHat, welches bei mir das veraltete Alsa ersetzt
    • Systemd - entwickelt von Lennart Poettering und Kay Sievers, RedHat
    • Wayland - entwickelt von Kristian Høgsberg, ehemals Red Hat. Öffnet man die Wayland-Website sieht man freedesktop.org. Und freedesktop.org wurde von Havoc Pennington (wieder Red Hat) im März 2000 gegründet

    In Fedora25 gibs keine init.d-Scripte mehr.... die sind komplett weg. Debian hat einige der wirklich innovativen Entwicklungen von RedHat übernommen. Und irgendwann wird dann auch Wayland den veralteten XServer bei Debian ersetzen. Debian bzw. die Debian-Community ist nur leider etwas träge, weil Stretch (die nächste Version nach Jessie) bedauerlicherweise noch einige Altlasten am Leben hält, auch wenn sie überflüssig sind... so eben diese Leiche /etc/init.d/networking. Nun ja, aber wenn Linux im Consumer-Computer-Universum einen Stand hat, dann imho durch die Leistungen von RedHat. Und ich glaube, dass die rückblickend Richtungsweisend waren und das auch künftig sein werden.


    Automatisch zusammengefügt:

    ... was auch dann falsch ist, wenn networking überflüssig ist.


    Mach einfach, was Du meinst.... Du hast wie immer Recht......

    Einmal editiert, zuletzt von WinterUnit16246 (2. Februar 2017 um 23:26)

  • Hallo Leute

    Habe mit Hilfe eines Links in diesem Forum folgende Infos gefunden: :bravo2:
    Quelle der unten angeführten Lösungsvorschläge:
    ELEKTRONIK Kompendium
    ELEKTRONIK Kompendium - Statische/feste IPv4-Adresse für Raspbian Jessie (Raspberry Pi)

    Statische/feste IPv4-Adresse für Raspbian Jessie (Raspberry Pi)

    Wer den Raspberry Pi zum ersten Mal in Betrieb nimmt und darauf per SSH zugreifen möchte, der muss zuerst einmal die IPv4-Adresse herausfinden. Geschickterweise zeigt der Raspberry Pi nach dem Boot-Vorgang seine IPv4-Adresse auf dem Bildschirm an, sofern man ihn mit Tastatur und Bildschirm in Betrieb nimmt. Leider ändert sich die IPv4-Adresse immer mal wieder, weil bei der IPv4-Adressvergabe durch den DHCP-Server im lokalen Netzerk nicht immer die gleiche Adresse zugeteilt wird, sondern dynamisch irgendeine aus seinem Adress-Pool.

    Sofern man den Raspberry Pi als Client benutzt, ist das kein Problem. Doch wenn man den Raspberry Pi als Server innerhalb des lokalen Netzwerk betreiben möchte oder öfter mal per SSH darauf zugreifen will, dann ist eine feste IPv4-Adresse von Vorteil.
    Hinweis hierbei: Man kann die Verbindung auch über den Hostnamen z. B. "raspberrypi.local" aufbauen. Nur funktioniert das nicht immer.

    Hinweis: In der Fachsprache spricht man nicht von einer "festen IP-Adresse", sondern von einer "statischen IP-Adresse", weil es im Gegensatz dazu dynamische IP-Adressen gibt, die von einem DHCP-Server zugewiesen werden. Im Falle einer "statischen IP-Adresse" spricht man von einer manuellen IP-Konfiguration.

    Hinweis: Wenn man statische IP-Adressen konfiguriert, dann sollten diese nicht aus dem DHCP-Pool eines DHCP-Servers kommen.

    Mehr zum Thema IPv4-Adressen und DHCP


    Aufgabe

    1. Ermitteln Sie eine freie IPv4-Adresse und die weitere IP-Konfiguration.
    2. Stellen Sie die IPv4-Konfiguration auf statisch um.
    3. Prüfen Sie die IPv4-Konfiguration.
    4. Prüfen Sie die Netzwerk-Verbindung auf Funktion.


    Übersicht
    Es gibt nicht nur eine, sondern gleich mehrere Varianten, wie man eine funktionierende Netzwerk-Konfiguration vornehmen kann. Welche man verwendet hängt von den Anforderungen und der persönlichen Bevorzugung ab.

    • IPv4-Konfiguration in der Datei "/etc/network/interfaces"
    • IPv4-Konfiguration per DHCP Client Deamon (DHCPCD)
    • Interface durch DHCPCD ausschließen (Kombination)
    • IPv4-Konfiguration im Router zuweisen (zentrale IP-Konfiguration)
    • IPv4-Konfiguration per systemd-networkd

    Offiziell wird die IP-Konfiguration für Raspbian Jessie über den DHCPCD empfohlen (Lösung 2). Grundsätzlich spricht allerdings nichts dagegen, eine statische IP-Konfiguration über die Datei "/etc/network/interfaces" vorzunehmen (Lösung 1). Man kann auch beide Lösungen miteinander kombinieren (Lösung 3).

    Der zukünftige Weg erfolgt über "systemd-networkd", über das ebenfalls die IP-Konfiguration erfolgen kann (Lösung 5). Der einfachste Weg wäre sicherlich, die IP-Zuweisung im Router zu machen (Lösung 4). Dabei müsste man keine Änderung am Raspberry Pi vornehmen.

    Troubleshooting: Netzwerk-Konfiguration
    Probleme bei der Netzwerk-Konfiguration sind nicht ausgeschlossen. Deshalb gleich zu Anfang ein paar Hinweise zur Problemlösung.


    Lösung (Variante 1): IPv4-Konfiguration in der Datei "/etc/network/interfaces"
    Konfigurations-Datei für die Netzwerk- bzw. IP-Konfiguration öffnen:

    sudo nano /etc/network/interfaces

    Eine vollständige IPv4-Konfiguration sieht wie folgt aus:
    # Ethernet
    auto eth0
    allow-hotplug eth0
    iface eth0 inet static
    address 192.168.1.2
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1

    Es handelt sich hierbei um eine Beispiel-Konfiguration. Diese kann funktionieren, muss aber nicht. Sie einfach auszuprobieren ist nicht sinnvoll. Man sollte vorher klären, was man hier eintragen muss und nicht irgendwie herumprobieren. Hilfreich ist es, wenn man nachschaut, was andere Clients im eigenen Netzwerk haben bzw. was beispielsweise schon per DHCP zugeteilt wurde.
    Bei der Vergabe der IPv4-Adresse muss man jedoch darauf achten, dass man eine Adresse wählt, die noch NICHT verwendet wird und sich auch NICHT im Adress-Pool eines DHCP-Servers (z. B. Internet-Router) befindet. Ansonsten kann es zu Verbindungsproblemen im Netzwerk kommen.
    Nachdem man die Änderungen vorgenommen hat kann man die Datei speichern und schließen: Strg + O, Return, Strg + X.

    Hinweis: In Raspbian Wheezy ab 2015-05-05 und in Raspbian Jessie ist standardmäßig ein DHCP Client Daemon (DHCPCD) aktiv, der zum Problem werden kann, wenn man die IPv4-Konfiguration auf diese Weise vornimmt.

    Wenn man diesen DHCP-Client definitiv nicht braucht, dann sollte man ihn deaktivieren.

    Bei Raspbian Wheezy:
    sudo service dhcpcd stop
    sudo update-rc.d -f dhcpcd remove

    Bei Raspbian Jessie:
    sudo service dhcpcd stop
    sudo systemctl disable dhcpcd

    Um die Änderungen zu übernehmen empfiehlt sich hier ein Reboot.

    sudo reboot

    Weniger radikal ist es, das "networking" neu zu starten. Das ist aber nur sinnvoll, wenn man NICHT per SSH mit dem Raspberry Pi verbunden ist.

    sudo service networking restart

    Alternativ kann man das Interface "eth0" aus- und wieder einschalten. Auch das ist nur dann sinnvoll, wenn man NICHT per SSH verbunden ist, sondern lokal mit Bildschirm und Tastatur am Raspberry Pi sitzt.

    sudo ifdown eth0
    sudo ifup eth0

    Dadurch wird das Interface "eth0" beendet und neu gestartet. Beim Start werden die Einstellungen übernommen. Danach müsste der Raspberry Pi mit seiner statischen IPv4-Adresse erreichbar sein.

    Anschließend ist die Netzwerk-Konfiguration zu prüfen.

    Lösung (Variante 2): IPv4-Konfiguration per DHCP Client Deamon (DHCPCD)

    In Raspbian Jessie ist standardmäßig ein DHCP Client Daemon (DHCPCD) aktiviert. Der offiziell empfohlene Weg eine IPv4-Konfiguration vorzunehmen, ist über den DHCPCD, der dafür eine Konfigurationsdatei bereithält.

    Hierzu ist es wichtig festzustellen, ob der "dhcpcd" überhaupt aktiv ist.
    sudo service dhcpcd status

    Liefert der Status einen installierten, aber abgeschalteten "dhcpcd", dann empfiehlt es sich diesen einzuschalten.
    Erst dann sollte man die Konfiguration über den "dhcpcd" vornehmen.

    sudo service dhcpcd start
    sudo systemctl enable dhcpcd

    Bevor man an die Konfiguration über den "dhcpcd" vornimmt, sollte man den Original-Zustand der Datei "/etc/network/interfaces" wieder herstellen. Die Schnittstellen müssen in der Option "iface" auf "manual" gesetzt sein.

    Zur statischen IPv4-Konfiguration öffnet man die Datei "/etc/dhcpcd.conf".

    sudo nano /etc/dhcpcd.conf

    Hier trägt man beispielhaft folgende Zeilen ein:

    interface eth0
    static ip_address=192.168.1.2/24
    static routers=192.168.1.1
    static domain_name_servers=192.168.1.1

    Es handelt sich hierbei um eine Beispiel-Konfiguration. Diese kann funktionieren, muss aber nicht. Sie einfach auszuprobieren ist nicht sinnvoll. Man sollte vorher klären, was man hier eintragen muss und nicht irgendwie herumprobieren. Hilfreich ist es, wenn man nachschaut, was andere Clients im eigenen Netzwerk haben bzw. was beispielsweise schon per DHCP zugeteilt wurde.

    Bei der Vergabe der IP-Adresse muss man jedoch darauf achten, dass man eine wählt, die noch NICHT verwendet wird und sich auch nicht im Adress-Pool eines DHCP-Servers befinden. Ansonsten wird es zu Verbindungsproblemen im Netzwerk kommen.

    Die Zeile "static ip_address=192.168.1.2/24" gibt die IPv4-Adresse "192.168.1.2" mit der Subnetzmaske "255.255.255.0" an. Die Angabe "24" ist eine Kurzschreibweise für die Subnetzmaske.

    Nachdem man die Änderungen vorgenommen hat kann man die Datei speichern und schließen: Strg + O, Return, Strg + X.

    Man hat jetzt nur die Datei geändert. Die Änderungen wurden aber noch nicht in die aktuelle Netzwerk-Konfiguration übernommen. Grundsätzlich empfiehlt sich hier ein Reboot, wenn man per SSH die Konfiguration vorgenommen hat.
    sudo reboot

    Weniger radikal ist es, das "networking" neu zu starten. Das ist aber nur sinnvoll, wenn man NICHT per SSH mit dem Raspberry Pi verbunden ist.

    sudo service networking restart

    Alternativ kann man das Interface "eth0" aus- und wieder einschalten. Auch das ist nur dann sinnvoll, wenn man NICHT per SSH verbunden ist, sondern lokal mit Bildschirm und Tastatur am Raspberry Pi sitzt.

    sudo ifdown eth0
    sudo ifup eth0

    Dadurch wird das Interface "eth0" beendet und neu gestartet. Beim Start werden die Einstellungen übernommen. Danach müsste der Raspberry Pi mit seiner statischen IPv4-Adresse erreichbar sein.

    Lösung (Variante 3): Interface durch DHCPCD ausschließen (Kombination)

    Wenn man den DHCPCD nicht deaktivieren will, weil man ihn für ein Interface braucht, dann kann man die Konfiguration durch den DHCPCD für ein Interface ausschließen oder explizit freigeben.

    Dazu öffnen wir die Konfigurations-Datei des DHCPCD und tragen dort noch eine Zeile ein.

    sudo nano /etc/dhcpcd.conf

    Netzwerk-Interface von der Konfiguration durch den DHCPCD ausschließen:

    denyinterfaces eth0

    Diese Zeile klammert das betreffende Interface aus der Netzwerk-Konfiguration aus. Die Netzwerk-Konfiguration für dieses Interface muss dann in der Datei "/etc/network/interfaces" erfolgen.

    Interface explizit freigeben:

    allowinterfaces eth0

    Nachdem man die Änderungen vorgenommen hat kann man die Datei speichern und schließen: Strg + O, Return, Strg + X.

    Die Änderungen wurden aber noch nicht in die aktuelle Netzwerk-Konfiguration übernommen. Grundsätzlich empfiehlt sich hier ein

    Reboot, wenn man per SSH die Konfiguration vorgenommen hat.

    sudo reboot

    Weniger radikal ist es, das "networking" neu zu starten. Das ist aber nur sinnvoll, wenn man NICHT per SSH mit dem Raspberry Pi verbunden ist.

    sudo service networking restart

    Alternativ kann man das Interface "eth0" aus- und wieder einschalten. Auch das ist nur dann sinnvoll, wenn man NICHT per SSH verbunden ist, sondern lokal mit Bildschirm und Tastatur am Raspberry Pi sitzt.

    sudo ifdown eth0
    sudo ifup eth0

    Dadurch wird das Interface "eth0" beendet und neu gestartet. Beim Start werden die Einstellungen übernommen. Danach müsste der Raspberry Pi mit seiner statischen IPv4-Adresse erreichbar sein.

    Lösung (Variante 4): IPv4-Konfiguration im Router zuweisen (zentrale IP-Konfiguration)

    Wenn man dem Raspberry Pi eine statische IP-Konfiguration mit fester IPv4-Adresse verpassen, aber dessen Netzwerk-Konfiguration nicht anfassen möchte, dann kann man sich auch einer Funktion im Internet-Router bedienen. Manche dieser Geräte haben eine Funktion, die es ermöglicht, dass die IPv4-Adresse auf die MAC-Adresse festgelegt wird. In dem Fall wäre die MAC-Adresse der Netzwerk-Schnittstelle zu ermitteln, der man im Router eine IPv4-Adresse fest zuteilt. Die Netzwerk-Konfiguration holt sich der Raspberry Pi weiterhin per DHCP. Nur bekommt er dann immer die selbe IPv4-Adresse zugewiesen.

    Diese Lösung hat den unausweichlichen Charme, dass man den Raspberry Pi dafür nicht anfassen muss. Nachteil dieser Lösung ist, dass dazu der DHCP-Server aktiv sein muss, wenn sich der Raspberry Pi die IP-Konfiguration per DHCP holt. Wenn nicht, dann steht der Raspberry Pi ohne IPv4-Adresse da.

    Lösung (Variante 5): IPv4-Konfiguration per systemd-networkd

    Neben der alten Konfiguration per "/etc/network/interfaces" oder "dhcpcd" gibt es noch die systemd-Variante. In zukünftigen Raspbian-Versionen wird "systemd" die Netzwerk-Konfiguration übernehmen.

    Man sollte die Umstellung auf "systemd-networkd" nicht per SSH machen. Gibt es eine Verbindungsunterbrechung, dann bekommt man die Verbindung unter Umständen nicht wieder aufgebaut.

    Zuerst prüfen wir, ob der Dienst "systemd-networkd" vorhanden ist. Das ist die Voraussetzung, dass diese Lösung überhaupt möglich ist. Ab Raspbian Jessie sollte das funktionieren.

    systemctl status systemd-networkd
    Dort sollte stehen "Loaded: loaded".

    Zuerst geht es darum, alte Network- oder Networking-Komponenten zumindest zu deaktivieren. Deinstallieren und löschen empfiehlt sich nicht, weil man sonst nur schwer wieder zurückkehren kann.

    sudo update-rc.d networking remove
    sudo systemctl stop dhcpcd
    sudo systemctl disable dhcpcd

    Den Dienst für die Namensauflösung "systemd-resolved" aktivieren und starten:

    sudo systemctl enable systemd-resolved
    sudo systemctl start systemd-resolved

    Prüfen, ob "systemd-resolved" läuft:

    sudo systemctl status systemd-resolved

    In der Zeile "Loaded: loaded" sollte hinten "enabled" stehen.

    Dann setzen wir noch einen symbolischen Link für die Datei mit der Adresse des Nameservers. Wenn dieser Link fehlt, dann kann es sein, dass die Namensauflösung nicht funktioniert.

    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    Dann geht es darum, eine Netzwerk-Konfiguration anzulegen. Die kann in mehreren Dateien verteilt sein, die sich alle im selben Verzeichnis befinden.

    ls /etc/systemd/network/

    Wenn das Verzeichnis leer ist, dann muss man die notwendigen Dateien erst noch anlegen. Der Dateiname ist dabei unerheblich. Er muss nur auf ".network" enden. Trotzdem empfiehlt es sich, sinnvolle Dateinamen zu wählen, um sich im Fehlerfall leichter zurecht zu finden.

    Beispiel für eine statische IPv4-Konfiguration für das Interface "eth0":
    sudo nano /etc/systemd/network/eth0.network

    Eintrag für eine statische IPv4-Konfiguration:

    [Match]
    Name=eth0

    [Network]
    Address=192.168.1.2/24
    Gateway=192.168.1.1
    DNS=192.168.1.1

    Alternativ: Eintrag für eine IP-Konfiguration mit DHCP:

    [Match]
    Name=eth0

    [Network]
    DHCP=yes

    Speichern und schließen mit Strg + O, Return, Strg + X.

    Den Dienst "systemd-networkd" aktivieren und starten:

    sudo systemctl enable systemd-networkd
    sudo systemctl start systemd-networkd

    Prüfen, ob "systemd-networkd" läuft:
    sudo systemctl status systemd-networkd

    In der Zeile "Loaded:" sollte hinten "enabled" stehen und die Schnittstelle sollte konfiguriert sein. In diesem Fall "eth0 : link configured".

    Danach das System neustarten:

    sudo reboot

    Nach dem Neustart sollte das System mit "systemd-networkd" laufen.

    Lösung: Netzwerk-Konfiguration prüfen
    Ob die IPv4-Einstellungen korrekt übernommen wurden, sollte man prüfen.

    Die IP-Adresse kann man wie folgt prüfen.

    ip a

    Das Interface "eth0" muss dann in der Zeile mit "inet-Adresse" die statische konfigurierte IPv4-Adresse bekommen haben.
    Dann prüft man, ob das Standard-Gatway bzw. die Default-Route eingetragen ist. Die ist wichtig, damit man überhaupt ins Internet kommt.

    ip r

    Wenn "default" auf die richtige IPv4-Adresse des Standard-Gateways zeigt, dann ist alles in Ordnung.
    Jetzt fehlt noch der DNS-Server.
    Der ist notwendig, damit die Namensauflösung funktioniert und Verbindungen ins Internet über die ermittelten IP-Adressen über das Standard-Gateway möglich sind.

    cat /etc/resolv.conf

    Steht hinter "nameserver" die IPv4-Adresse des DNS-Servers, dann ist auch hier alles in Ordnung.

    Troubleshooting: Doppelte IPv4-Adresse

    Grundsätzlich gilt, dass ein Interface (eth0, wlan0, usw.) nur eine IPv4-Adresse haben darf. Die Prüfung der Netzwerk-Konfiguration ergab, dass die IPv4-Adresse doppelt vergeben wurde. Das kann zu Problemen führen.

    ip a

    Eine beispielhafte Ausgabe:

    inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
    valid_lft forever preferred_lft forever
    inet 192.168.1.132/24 brd 192.168.1.255 scope global secondary eth0
    valid_lft forever preferred_lft forever

    Wie man sieht, hat das Interface "eth0" zwei IPv4-Adressen, was zu Problemen im Netzwerk führen kann. Manche Router reagieren allergisch, wenn ein Host unter zwei IPv4-Adressen erreichbar ist.
    Hier spuckt uns der DHCP Client Daemon in die Suppe. Wenn man diesen DHCP-Client definitiv nicht braucht, dann sollte man ihn deaktivieren.

    sudo systemctl stop dhcpcd
    sudo systemctl disable dhcpcd

    Um die Änderungen zu übernehmen empfiehlt sich ein Reboot.


    Troubleshooting: Kein Hostname mehr
    Wenn man die Netzwerk-Konfiguration nach Lösung 1, 2 oder 3 einstellt, dann ergibt sich das Problem, dass man den Hostnamen des Raspberry Pi nicht mehr im Internet-Router angezeigt bekommt. Nur wenn man die Einstellungen im Urzustand belässt erscheint im Router der Hostname "raspberrypi" (Grundeinstellung).

    Der Grund dafür ist die statische Netzwerk-Konfiguration. In dem Fall findet keine aktive Kommunikation zwischen Raspberry Pi und dem Router statt. Und somit erfährt der Router auch nicht den Hostnamen des Raspberry Pi.

    Man kann das Problem mit Variante 4 lösen.
    Hier findet dann die Kommunikation mit DHCP statt und der Raspberry Pi teilt auf diese Weise seinen Hostnamen mit.

    Die Voraussetzung, damit das funktioniert ist, dass in der Datei "/etc/dhcpcd.conf" in einer Zeile "hostname" steht.

    Erweiterung: IPv4-Konfiguration mit dem Netzwerk-Manager "wicd-curses"
    "wicd-curses" ist ein grafischer Netzwerk-Manager, der alle wichtigen Informationen in einer Benutzeroberfläche darstellt, die mit der Tastatur bedient werden muss.

    Wer sich mit dem Editieren von Text-Dateien schwer tut, für den kann das eine Alternative sein.


    Erweiterung: Über den Hostnamen auf den Raspberry Pi zugreifen (Zeroconf/Bonjour/Avahi)
    Wer nicht mit IP-Adressen und deren Konfiguration hantieren möchte, kann das Problem auch mit Zeroconf lösen. Mit Zeroconf, auch Bonjour oder Avahi genannt, kann man innerhalb des lokalen Netzwerks eine Verbindung zum Raspberry Pi mit seinem Hostnamen aufbauen. Das heißt, statt der IP-Adresse, die man vielleicht gar nicht weiß, nimmt man einfach den Hostnamen, den man sich viel einfacher merken kann. Das funktioniert sowohl im Browser als auch per SSH.


    Weitere verwandte Themen:

    lg

    willi

    Einmal editiert, zuletzt von zillawilli (4. Februar 2017 um 18:41)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!