[gelöst] Wie kommt die IP in meinen Rechner?

[TomL]

... jaaa.... is klar... übers Kabel.... ... aber ganz so einfach ist die Antwort doch nicht.

Ich versuche gerade hier mit ein paar Experimente Zusammenhänge zu verstehen und komm jetzt nicht mehr weiter. Das hier folgend sind die Fakten... auf meinem Pi (Testrechner):

• ist definitiv kein dhcpcd als Daemon installiert und aktiviert
• ist /etc/init.d/networking deaktiviert
• enthält /etc/networking/interfaces keine zur Netzwerk-Etablierung relevanten Einträge
• wird das Netzwerk über systemd-networkd gestartet
• gibt es KEINE /etc/systemd/network/eth0.network (hab sie um Fehler zu provozieren einfach mal wegkopiert)

Da es sich hier um meinen Test-Pi handelt und ich den Zugriff via SSH nutze, habe ich in "screen" folgende Jobs gestartet, die mir den Zugriff spätestens nach 3 Minuten wieder ermöglichen sollen:

Code: Alles auswählen

sleep 15;ip link set dev eth0 down;ip addr flush dev eth0; sleep 10;ip link set dev eth0 up; sleep 180; dhclient -v eth0

Ich starte den Job und habe dann 15 Sekunden Zeit, den Pi ordentlich zu verlassen. In einem Parallelfenster meines PC habe ich einen Ping auf den Pi vorbereitet... und wie gewollt, ist er kurz noch erreichbar, dann 10 Sekunden nicht mehr... und dann ist er wieder da... und ich mach nen dummgesicht. Wieso ist der nach 10 Sekunden schon wieder da, mit seiner IP, obwohl das eigentlich gar nicht sein dürfte? Ich hatte erwartet, dass ohne einen Helfer (i.ü.s. dh-client) der Pi erst nach 180 Sekunden zurück ist.... war'n aber keine 3 Minuten... eben nur genau die 10 Sekunden. Wie geht das?

Beim erfolglosen Suchen nach Fehlermeldungen im Journal bin ich über avahi gestolpert, der sich dort beim Starten des Netzwerks ein Wechselspiel mit systemd-networkd liefert. Ist systemd-networkd oder vielleicht avahi gleichzeitig auch ein dh-Client?

[mat6937]

... bin ich über avahi gestolpert, der sich dort beim Starten des Netzwerks ein Wechselspiel mit systemd-networkd liefert. Ist systemd-networkd oder vielleicht avahi gleichzeitig auch ein dh-Client?

Das mit dem avahi-daemon könnte schon stimmen.

Versuch mal für deinen Test, den src-udp-Port 5353 mit iptables zu blocken. Auch in der INPUT chain, den src-udp-Port 5353 blocken, denn die FritzBox lauscht auf dem Port (für multicast-dns):

Code: Alles auswählen

:~ $ nc -zv -u 192.168.178.1 5352 5353 5354
Connection to 192.168.178.1 5353 port [udp/mdns] succeeded!

[TomL]

Tja, avahi ist es wohl nicht.... ... ich denke jetzt, in systemd-network ist ein eigener dh-client implementiert.

So sieht nun aktuell 'der' Screen-Befehl aus, der mir den Zugang sichern soll:

Code: Alles auswählen

sleep 15;\
ip link set dev eth0 down;\
ip addr flush dev eth0;\
systemctl restart systemd-networkd;\
systemctl restart systemd-resolved;\
sleep 10;ip link set dev eth0 up;\
sleep 180; dhclient -v eth0

Der Schlüssel liegt wohl in der /etc/systemd/network/eth0.network, die in der [Network]-Sektion mit DHCP verschiedene Optionen zulässt. Meine erste Beobachtung war, es geht trotzdem, auch wenn die Datei nicht existiert. In dem Fall gehe ich davon, dass anscheinend ein systemd-networkd-Default-Plan greift, und zwar wird einfach der/ein 'embedded' DH-Client gestartet. Die Einstellung

• DHCP=yes verlangt einen externen DH-Client-Aufruf oder einen aktiven dhcpc.service, der als Daemon selbstständig auf die Netzverbindung reagiert
• DHCP=no setzt Static-IPs voraus

Für den letzten Versuch habe ich ausserdem mit Risiko auch noch den DH-Client aus dem Rennen genommen:

Code: Alles auswählen

mv /sbin/dhclient /sbin/dhclient.sik

Und es geht trotzdem hiermit... es aktiviert m.E. den 'embedded'-DH-Client

• DHCP=v4

Mein Fazit: systemd-networkd muss auch dh-client-Funtionen eingebaut haben. *hmmm*

[mat6937]

Mein Fazit: systemd-networkd muss auch dh-client-Funtionen eingebaut haben. *hmmm*

Du könntest zum testen, mit iptables auch die portrange 67-68 blocken. Dann sollte der ominöse dh-client keinen Zugang zu einem DHCP-Server haben.

EDIT:

Auf einem 2. Linux-PC in deinem (W)LAN, könntest Du mit:

Code: Alles auswählen

tcpdump -vvven ether dst ff:ff:ff:ff:ff:ff and udp portrange 67-68

verfolgen, ob von deinem PI aus, ein DHCP-discover oder ein DHCP-request gemacht wird.

Siehe auch:

Code: Alles auswählen

strings /lib/systemd/systemd-networkd | grep -i dhcp

und: https://www.freedesktop.org/software/sy ... .gcov.html

[guennid]

Mein Fazit: systemd-networkd muss auch dh-client-Funtionen eingebaut haben.

Frag' doch den Poettering, der müsste es wissen.

Bin gespannt, wie das hier ausgeht.

[DeletedUserReAsG]

Frag' doch den Poettering, der müsste es wissen.

Weil kurz suchen oder Doku lesen zu schnell und zu einfach ginge? systemd-networkd kann DHCP verwenden, wenn es entsprechend konfiguriert ist.

[guennid]

Weil kurz suchen oder Doku lesen zu schnell und zu einfach ginge?

Für mich ist das Thema eh zu speziell, nichtsdestotrotz bin ich gespannt auf den Ausgang.

••• Hinweis: Von diesem User werden auch Sarkasmus und Ironie verarbeitet. Spuren davon können daher in diesem Beitrag enthalten sein •••

[TomL]

Weil kurz suchen oder Doku lesen zu schnell und zu einfach ginge? systemd-networkd kann DHCP verwenden, wenn es entsprechend konfiguriert ist.

Das es dhcp verwenden kann war unstrittig... soll heißen, dass es einen anderen Dienst in Anspruch nimmt oder den Job erledigen lässt. Wenn aber kein anderer Dienst verfügbar ist, funktioniert es trotzdem. Daraus schließe ich, dass networkd über eingebaute dh-client-Funktionen verfügt. Ich habe die Doku gelesen .... aber dazu konnte ich nichts finden.

[mat6937]

Daraus schließe ich, dass networkd über eingebaute dh-client-Funktionen verfügt.

OK, aber wenn networkd über eingebaute dh-client-Funktionen verfügt, dann müsste/sollte man networkd doch auch so konfigurieren können, dass diese eingebaute dh-client-Funktion nicht (immer) verwendet wird (... ohne den Zugang zum DHCP-Server zu blocken oder gleichwertig).

Lt. deinen Beiträgen oder zumindest bis jetzt, scheint das nicht möglich zu sein, oder?

[DeletedUserReAsG]

Warum sollte das nicht möglich sein? Eigentlich ist es eher so, dass es DHCP nur dann verwendet, wenn es so konfiguriert ist. Ich würde also zunächst mal schauen, ob und wer genau die Adresse anfordert – bislang glaube ich nicht wirklich daran, dass es der systemd-networkd ist (es sei denn, bei Raspbian weichen sie mal wieder ab [ich gehe mal davon aus, dass zumindest Raspbian verwendet wird]). Bei der Suche mag netstat helfen können.

[TomL]

Lt. deinen Beiträgen oder zumindest bis jetzt, scheint das nicht möglich zu sein, oder?

Doch, sicher, das kann man abschalten. Mit dieser Einstellung wird defintiv keine IP angefordert. Entweder man tut das dann von Hand oder vergibt eine Static-IP:

Code: Alles auswählen

DHCP=no

bislang glaube ich nicht wirklich daran, dass es der systemd-networkd ist (es sei denn, bei Raspbian weichen sie mal wieder ab [ich gehe mal davon aus, dass zumindest Raspbian verwendet wird]). Bei der Suche mag netstat helfen können.

Doch, es ist wohl so, dass systemd das selber handhaben kann. Wenn es Dir bei netstat um die typischen DHCP- Ports geht... da gibts bei mix. Ich habe mir zudem laufende Prozesse angesehen, installierte Pakete.... und definitiv habe ich keinen Dienst "dhcp-client" am Laufen. ... es ist noch nicht mal einer installiert. Darüber hinaus habe ich das im Log gefunden... das ist bei mir der erste Eintrag mit der IP:

Code: Alles auswählen

journalctl -b | grep dhc -i
Dez 16 10:48:20 thomaspc systemd-networkd[483]: eth0            : DHCPv4 address 10.100.100.41/24 via 10.100.100.1

Ich habe jetzt gerade mal folgendes gemacht.... und mal so ein bisschen drin rumgeschnüffelt:

Code: Alles auswählen

apt-get source systemd

Unter /home/downloads/systemd-215/src/libsystemd-network finde ich folgende Module:

Code: Alles auswählen

-rw-r--r--  1 root root 2,7K Dez 16 11:02 dhcp6-internal.h
-rw-r--r--  1 root root 2,1K Dez 16 11:02 dhcp6-lease-internal.h
-rw-r--r--  1 root root 6,0K Dez 16 11:18 dhcp6-network.c
-rw-r--r--  1 root root 8,9K Dez 16 11:18 dhcp6-option.c
-rw-r--r--  1 root root 5,4K Dez 16 11:02 dhcp6-protocol.h
-rw-r--r--  1 root root 2,9K Dez 16 11:02 dhcp-internal.h
-rw-r--r--  1 root root 2,5K Dez 16 11:02 dhcp-lease-internal.h
-rw-r--r--  1 root root 7,3K Dez 16 11:18 dhcp-network.c
-rw-r--r--  1 root root 8,2K Dez 16 11:18 dhcp-option.c
-rw-r--r--  1 root root 6,2K Dez 16 11:18 dhcp-packet.c
-rw-r--r--  1 root root 4,8K Dez 16 11:02 dhcp-protocol.h
-rw-r--r--  1 root root 2,6K Dez 16 11:02 dhcp-server-internal.h
-rw-r--r--  1 root root 1,5K Dez 16 11:02 ipv4ll-internal.h
-rw-r--r--  1 root root 3,8K Dez 16 11:18 ipv4ll-network.c
-rw-r--r--  1 root root 2,5K Dez 16 11:18 ipv4ll-packet.c
-rw-r--r--  1 root root  15K Dez 16 11:18 network-internal.c
-rw-r--r--  1 root root 3,5K Dez 16 11:02 network-internal.h
-rw-r--r--  1 root root  35K Dez 16 11:18 sd-dhcp6-client.c
-rw-r--r--  1 root root 5,8K Dez 16 11:18 sd-dhcp6-lease.c
-rw-r--r--  1 root root  49K Dez 16 11:18 sd-dhcp-client.c
-rw-r--r--  1 root root  23K Dez 16 11:18 sd-dhcp-lease.c
-rw-r--r--  1 root root  30K Dez 16 11:18 sd-dhcp-server.c
-rw-r--r--  1 root root 9,1K Dez 16 11:18 sd-icmp6-nd.c
-rw-r--r--  1 root root  19K Dez 16 11:18 sd-ipv4ll.c
-rw-r--r--  1 root root  21K Dez 16 11:18 test-dhcp6-client.c
-rw-r--r--  1 root root  18K Dez 16 11:18 test-dhcp-client.c
-rw-r--r--  1 root root  12K Dez 16 11:18 test-dhcp-option.c
-rw-r--r--  1 root root  11K Dez 16 11:18 test-dhcp-server.c
-rw-r--r--  1 root root 4,8K Dez 16 11:18 test-icmp6-rs.c
-rw-r--r--  1 root root 7,4K Dez 16 11:18 test-ipv4ll.c

Ich bin natürlich außerstande, dass abschließend bestätigen zu können, aber die Filenames scheinen mir schon einigermaßen selbstredend zu sein. Nach meiner Interpretation verfügt systemd über einen eigenen dhclient, den es verwendet, wenn nix anderes vorgegeben ist. Ob es vielleicht nur als Fallback gedacht ist...*hmmm*... keine Ahnung... aber es funktioniert. Einen Unterschied zwischen Rasbian und Debian kann ich nicht feststellen.

Äääh... nur mal so am Rande, warum ich mich gerade überhaupt damit befasse. Ich versuche eine Erklärung zu finden, warum auf einigen Maschinen zwei IPv4's erzeugt werden. Der Router hat für einige bestimmte Geräte feste IPs reserviert, die werden auch korrekt "geliefert", aber irgendwie wird manchmal -nicht gezielt reproduzierbar- eine zweite aus dem 'offenen' IP-Range vergeben. Bei mir sind die IPs von 1-23 die reservierten, ab 24 beginnt der dynamische IP-Range. Das heisst, irgendein DH-Client auf dem PC ruft manchmal noch mal eine IP ab. Und da ich eben keinen DH-Client installiert habe, ist das irgendwie merkwürdig.

Nachtrag:
Jetzt gerade in diesem Moment kommt mir ein Gedanke.... ich hatte bislang nämlich immer darauf verzichtet, DHCP explizit auf No zu setzen. Ich habe einfach DHCP=v4 mit # auskommentiert und eine Static-IP vergeben..... aber offensichtlich reicht das nicht. Das werde ich testen und mal beobachten. Das ist jetzt kein Widerspruch.... erst wegen dieses Problems der zweiten IP habe ich zum Testen wieder auf Static-IPs verzichtet und versucht, dass über den Router zu lösen.

[wanne]

ist definitiv kein dhcpcd als Daemon installiert und aktiviert

Sehe ich doch schon an deiner Config, deiner command line dass da installiert ist. (dhclient)

systemd-networkd liefert. Ist systemd-networkd oder vielleicht avahi gleichzeitig auch ein dh-Client?

Nope. systemd-networkd nutzt dhclient. Fehlt der funktionier er nicht. (Was mich schon massiv verwundert hat.)

Wenn du systemd verwendest, kannst du dir btw. mit systemctl status anyeigen lassen welche (durch systemd gestarteten) dienste laufen und welche Programme die am laufen haben.
wuerde mal nach dhclient suchen (mit / kann gesucht werden wie im vim) und gucken wer des verbrochen hat.

[TomL]

Noch mal.... ausdrücklich ... es gibt bei mir keinen dh-client, den networkd verwenden kann.

Code: Alles auswählen

mv /sbin/dhclient /sbin/dhclient.sik

Der 'grosse' Daemon ist gepurged und removed. Es läuft definitiv kein dh-client-dienst. Und es funktioniert trotzdem! Zusammen mit den source-code-modulen von oben bleibt da m.E. nur ein Rückschluss.

[BenutzerGa4gooPh]

Nimm doch testweise mal zeroconf/avahi weg. Ein DHCP-Client ohne funktionierenden/erreichbaren Server kriegt zeroconf. Zumindest war das bei mir mal so. Was bei "ohne Client" ist, weiss ich nicht. Eigentlich müsste avahi/zeroconf auch "zuschlagen", wenn man gar nichts konfiguriert, ist ja Sinn der Sache.
https://wiki.debian.org/ZeroConf
Avahi sorgt im lokalem Netz für IPs und Namensauflösung ohne DNS.
Avahi ist auch von Poettering.
https://de.m.wikipedia.org/wiki/Avahi_(Software)

[mat6937]

Doch, sicher, das kann man abschalten. Mit dieser Einstellung wird defintiv keine IP angefordert. Entweder man tut das dann von Hand oder vergibt eine Static-IP:

Code: Alles auswählen

DHCP=no

BTW: Lt. der manpage für systemd.network in raspbian, wäre es "none" und nicht "no":

DHCP=
Enables DHCPv4 and/or DHCPv6 support. Accepts "both", "none", "v4" or "v6".

Lt. der distributions-unabhängigen manpage für systemd.network, ist es "no":

DHCP=
Enables DHCPv4 and/or DHCPv6 client support. Accepts "yes", "no", "ipv4", or "ipv6".

D. h., m. E. haben die bei raspbian schon etwas geändert. Zum default-Wert (für "DHCP=") gibt es in der manpage keine Hinweise/Angaben.

EDIT:

There is DHCP client support integrated into systemd, so I wanted to use this instead of using another DHCP client.

Quelle: http://baptiste-wicht.com/posts/2014/10 ... -dhcp.html

[habakug]

Hallo!

AGWA beschreibt es in seinem Blog [1] so:

Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client.

Hinweise sind zu finden in

Code: Alles auswählen

$ man 5 systemd.network

Gruss, habakug

[1] https://www.agwa.name/blog/post/how_to_ ... _one_tweet

[TomL]

D. h., m. E. haben die bei raspbian schon etwas geändert.

Nee, haben sie nicht.... ist meiner Einschätzung nach alles original Debian. Das hier ist aus meiner Debian-Jessie:

Code: Alles auswählen

static const char* const dhcp_support_table[_DHCP_SUPPORT_MAX] = {
        [DHCP_SUPPORT_NONE] = "none",
        [DHCP_SUPPORT_BOTH] = "both",
        [DHCP_SUPPORT_V4] = "v4",
        [DHCP_SUPPORT_V6] = "v6",
};

Ich gehe davon aus, dass es sich hier um Versionsunterschiede handelt. Jessie (Raspian und Debian) verwenden systemd V. 215, die aktuelle Version ist aber 231. Die Freedesktop-Seiten werden sich wohl auf die aktuelle Version beziehen. Deshalb nehme ich an, diese Änderungen, sind auf Namenskonventionen beim Handling von Direktiven zurückzuführen. *hmmm*

There is DHCP client support integrated into systemd, so I wanted to use this instead of using another DHCP client.

Mit dem, was Habakug auch festgestellt hat, denke ich nun, dass das Geheimnis gelöst ist. Für mich bedeutet das, wer ein statisches Netz mit Cat5-Anbindung verwendet, kann locker auf diesen Daemon verzichten - wenn er statt /etc/init.d/networking und dem traditionellen 'ifupdown' das sowieso vorhandene systemd-networkd nutzt. Lediglich bei Verwendung von häufig wechselnden WiFi-Accesspoints und einem Netzwerk-Manager ist dieser Service ratsam. Da ich diese Fälle mit meinem eigenen Script und dem Aufruf 'dhclient' löse, gibts für mich weiterhin keinen Grund für einen solchen Dienst.

Und das Phänomen der mehreren IPv4's führe ich nun darauf zurück, dass ich DHCP nicht ausdrücklich abgeschaltet habe, obwohl ich eine Static-IP eingetragen habe.... mit anderen Worten: Customizing-Fehler. Das habe ich aber jetzt korrigiert.

Danke für Eure Mithilfe...

[mat6937]

Und das Phänomen der mehreren IPv4's führe ich nun darauf zurück, dass ich DHCP nicht ausdrücklich abgeschaltet habe, ...

Naja, merkwürdig ist das trotzdem, wenn der integrierte dhcp-Client auch ohne eine interface spezifische *.network-Datei, dem Interface (per dhcp) eine IP-Adresse zuweist. Denn Du hast in deinem 1. Beitrag u. a. auch geschrieben:

gibt es KEINE /etc/systemd/network/eth0.network (hab sie um Fehler zu provozieren einfach mal wegkopiert)

D. h., es muss lediglich systemd-networkd gestartet/aktiviert sein, denn damit wirkt auch der default Wert für "DHCP=".

[TomL]

D. h., es muss lediglich systemd-networkd gestartet/aktiviert sein, denn damit wirkt auch der default Wert für "DHCP=".

Gestartet sowieso. Aber es muss eben auch in der eth0.network ausdrücklich mit der passenden Direktive erklärt sein, was passieren soll. Und wenn die Datei ganz weg ist, vermute ich, es greift das, was jana beschrieben hat.... und zwar avahi. Das Programm soll ja eine Verbindung ohne ausdrückliches Customizing ermöglichen.... *hmmm* ... keine Ahnung, das festzustellen übersteigt meine Möglichkeiten.

[mat6937]

[Und wenn die Datei ganz weg ist, vermute ich, es greift das, was jana beschrieben hat.... und zwar avahi.

Aber Du hast doch in deinem 2. Beitrag geschrieben, dass es nicht avahi ist:

Tja, avahi ist es wohl nicht....

[TomL]

Aber das war doch zu dem Zeitpunkg nur ein Schuss ins Blaue... geraten... eine Vermutung. Ausserdem weiss ich jetzt gar nicht mehr, wie die eth0.network zu dem Zeitpunkt ausgesehen hat. Diese Aussage sollte man deshalb jetzt nicht überbewerten. Das kann auch einfach eine Fehlinterpretation gewesen sein. Ich denke, wir können das hier als erledigt betrachten.

[mat6937]

Ausserdem weiss ich jetzt gar nicht mehr, wie die eth0.network zu dem Zeitpunkt ausgesehen hat.

Zu diesem Zeitpunkt (d. h. vor deinem 2. Beitrag) hat es lt. deinem 1. Beitrag, die eth0.network-Datei nicht gegeben:

gibt es KEINE /etc/systemd/network/eth0.network (hab sie um Fehler zu provozieren einfach mal wegkopiert)