[Gelöst] Kein Zugriff auf Fritzbox 7490

Das war allerdings nur ein kurzer Test auf einem einzelnen System und daher halte ich die Aussage selbst nicht für repräsentativ. Ich habe jetzt noch ein zweites System getestet und hier lässt sich die Adresse 169.254.1.1 problemlos ansprechen.
Wer weiß, ob es irgendwelche Registry-Einstellungen gibt, die das Verhalten beeinflussen oder was in den jeweiligen Netzwerktreibern gemacht wird. Für eine belastbare Aussage müsste man da wohl tiefer forschen.
 
Heute habe ich mit bestimmten Stichwörtern von Dir, @klp55tsch ("LinkLocalAddressing") und @Hagen2000, im Hinterkopf noch ein wenig in den Netzwerkeinstellungen gestöbert und das "Geheimnis" gefunden: Bei den vorhandenen Linux-Systemen bietet der Netzwerkmanager (GUI) auf dem Reiter "IPv4-Einstellungen" sechs verschiedene "Methoden" an. Standardmäßig ist "Automatisch (DHCP)" eingestellt, und ich habe es geändert auf "Nur per Link-Local". Jetzt funktioniert es.

Da ich die Situation hier nicht 1:1 nachstellen kann, weil meine FB 7490 per Mesh ins Netzwerk eingebunden war/ist und die in Spanien händisch konfiguriert wurde, weiß ich nicht, warum die Tests mit nicht mehr ganz aktuellen Linux-Systemen funktionierten, denn hier tun selbst die es auch nur mit "Link-Local". Wenn Deine Überlegung richtig sein sollte, @Hagen2000, dürfte es demnach umgekehrt sein - dass sich Linux richtig verhält, Windows 10 (jedenfalls meines) und MacOS hingegen nicht.
 
Letztlich sollte man sich nicht darauf verlassen, dass man Adressen aus dem 169.254/16-Netz (APIPA / link-local) erreichen kann, wenn der benutzte Rechner eine gültige IP-Adresse (per DHCP oder statisch) hat. Ein Betriebssystem, das sich 100% strikt an den RFC 3927 hält, sollte Pakete an diese Adressen verwerfen - außer es hat selbst eine Adresse aus diesem Bereich.
Es gibt offenbar viele Implementierungen, die das ignorieren und die entsprechenden Pakete einfach an die Default-Route schicken. Wenn diese zur FRITZ!Box führt, was bei den meisten Netzen der Fall sein wird, dann funktioniert der Zugriff "eher zufällig".

Ansonsten muss man entsprechende Einstellungen bemühen, wie Du es mit
"Nur per Link-Local"
gemacht hast.
 
  • Like
Reaktionen: Grisu_
Letztlich sollte man sich nicht darauf verlassen, dass man Adressen aus dem 169.254/16-Netz (APIPA / link-local) erreichen kann, wenn der benutzte Rechner eine gültige IP-Adresse (per DHCP oder statisch) hat.
Würde ich so nicht sagen: Fritzboxen als Erst- bzw. Mastergeräte machten bei mir noch nie diesbezügliche Probleme und machen auch aktuell keine - offenbar aber dann, wenn sie als Clients in Betrieb sind.
Es gibt offenbar viele Implementierungen, die das ignorieren und die entsprechenden Pakete einfach an die Default-Route schicken. Wenn diese zur FRITZ!Box führt, was bei den meisten Netzen der Fall sein wird, dann funktioniert der Zugriff "eher zufällig".
Auch das gilt IMO nur für Client-Konfigurationen: Dann haben die Fritzboxen entweder vom Mastergerät zugewiesene IP-Adressen oder - wenn die Verbindungen dorthin getrennt sind - keine.

Jedenfalls sind die Publikationen von AVM/Fritz (und vielen anderen, die im Internet zu finden sind) in diesem Punkt unzureichend und helfen nicht weiter, sonst wäre ich in dieser Frage nicht dermaßen ins Schleudern gekommen. Behauptet wird ja, dass mit der Notfall-IP-Adresse immer auf Fritzboxen zugegriffen werden kann. Wenn das nicht funktioniere, sei entweder eine Fritzbox falsch konfiguriert, was nur durch Zurücksetzen auf Werkseinstellungen gelöst werden könne. Das hatte mir auch der Support empfohlen. Im Client-Fall ist das aber falsch. Oder das Netzwerkgerät (z.B. ein Rechner) sei falsch konfiguriert. Formal ist genau das zwar korrekt (jedenfalls bei meinen genannten Linux-Systemen), denn die Standardeinstellung "Automatisch (DHCP)" funktioniert ja nicht. Ein nicht gerade mit üppigen Kenntnissen ausgestatteter Anwender aber steht damit im Regen. Dass die Einstellung Link-Local gewählt werden muss, habe ich ja - angeregt durch die Diskussion hier - eher zufällig und durch ausprobieren entdeckt.
 
Dass die Einstellung Link-Local gewählt werden muss, habe ich ja - angeregt durch die Diskussion hier - eher zufällig und durch ausprobieren entdeckt.
Schau mal nach, ob Du mit der Einstellung "Link-Local" im NM (oder gleichwertiges Frontend) sowohl eine (autogenerierte) LL-IPv4-Adresse aus dem Subnetz 169.254.0.0/16 als auch per dhcp-zugewiesen, eine IP-Adresse aus dem Subnetz des DHCP-Servers/Routers/gateway (für das Interface) bekommst.
 
offenbar aber dann, wenn sie als Clients in Betrieb sind
Ganz genau, denn im Client-Modus ist die FRITZ!Box nicht das Ziel der Default-Route und nur wenn der verwendete Computer selbst im 169.254/16-Netz ist, kann er mit solchen Geräten kommunizieren.

@klp55tsch Hier auf einem AlmaLinux 8 heißt die Einstellung für IPv4 "Nur Link-Local" und dann erhält man auch nur eine IPv4-Adresse aus dem APIPA-Bereich.
 
..., denn im Client-Modus ist die FRITZ!Box nicht das Ziel der Default-Route und nur wenn der verwendete Computer selbst im 169.254/16-Netz ist, kann er mit solchen Geräten kommunizieren.
Das stimmt so nicht. Es muss nicht zwingend die default route sein und der verwendete Computer braucht auch keine IP aus dem Subnetz 169.254/16. Es geht auch mit einer definierten Route, wenn man das richtige/zuständige gateway benutzt. Hat der TE doch bereits gemacht, ... siehe die Beiträge #11 und #12 in diesem Thread.
Definierte Route:
Code:
ip -4 route add 169.254.1.1 via 192.168.0.104 dev wlo1
 
Formal stimme ich Dir zu, aber bevor man explizit so eine Route auf die FRITZ!Box setzt, ist es doch einfacher, die FRITZ!Box gleich mit der richtigen IP-Adresse anzusprechen. Bei meiner Aussage in #46 bezog ich mich auf ein System, welches noch nicht durch spezielle Routen (oder andere Konfigurationsmaßnahmen) verändert worden ist.
 
..., aber bevor man explizit so eine Route auf die FRITZ!Box setzt, ist es doch einfacher, die FRITZ!Box gleich mit der richtigen IP-Adresse anzusprechen.
Ja, wenn man die "richtige" IP-Adresse der FritzBox kennt ... bzw. das hat der TE dann auch so gemacht (siehe sein Beitrag #8).
Dort schreibt er aber weiter, auch:
Das ursprüngliche Problem war/ist damit gelöst. Allerdings verstehe ich immer noch nicht, warum es mit der Notfall-IP-Adresse nicht geht.
 
Ja, hatte ich geschrieben - in Posting #14 aber auch:

Wenn für die erfolgreiche Ausführung des Kommandos die eigentliche IP-Adresse des Notebooks benötigt wird, ergibt das Ganze eigentlich keinen Sinn.

Es ist schon so, wie @Hagen2000 schreibt: Wenn die der Fritzbox zugewiesene IP-Adresse bekannt ist, wird die Notfall-IP nicht benötigt. Mir ging es am Anfang ja schließlich um die Frage, wie ich an die Box herankomme. Deshalb erschließt sich mir immer noch nicht, wozu das von Dir vorgeschlagene und von mir ausprobierte ein Konstrukt gut sein soll ("definierte Route").

Zu Deinem Vorschlag in #45: Ob die Tests zu hier wirklich aussagekräftigen Ergebnissen führen, bin ich mir nicht sicher: Im "angestöpselten" Zustand befindet sich die FB 7490 hier als Client nämlich (per Mesh) hinter einer FB 7590. Von der bekommen sie und der Rechner die IP-Adressen. Das müsste zwar in etwa der Situation in Spanien entsprechen: Die Internetverbindung klappte dort ja von vornherein, weil sowohl das Notebook eine IP-Adresse vom Master-Gerät (TP-Link) bekommen hatte (192.168.0.108), als auch die Client-FB 7490 (192.168.0.104), die mir zunächst nicht bekannt war. Die Art der Einbindung aber ist hier ja eine andere. Ich habe es trotzdem getestet.

Im eingestöpselten Zustand mit der Einstellung "Link-Local" gibt hostname -i hier aus: 127.0.1.1. Internetverbindungen funktionieren nicht. Die Notfall-IP-Adresse lässt sich anpingen und die Benutzeroberfläche damit öffnen. Mit der Standardadresse 192.168.178.1 funktioniert beides nicht.

Mit der Einstellung "Automatisch (DHCP)" gibt hostname -i hier ebenfalls nur 127.0.1.1 aus. Internetverbindungen funktionieren, und sowohl die Standard-Adresse, als auch die Notfall-IP-Adresse lassen sich anpingen. Während sich mit 192.168.178.1 aber die Benutzeroberfläche der FB 7590 (Master) öffnet, ist es mit 169.254.1.1 - anders, als ich erwartet hatte - die der FB 7490 (Client). Vielleicht, weil der Rechner an der angeschlossen ist?

Auch im ausgestöpselten Zustand gibt hostname -i aus: 127.0.1.1. Ping und Zugriff auf Benutzeroberfläche mit 169.254.1.1 möglich. Nach dem Login sehe ich, dass der Rechner die Adresse 169.254.157.207 bekommen hat, die FB 7490 selbst aber 192.168.178.2 - also die Adresse, die ich ihr irgendwann mal zugewiesen hatte (das ist bei einer frisch konfigurierten FB wie in Spanien natürlich anders).

Offen gestanden: Mich verwirrt das Ganze. Die Frage allerdings ist, ob es sich lohnt, die Sache noch weiter zu ergründen. Klar ist bei meinen Anwendungsszenarien ja, dass mit wenigen Mausklicks die IPv4-Einstellung auf Link-Local geändert werden muss und ich dann auch auf die FB zugreifen kann. Dann dürfte ich auch die (vom Mastergerät zugewiesene) IP-Adresse der FB sehen und kann damit weitermachen.
 
Vielleicht passt das zu deiner Situation in Spanien ....
Behauptet wird ja, dass mit der Notfall-IP-Adresse immer auf Fritzboxen zugegriffen werden kann. Wenn das nicht funktioniere, sei entweder eine Fritzbox falsch konfiguriert, was nur durch Zurücksetzen auf Werkseinstellungen gelöst werden könne. Das hatte mir auch der Support empfohlen. Im Client-Fall ist das aber falsch.
So habe ich bisher keine Probleme mit meinen IP-Clients erlebt. Irgendwo habe ich mal dazu gelesen, dass diese Notfall-IP 169.254.1.1/16 (bei IP-Clients) nur für 10 Minuten nach dem Einschalten (Stromtrennen) erreichbar ist. (Quelle unbekannt bzw. nicht wiedergefunden)

Wenn ich meine Accesspoints (7490, 3490, 7272) konfiguriere, lasse ich mir nie so viel Zeit. Nach 10 Min. sind sie erneut vom Strom getrennt und beziehen eine IPv4 vom DHCP-Server und werkeln als AccessPoint im LAN für Jahre dahin.
 
Dieser Befehl ist nicht gut geeignet, denn er zeigt zu deinem Hostnamen die vergebenen IP-Adressen an. Dein Hostname lautet offenbar localhost, denn es werden nur 127-er IP-Adressen angezeigt.
Verwende besser folgende Befehle: ifconfig oder ip addr und zusätzlich route oder ip route um in der Routing-Tabelle nach Einträgen zu suchen, die das Netz 169.254.0.0/16 betreffen.
 
Dieser Befehl ist nicht gut geeignet,
Das hatte ich mir schon gedacht.
Dein Hostname lautet offenbar localhost, denn es werden nur 127-er IP-Adressen angezeigt.
Nein. Der Hostname lautet DRES. localhost mit der IP-Adresse ist ein (Standard-)Eintrag in der Datei hosts.
Verwende besser folgende Befehle: ifconfig oder ip addr und zusätzlich route oder ip route
route allein oder mit einem der beiden anderen Befehle vorangestellt funktioniert nicht, ebenso wenig wie ifconfig ohne Root-Rechte. Hier die Ausgabe mit eingestöpselter FB 7490 (Client) und aktiver Verbindung Link-Local:

sudo ifconfig && ip route

Für den Teil, der für ifconfig zuständig ist, wird im Abschnitt enp0s25 u.a. diese Zeile ausgegeben:

inet 169.254.157.207 netmask 255.255.0.0 broadcast 169.254.255.255

... und im Abschnitt lo diese:

inet 127.0.0.1 netmask 255.0.0.0

... und schließlich dem dem für ip route zuständigen:

169.254.0.0/16 dev enp0s25 proto kernel scope link src 169.254.157.207 metric 100
224.0.0.0/4 dev enp0s25 proto static scope link metric 100

Soweit ich erkennen kann, bringen diese Befehle aber gegenüber der Methode, bei aktiver Verbindung Link-Local mittels Notfall-IP-Adresse auf die Benutzeroberfläche der FB zuzugreifen und dort nachzusehen keinen wirklichen Erkenntnisgewinn.
 
Das hatte ich mir schon gedacht.

...

route allein oder mit einem der beiden anderen Befehle vorangestellt funktioniert nicht, ebenso wenig wie ifconfig ohne Root-Rechte.
BTW: Richtig angewendet, funktioniert alles (... auch ohne sudo). Z. B., versuch mal (... als normaler user und _nicht_ als root):
Code:
hostname
hostname -i
hostname -I
/usr/sbin/ifconfig
/usr/sbin/route
echo $PATH
 
ifconfig ohne sudo funktioniert hier nicht. Was soll dabei nicht richtig angewendet worden sein?

hostname -i funktioniert auch ohne sudo, aber das hatte ich vorherigen Postings bereits geschrieben. Die anderen Versuche lasse ich sein, denn sie führen vom eigentlichen Thema weg: Die Sache ist doch schon geklärt. Mein Hinweis zu ipconfig war nur eine Anmerkung.
 
ifconfig ohne sudo funktioniert hier nicht. Was soll dabei nicht richtig angewendet worden sein?
Du musst als normaler user, den absoluten Pfad benutzen, weil "/usr/sbin" nicht in der PATH-Variable deines users ist. Siehe die Ausgabe von "echo $PATH", als normaler user. BTW: Von hostname (... ohne und mit -i, -I) mit sudo war nicht die Rede.

EDIT:

... und die Ausgaben von:
Code:
whereis hostname
whereis route ifconfig
 
Zuletzt bearbeitet:
Kostenlos!

Zurzeit aktive Besucher

Keine Mitglieder online.

Statistik des Forums

Themen
247,814
Beiträge
2,274,115
Mitglieder
376,775
Neuestes Mitglied
heino_h