Kein ping auf lokale fe80:: Adresse, host tut's aber

[incredibletimbo]

Moin!
Was ich gern wüsste:
Warum kann ich auf jedem meiner Rechner die link-lokale Adresse der Schnittstelle pingen außer auf meinem antiken Raspberry Pi 1B?

Zum Szenario:
Mein antiker Raspberry Pi 1B dient innerhalb und außerhalb des Hauses als NTP- Server (Hardware- Empfänger für den Sender der physikalisch- technischen Bundesanstalt AKA Funkuhr)
Er sitzt per LAN in meinem kleinen Heimnetz. Statische IP- Einrichtung via systemd-networkd, also statische Adressen für IPv4 und IPv6. Auch die Routen sind statisch gesetzt.
So ziemlich alles LÄUFT. Die WLANs der Familie in entfernten Städten synchronisieren ihre Uhrzeit auf meinen kleinen NTP-Server, wozu mein Heimstrick- Router (aktuell Raspberry Pi 4) Port 123 UDP auf ebendiesen Raspi 1B forwardet. eth0 ist die einzige verfügbare Schnittstelle, kein WLAN in diesem Möfchen!

ABER:
In unregelmäßigen Abständen (alle paar Minuten) reißt die Verbindung zum Raspi1B ab, weil intern die IPv6- Adresse "verschwindet" - garniert mit der Log- Meldung

ICMPv6: RA: ndisc_router_discovery failed to add default route

Der betreffende Router hat die Ports 546 und 547 (UDP) LAN- seitig offen stehen. Alle anderen heimischen Geräte rennen LAN- technisch WIE HULLE, nur mein altes Schätzchen stottert IPv6- seitig. Das Gateway ist einwandfrei link-lokal und global zu erreichen.

Jetzt fiel mir auf, dass der Kleine kein ping auf seine link-lokale Adresse zurück bekommt, also

ping fe80::ba27:ebff:fea1:f888

wird ausgeführt, aber es kommt nie etwas zurück. Die globale IPv6- Adresse ist oben und funktional währenddessen.

Ich unterstelle dem Kleinen Hardware- Ausfälle. Gestern maß ich mit dem frisch erstandenen USB- Leistungsmesser, was der Kleine so an Strom zieht: Maximal 2,5 Watt bei 5,1 Volt. Das Netztteil gäbe doppelt so viel her, daran scheint es mir nicht zu liegen.

Hat noch jemand eine Idee, wonach ich schauen kann?
Frohen dritten Advent aus dem Münsterland!

timbo

[incredibletimbo]

Ergänzung:

ping ::1

tut's.

[mat6937]

ping fe80::ba27:ebff:fea1:f888

wird ausgeführt, aber es kommt nie etwas zurück.

Versuch mal mit:

Code: Alles auswählen

ping6 -c 3 -I eth0 fe80::ba27:ebff:fea1:f888

oder mit:

Code: Alles auswählen

ping -6 -c 3 fe80::ba27:ebff:fea1:f888%eth0

[incredibletimbo]

Tut's ...
Womit es wohl ein Routing- Problem ist.

ip -6 route show

sagt:
::1 dev lo proto kernel metric 256 pref medium
2fff:6020:4c16:bf01:ba27:ebff:fea1:f888 dev eth0 proto kernel metric 256 pref medium
2fff:6020:4c16:bf01::/64 dev eth0 proto ra metric 1024 pref medium
default via fe80::abe:acff:fe21:77b6 dev eth0 proto static metric 1024 pref medium

Das ist eine Route mehr, als ich eingerichtet habe. NetworkManager ist abgeschaltet. (globale IP-Adressen verfremdet...)

[michaa7]

bei IPv6 genügt die IP alleine nicht zum Verbindungsaufbau. Man muss %<interfacename> dranhängen, bei dir also

Code: Alles auswählen

ping  fe80::ba27:ebff:fea1:f888%eth0

https://labs.ripe.net/author/philip_hom ... addresses/

In short, it is not possible to use an IPv6 link-local address in sockets API without selecting an appropriate interface as well. This is a significant departure from the past: knowing an IP address is no longer enough.

Textual representation of scoped addresses
One question remains: is there a textual representation that contains both an IPv6 address and an outgoing interface? The answer is yes. RFC 4007 (IPv6 Scoped Address Architecture) introduces the percent sign ("%") as a separator between an IPv6 address literal and a zone_id. It describes that a zone identifier can be numeric or a string. Therefore, we can refer to the address fe80::1 on interface eth0 as fe80::1%eth0 and (if eth0 maps to interface number 1) as fe80::1%1.

[incredibletimbo]

Okay, danke!
Das leuchtet so weit ein, darüber war ich früher schon man gestolpert, mir war das mit der Ambiguität der link-lokalen Adressen bloß nicht eingefallen. Spätestens beim Router (mehrere Netzwerke) leuchtet es auch unmittelbar ein.

Wo es weniger einleuchtet, ist der Client mit nix als eth0. (Ich brauche diese altmodischen Namen...) Ich habe ja keinen entfernten Rechner angepingt, sondern die eigene, einzige Schnittstelle (abgesehen von loopback). Auf jedem anderen vorhandenen Rechner tut's das auch, nur eben nicht auf dem ollen Raspi. Da ich mit Netzwerkkarten schon Schräges erlebt habe, hatte ich jetzt mal auf Alterserscheinungen getippt. Das "Problem" ist somit keins mehr. Nach Lektüre meiner Routing- Tabelle meinte ich, der Rechner käme notfalls selbst drauf, wo er die Adresse erreichen kann.

Nochmals Danke!

[wanne]

Der Unterschied ist der Scope: Es ist ein explizites feature dass du die Reichweite beschränken kannst. Du kennst das von früher: 169.254.0.0/16 war immer aufs Subnet beschränkt und hat explizit nicht über router funktioniert. ::1 oder 127/8 explizit nur auf deinem Host. Es ist ein Feature, dass du da immer sofort sehen kannst dass du nur in gewissen Grenzen kommunizieren kannst. Auch wenn du problemlos deinem Nachbarrechner 127.0.0.1 und dir 127.0.0.17 geben könntest. Du willst nicht, dass die Kommunikation funktioniert, weil niemand erwartet dass 127.0.0.1 der Nachbarrechner ist. Der scope für fe80::/64 ist das Interface. Die Idee ist explizit dass selbst die Kommunikation innerhalb eines Hosts nicht funktioniert. Selbstverständlich erlaubt dir Linux den scope zu ändern. Machen solltest du das besser nicht.

[mat6937]

... von früher: 169.254.0.0/16 war immer aufs Subnet beschränkt und hat explizit nicht über router funktioniert.

Inzwischen geht es auch über den Router. Z. B.:

Code: Alles auswählen

:~ $ ip r g 169.254.1.1
169.254.1.1 via 192.168.178.1 dev eth0 src 192.168.178.13 uid 1000 
    cache 

[incredibletimbo]

Danke für die Klarstellung!
Das Scope- Thema war mir tatsächlich entfallen. So gründlich sind meine Netzwerk- Kenntnisse dann doch nicht.
Ich schätze, im Moment sind alle Fragen beantwortet.
Mir bleibt noch rasuzufinden, warum mein Raspi1B ale paar Minuten seine (statische) IPv6- Adresse verliert.
Stromversorgung scheint es nicht zu sein.
Prost 2. Frühstück!

timbo

[mat6937]

Mir bleibt noch rasuzufinden, warum mein Raspi1B ale paar Minuten seine (statische) IPv6- Adresse verliert.

Ist die Interface-ID dieser (statischen) IPv6-Adresse mac-addressen-basiert? Hast Du in deinem Raspi1B die PEs (privacy extensions) deaktiviert?
Wie bekommt der Raspi1B, nach dem er seine (statische) IPv6-Adresse verloren hat, diese wieder?

[incredibletimbo]

Oh, jetzt habe ich ein paar Tage nicht geschaut - brauchbare Ablenkung in der Zwischenzeit...

PE sind deaktiviert wg. statischem Routing im Router (Badumm- Tsss!) zwecks externem Zugriff.

Aktuell ist die IP6- Adresse statisch (systtemd-networkd) konfiguriert, was jetzt schon eine Woche ohne Abriss funktioniert. Ob statisch oder DHCPv6: Die Adresse bricht schon mal ohne erkennbaren Anlass weg. Ich argwöhnet schon, dass das Netzteil des Raspi unterdimensioniert ist, aber laut Messung zieht er maximal 2,5 Watt aus einem 5 Watt- Netzteil.

Worauf ich gerade nicht klar komme, ist die Differenz zwischen Einrichtung [1] und Ergebnis [2]. Die Netzmaske ist eine andere und ich weiß nicht woher (/64 in der Config, /128 laut "ip a s"). Ich meine zu wissen, dass ich die IP-Adresse "gebastelt" habe aus Subnetz und MAC- Adresse. Hab ich einen Scheiß gebaut? Ich könnte einen Kontrollblick von außerhalb gebrauchen!
Danke vorab für Denken und Gucken!

tim

[1] /etc/systemd/networkd/eth0.network

Code: Alles auswählen

[Match]
MACAddress=b8:27:eb:a1:f8:88

[Link]
ARP=true

[Network]
Address=192.168.25.123/24
Address=dead:beef:4c16:bf01:ba27:ebff:fea1:f888/64
DHCP=false
Gateway=192.168.25.4
Domains=hell.local
IPv6PrivacyExtensions=no

[Route]
Gateway=fe80::abe:acff:fe21:77b6

[2] Output von "ip a s" :

Code: Alles auswählen

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: enxb827eba1f888: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:a1:f8:88 brd ff:ff:ff:ff:ff:ff
    inet 192.168.25.123/24 brd 192.168.25.255 scope global enxb827eba1f888
       valid_lft forever preferred_lft forever
    inet6 dead:beef:4c16:bf01:ba27:ebff:fea1:f888/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fea1:f888/64 scope link 
       valid_lft forever preferred_lft forever

[incredibletimbo]

Wie der Raspi seine Adresse zurück erlangt nach Abriss ? Per besonders primitivem "ip replace address" per cronjob. Seit dem 14. ist es offenbar nicht mehr nötig geworden. Ich werde nicht recht schlau draus.

[incredibletimbo]

Nachtrag:
Zu meiner Überraschung läuft er seit dem letzten Reboot stabil ohne Abriss. Das korreliert mit der letzten Änderung an /etc/systemd/network/50-eth0.network, die ich hier poste: Statische Config, keinerlei DHCP. Kann Zufall sein, aber so stabil lief er noch nicht bislang.

[Match]
MACAddress=b8:27:eb:a1:f8:88

[Link]
ARP=true

[Network]
Address=192.168.25.123/24
Address=2aaa:cdef:4c16:bf01:ba27:ebff:fea1:f888/64
DHCP=false
Gateway=192.168.25.4
Domains=hell.local
IPv6PrivacyExtensions=no

[Route]
Gateway=fe80::abe:acff:fe21:77b6