[Gelöst] FB7490 -- DHCP/IP zuweisen: mit dhcpcd

neandr

Neuer User
Mitglied seit
8 Mrz 2006
Beiträge
184
Punkte für Reaktionen
6
Punkte
18
Für mein lokales Netzwerk sollen die IP Addressen fest zugeordnet werden. Dazu ist an der FB DHCP mit einem IP Bereich von 20 .. 60 auf Heimnetz --> Netzwerkeinstellungen --> IPv4-Adressen eingestellt worden.

In der Übersicht erscheinen aber Geräte mit zB IP .82. Für dieses Gerät/Raspberry ist aber in der /etc/network/interfaces für LAN angeben
Code:
iface eth0 inet static
address 192.xxx.yyy.35
netmask 255.255.255.0
gateway 192.xxx.yyy.1
Auf Bearbeiten des Eintrages lässt sich der Eintarg zwar ändern, aber das bringt nix, die .82 bleibt ... auch nach Reboot des Raspberry.
Merkt sich die FB die "alten" IPs und weist diese direkt der Verbindung wieder zu? Wenn ja wie kann man das abstellen?
 
Zuletzt bearbeitet:
Dort was zu bearbeiten bringt ja nur was, wenn auch DHCP nutzt.

Also im RasPi DHCP aktivieren, Gerät vom LAN trennen, Eintrag in FB bearbeiten, und Gerät wieder per LAN verbinden.
 
Hmm, bin jetzt etwas verwirrt :confused:
Ich dachte DHCP wird im FB Router eingestellt -- nicht im Netzwerkgerät (RPI), d.h. der Router weist den angeschlossenen Geräten die Adressen zu und zwar in dem Bereich der im Router/DHCP Server eingestellt wurde.
Feste IPs für die Netzwerkgeräte (zB. RPI) *müssen* außerhalb des im Router/DHCP Server festgelegten Bereich liegen.

Gesagt getan, dann erwarte ich, dass nach Reboot ein Gerät mit einer fest zu geordneten IP als solche auch in den FB Netzwerkangaben so erscheint. Aber das ist nicht der Fall.

Sogar wenn ein vorher angeschlossenes Gerät mit festen IPs für LAN und WLAN vom Netz genommen wurde und stromlos ist, erscheint in der FB Maske das Gerät mit einer anderen IP in der Rubrik "Aktive Verbindungen". Und diese Einträge lassen sich mittels der GUI nicht löschen.
Die FB kennt hier "Vergessen von vorher angeschlossenen Geräten / IPs" nicht.
 
Ist nicht neu dass es da Konflikte gibt wenn man am Gerät IP fixiert.

Der IP Bereich ist nur für neue Geräte reserviert, IP Zuweisung Erfolgt für ganze Netzwerk.

Also stell wie gesagt dein RasPi sonst auf dhcp, und lass die von FB beziehen in dem dort deine gewünscht IP den Gerät zuweist.
 
Sogar wenn ein vorher angeschlossenes Gerät mit festen IPs für LAN und WLAN vom Netz genommen wurde und stromlos ist, erscheint in der FB Maske das Gerät mit einer anderen IP in der Rubrik "Aktive Verbindungen".
Poste mal von deinem PI, mit der jetzigen Konfiguration, die Ausgaben von:
Code:
apt-cache policy dhcpcd5
ps aux | grep -i [d]hc
ip a
ip r
 
@sf3978 Hier zunächst was der RPI dazu sagt, Neustart heute mittag:

a) ohne LAN
Code:
aa@bbbb:~ $ apt-cache policy dhcpcd5
dhcpcd5:
  Installed: 6.7.1-1+rpi5
  Candidate: 6.7.1-1+rpi5
  Version table:
 *** 6.7.1-1+rpi5 0
        500 http://archive.raspberrypi.org/debian/ jessie/main armhf Packages
        100 /var/lib/dpkg/status
     6.0.5-2 0
        500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages
aa@bbbb:~ $ ps aux | grep -i [d]hc
root       630  0.0  0.3   2552  1572 ?        Ss   11:18   0:00 /sbin/dhcpcd -q -w
ntp        651  0.2  0.8   5764  3836 ?        Ss   11:18   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 106:111
aa@bbbb:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:xx:xx:xx:xx:bf brd ff:ff:ff:ff:ff:ff
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link tentative 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 80:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.xxx.yyy.84/24 brd 192.xxx.yyy.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet 192.xxx.yyy.24/24 brd 192.xxx.yyy.255 scope global secondary wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxx:xxxx:24fd/64 scope link 
       valid_lft forever preferred_lft forever
aa@bbbb:~ $ ip r
default via 192.xxx.yyy.1 dev wlan0 
default via 192.xxx.yyy.1 dev wlan0  metric 303 
192.xxx.yyy.0/24 dev wlan0  proto kernel  scope link  src 192.xxx.yyy.24  metric 303 
aa@bbbb:~ $

b) mit LAN
Code:
aa@bbbb:~ $ ps aux | grep -i [d]hc  
root       630  0.0  0.4   2552  1828 ?        Ss   11:18   0:00 /sbin/dhcpcd -q -w
ntp        651  0.0  0.8   5764  3844 ?        Ss   11:18   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 106:111
aa@bbbb:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:xx:xx:xx:xx:bf brd ff:ff:ff:ff:ff:ff
    inet 192.xxx.yyy.14/24 brd 192.xxx.yyy.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::8cba:8722:5530:fb8b/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 80:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.xxx.yyy.84/24 brd 192.xxx.yyy.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet 192.xxx.yyy.24/24 brd 192.xxx.yyy.255 scope global secondary wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxx:xxxx:24fd/64 scope link 
       valid_lft forever preferred_lft forever
aa@bbbb:~ $ ip r
default via 192.xxx.yyy.1 dev wlan0 
default via 192.xxx.yyy.1 dev eth0  metric 202 
default via 192.xxx.yyy.1 dev wlan0  metric 303 
192.xxx.yyy.0/24 dev eth0  proto kernel  scope link  src 192.xxx.yyy.14  metric 202 
192.xxx.yyy.0/24 dev wlan0  proto kernel  scope link  src 192.xxx.yyy.24  metric 303 
aa@bbbb:~ $

Zur Erinnerung: in der 'interfaces' ist LAN mit .74 und WLAN mit .84 angegeben.

Einen Punkt habe ich bisher nicht erwähnt, scheint mir aber wichtig nachdem mir nochmal klar geworden ist, dass die IP Bestimmung auch etwas zu tun hat mit den MAC Adressen.

Es wird *ein* RPI benutzt, um die SW Installation auf zwei verschiedenen SDCards vorzubereiten. Damit hat die HW (LAN und WLAN) immer jeweils dieselbe MAC Adresse. Die SDCard in der 'interfaces' aber andere IPs.

Das og. Listing ist für die SDCard mit LAN .74 und WLAN .84, ich kann mich über SSH mit 192.xxx.yyy.84 und .24 sowie .14 anmelden, aber nicht mit .74!?
Code:
ssh: connect to host 192.xxx.yyy.74 port 22: No route to host

Und die FB sagt
Code:
rpi4 WLAN 192.xxx.yyy.24
rpi4 LAN 4 mit 100 Mbit/s 192.xxx.yyy.14

Hoffe da kann mir jemand Aufklärung geben.
 
Code:
aa@bbbb:~ $ apt-cache policy dhcpcd5
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 80:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.xxx.yyy.84/24 brd 192.xxx.yyy.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet 192.xxx.yyy.24/24 brd 192.xxx.yyy.255 scope global secondary wlan0
       valid_lft forever preferred_lft forever

Trage in die /etc/dhcpcd.conf
Code:
denyinterfaces=wlan0
ein, damit das wlan0-Interface deines PIs, nicht auch noch per dhcp eine 2. IPv4-Adresse bekommt.

Besser wäre es m. E. die interfaces-Datei nicht mehr zu nutzen und alles über dhcpcd oder über systemd-networkd zu machen.



Es wird *ein* RPI benutzt, um die SW Installation auf zwei verschiedenen SDCards vorzubereiten. Damit hat die HW (LAN und WLAN) immer jeweils dieselbe MAC Adresse. Die SDCard in der 'interfaces' aber andere IPs.
Das muss nicht sein, denn Du kannst deinen PI so konfigurieren, dass die richtige bzw. eine andere MAC-Adresse verwendet wird. Z. B. mit "smsc95xx.macaddr= ..." in der /boot/cmdline.txt
 
@sf978 Danke erstmal!

Das ganze läuft ja bei diesen Versuchen unter Jessie Light. Bisher hatte ich Wheezy laufen -- never touch a running system .. und der RPI bleibt auch so, aber ein weiterer soll mit der aktuellen Raspian Version eingerichtet werden.

Besteht denn zw Jessie und Wheezy bzgl der DHCP etc Behandlung (auch) ein Unterschied?
 
Besteht denn zw Jessie und Wheezy bzgl der DHCP etc Behandlung (auch) ein Unterschied?

Ja, bei jessie ist dhcpcd5 schon vorinstalliert. Siehe z. B. auf beiden OSs, die Ausgabe von:
Code:
ps aux | grep -i [d]hc

wheezy hat SysVinit und jessie hat systemd. Aber das ist m. E. kein Grund, jessie (systemd) nicht zu verwenden.
 
Kennst du eine gute Anleitung/Erklärung zu dhcpcd5? Dr.G zeigt zwar viel, aber ev. kennst einen guten Link
 
Zuletzt bearbeitet:
Was ist nun so schwer in FB die IP festzulegen für das Gerät und dann DHCP zu verwenden? So bleibt auch nach Neuinstall, Updates ect. immer diese IP erhalten und muss nicht ständig am Gerät fixiert werden.
 
Kennst du eine gute Anleitung/Erklärung zu dhcpcd5?

Siehe z. B. auf deinem PI mit jessie, die Ausgaben von:
Code:
man dhcpcd.conf
man dhcpcd

EDIT:

BTW: Mit z. B. zusätzlich:
Code:
interface <Interface>
request <IP-Adresse-aus-dem-DHCP-Pool>
in der /etc/dhcpcd.conf, kann man auch eine feste IP-Adresse konfigurieren.

Und wenn Du Lust hast, kannst Du mit dhcpcd, als fallback profil, auch eine feste/statische IP-Adresse von außerhalb des DHCP-Pools, konfigurieren.

Zum testen des dhcpcd auf deinem Pi mit jessie, kannst Du z. B. Folgendes verwenden:
Code:
sudo tcpdump -vvveni <Interface> udp portrange 67-68
Code:
sudo systemctl restart dhcpcd
und siehe danach die Ausgaben von tcpdump bzw. "ip a".
 
Zuletzt bearbeitet:
Es sieht so aus als liegt die Lösung in der Konfigurierung von /etc/dhcpcd.conf, in sofern Danke für den Hinweis.

Allerdings muss ich gestehen, die Erarbeitung mit Hilfe der man-pages ...
Siehe z. B. auf deinem PI mit jessie, die Ausgaben von:
Code:
man dhcpcd.conf
man dhcpcd
... war mir etwas zu mühsam und ich fand schließlich die Anleitung auf https://www.jeffgeerling.com/blog/2016/setting-static-ip-address-raspbian-jessie-lite-on-raspberry-pi

Danach und mit diesem Block angefügt in /etc/dhcpcd.conf geht es!
Code:
interface eth0
static ip_address=192.xxx.yyy.{IP}
static routers=192.xxx.yyy.1
static domain_name_servers=8.8.8.8 8.8.4.4
Entsprechendes für WLAN.

Die FB zeigt dann auch die jeweilige(n) IP richtig an. Der SSH Zugang ist eindeutig mit der IP möglich.

Der offene Punkt: Die /etc/network/interfaces habe ich nicht verändert. Eigentlich sollte sie doch überflüssig sein?

EDIT:
Auf http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_Network.htmlist eine weitere Erklärung, siehe Abschnitt: Netzwerk einrichten ab Raspbian "Jessie"
 
Zuletzt bearbeitet:
Danach und mit diesem Block angefügt in /etc/dhcpcd.conf geht es!
Code:
interface eth0
static ip_address=192.xxx.yyy.{IP}
static routers=192.xxx.yyy.1
static domain_name_servers=8.8.8.8 8.8.4.4

Wenn Du "static" verwendest sollte die IP-Adresse von außerhalb des DHCP-Pools der FB sein.

Ich bleibe dabei, dass "request" (un der dhcpcd.conf) m. E. eleganter als "static" ist, denn mit "request" wird (durch den dhcpcd) ein "Wunsch an den DHCP-Server geäußert", immer die gleiche IP-Adresse aus dem DHCP-Pool der FB zugewiesen zu bekommen.

Entsprechendes für WLAN.

Der offene Punkt: Die /etc/network/interfaces habe ich nicht verändert. Eigentlich sollte sie doch überflüssig sein?

Die interfaces-Datei (networking) ist nur dann überflüssig, wenn Du den wpa_supplicant nicht mit Hilfe der interfaces-Datei startest. Wenn das der Fall ist (und Du auf die interfaces-Datei verzichten willst), könntest Du alternativ eine service-unit für den wpa_supplicant schreiben/nutzen.

EDIT:

Beachte, dass der Link aus deinem EDIT, "Letzte Aktualisierung: 10/20/2016 13:15:01" hat. D. h., nicht gerade aktuell.
 
Zuletzt bearbeitet:
@sf3978 Also PRIMA supported!

Habe deine und andere Punkte berücksichtigt
-- static IP außerhalb des Router/DHCP Pools
-- static ip_address=192.xxx.yyy.{IP}/24 << fehlte
-- /etc/network/interfaces auf ursprüngliche Werte zurückgesetzt

Und ja ...
EDIT:
Beachte, dass der Link aus deinem EDIT, "Letzte Aktualisierung: 10/20/2016 13:15:01" hat. D. h., nicht gerade aktuell.
... ist etwas ältlich, aber an anderen Stellen im Netz stehen eigentlich die gleichen Infos (wer schreibt von wem .. :grin:).

Jetzt läuft der RPI wie gewünscht, die IPs sind wie sie sein sollen!

Als "Kür" wäre noch zu überlegen (später) mal auf systemd über zu gehen. Siehst du dafür Gründe oder lieber "never touch a running system"?
 
Als "Kür" wäre noch zu überlegen (später) mal auf systemd über zu gehen. Siehst du dafür Gründe oder lieber "never touch a running system"?

Naja, Gründe nicht, denn dhcpcd funktioniert zuverlässig.

Aber wenn Du systemd-networkd ausprobieren willst, dann könntest Du z. B. das wlan0-Interface beim dhcpcd belassen und die Konfiguration bzw. IP-Adress-Zuweisung für das eth0-Interface mit Hilfe von systemd-networkd machen. dhcpcd und systemd-networkd kann man ohne Probleme auch parallel verwenden. Später kannst Du dich dann, für eines der beiden entscheiden.
 

Statistik des Forums

Themen
246,361
Beiträge
2,250,846
Mitglieder
374,014
Neuestes Mitglied
flindiesel
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.