[Gelöst] FritzBox 7330 SL (freetz-trunk) kein Zugriff mehr...

[rsi]

Hallo,

ich habe versehentlich, weil ich was testen wollte, in der FritzBox ein Default-Gateway in den Routings aktiviert.
Jetzt kann ich die FritzBox über die IP nicht mehr erreichen.
Die FritzBox ist mit einem aktuellem freetz-trunk gepatched und läuft mit dnsmasq als dhcp-server.

Gibt es irgend eine Möglichkeit doch noch auf die FritzBox zu kommen, oder muss ich zwangsweise einen kompletten Reset bzw. ReInstall machen?

 

[Telefonmännchen]

Wenn Du die IP noch im Kopf hast, dann würde ich dieses Gateway mit einer zweiten Box oder anderem Router temporär zur Verfügung stellen. Vielleicht ist der Zugriff ja dann möglich.

Gruß Telefonmännchen

 

[PeterPawn]

Wenn das kein klassischer Fall für die Notfall-IP ist (wenn es die bei der Box gibt), dann weiß ich nicht, wann die jemals etwas bringen soll.

Einfach mit einem PC per LAN-Kabel verbinden, der seinerseits irgendeine Adresse aus 169.254.0.0/16 verwendet, und die Kommunikation sollte sofort funktionieren, da die Layer2-Adressen per ARP aufgelöst werden und wenn die beiden Kommunikationspartner in demselben Segment liegen, geht der Traffic direkt zwischen ihnen hin und her, da hat ein Gateway - egal was da eingestellt ist - nichts mit zu tun. Man muß eben nur die FRITZ!Box unter 169.254.1.1 ansprechen ...

 

[rsi]

Ich habe es mit der orig. IP, mit der Notfall IP (welche bei mir 192.168.178.1 ist) und allem möglichem versucht, direkt mit dem PC verbunden. Keine Chance. Ich kam nicht mehr ran. Sogar über eine zweite FritzBox nicht.

Na ja, am Ende habe ich ein Revocer und Re-Installation gemacht. Das war eigene Dummheit, weil ich nicht aufgepasst habe. Aus Fehlern lernt man bekanntlich...

 

[andiling]

Sowas kann ja immer mal beim Testen passieren... wenn man eine freetz Sicherung parat hat, sind das eigentlich nur drei Schritte um wieder auf einen funktionierenden Stand zu kommen. (-:

 

[PeterPawn]

mit der Notfall IP (welche bei mir 192.168.178.1 ist) und allem möglichem versucht

Dein Problem ist ja gelöst, trotzdem quält mich die Frage, wie das mit der 192.168.178.1 sein kann? Hast Du an der ar7.cfg herumgespielt oder ist es bei der 7330_SL tatsächlich so, daß da die "normale" IP nicht die 192.168.178.1 ist und die stattdessen für die Notfall-Adresse verwendet wird? Das wäre schon verblüffend, vor allem auch die Frage, welche Netzwerkmaske da dann verwendet wird.

 

[rsi]

Die IP wird mir auch im freetz-info als IP angezeigt. Ich habe die nie geändert, die war so. Und ja, der Zugriff darüber funktioniert normal.
Vielleicht weil es ein (gebrauchtes) 1&1 Gerät war???
Ich selber benutze als IP 192.168.100.1 und die wird mit mit der 192.168.178.1 im freetz-info angezeigt.

Zum Glück habe ich immer eine regelmäßige Sicherung, bevor ich an meine FritzBox herum spiele.

 

[PeterPawn]

Die IP wird mir auch im freetz-info als IP angezeigt.

Ich habe jetzt in den vergangenen 10 Minuten verzweifelt versucht, die von Dir angesprochene Stelle in den Freetz-Dateien für's GUI zu finden ... kannst Du mir bitte die URL der Seite geben, wo Du diese Anzeige erhältst? Ich finde sie nicht ... habe allerdings auch gerade keine Box mit Freetz zur Hand und muß daher in den "Quellen" suchen.

Alternativ wäre der Inhalt der ar7.cfg für das Interface "eth0:0" interessant, also die dort angegebene IP-Adresse und Netzwerkmaske.

Erledigt, hab' sie doch noch gefunden.

Was die Box nach einem Werksreset als Notfall-IP verwendet, steht in der Datei /etc/default.$CONFIG_PRODUKT/$OEM/ar7.cfg ... das ist der Standard-Inhalt, wenn keine existiert.
Denkste ... steht nicht drin, mithin irgendwo im dsld oder im ctlmgr bei den Defaults hinterlegt. Dann wundert es mich aber um so mehr, wenn da eine 192.168.178.1 verwendet werden sollte.

Hat die 7330_SL eigentlich 4 Ports und nur kein Telefon? Oder ist das eines von den 1-Port-Modellen?

Die Frage nach den Einstellungen des "eth0:0"-Interfaces wäre noch offen, wenn Du Lust auf eine Antwort hast.

Ich bin bloß deshalb so interessiert, weil ich das noch nicht hatte, daß die Notfall-IP die 192.168.178.1 war ... dann müßte eben in der Folge das Standard-Netz der Box ja ein anderes sein als 192.168.178.0/24 (die Notfall-IP im normalen Netz macht ja keinen Sinn) und da würde mich tatsächlich interessieren, wie das bei der 7330_SL ist bzw. warum das so abweichen könnte von den anderen Boxen.

Nach diesem Link hier müßte die auch die 169.254.1.1 verwenden ... schon komisch.

 

[andiling]

Vmtl. /cgi-bin/status/mod/box_info

Da steht bei mir als urloader ip auch die 192.168.178.1.

ar7.cfg

                name = "eth0:0";
                dhcp = no;
                ipaddr = 169.254.1.1;
                netmask = 255.255.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                no_dnsd_static = no;
                is_guest = no;
                is_hotspot = no;

 

[PeterPawn]

Ok, dann hat rsi das nur falsch verstanden. Die Urlader-IP wird von EVA verwendet, wenn in den ersten 5 Sekunden nach Power-On auf eingehende FTP-Verbindungen gewartet wird.

Die hat mit der Notfall-IP absolut nichts zu tun ... diese Notfall-IP ist eine vom Benutzer nicht (oder nur unter Kopfständen, daher auch meine Frage nach "Spielerei" an der ar7.cfg) zu verändernde IP-Adresse, die praktisch immer erreichbar ist, weil auch ein Windows-PC sich - wenn er keine Adresse per DHCP kriegt, weil die Einstellungen in der FRITZ!Box nicht stimmen - immer eine APIPA-Adresse (das ist das Subnetz 169.254.0.0/16) zuweist und somit die Kommunikation eigentlich wirklich immer klappt.

Was dann aber noch nicht erklären würde, warum die 192.168.178.1 auch in seiner Box konfiguriert ist, wenn er es auf 192.168.100.1 geändert hat ... dann sollte die eigentlich nicht zugewiesen sein, der Bootloader ist ja lange erledigt.

 

[rsi]

Ich bin zwar im Moment nicht in der Nähe der FreetzBox, aber ja... du hast da wohl recht. Mir war immer nur meine vergebene IP und die 192.168.178.1 bekannt. Woher die allerdings kommt, ist mir auch unklar. Und vor allem, warum die dann bei mir in der Box-Info angezeigt wird, zur 192.168.100.1.

Aber sobald ich kann, werde ich da noch mal genau schauen und hier posten.

 

[andiling]

In der Boxinfo wird die externe, interne und urloader IP angezeigt, in der Reihenfolge untereinander.

 

[rsi]

Das ist jetzt der typische Vorführ-Effekt!
Ich hatte ja ein Recover gemacht und siehe da... im Urloader steht jetzt auch 192.168.100.1!
Da muss bei mir was wirklich schief gelaufen sein, aber keine Ahnung wann und wo.
Einzig als "guest" wird noch 192.168.179.1 angezeigt.

Schnittstellen:  	Protokoll	IP-Adresse	Namen
dsl	Point-to-Point	192.168.100.1	fritz.box; fritz.nas; sunshine
guest	Ethernet	192.168.179.1	
lan	Ethernet	192.168.100.1	fritz.box; fritz.nas; sunshine

Aber dabei ist mir auch aufgefallen, dass der nfsd nicht mehr funktioniert. Was aber am Trunk liegen könnte und ein anderes Thema ist...

 

[andiling]

Also bei mir gibt's nach wie vor Unterschiede...

 

[PeterPawn]

@rsi:
Das, was Du da zitiert hast, hat aber mit der "Urlader-IP" nichts zu tun ... bei andiling siehst Du diese Anzeige über "Schnittstellen". Ich kann mir auch beim besten Willen nicht vorstellen, daß im Urlader-Environment tatsächlich eine 192.168.100.1 stehen sollte ... das wäre nur mit einem wilden Schreibzugriff zu erklären und könnte zumindest das AVM-Recovery-Programm vor ernsthafte Probleme stellen, wenn mal wieder Recovery fällig wäre.

 

[eisbaerin]

Urlader-Environment enthält die aktuelle oder eine ältere IP.

Den Effekt konnte ich aber schon des öfteren beobachten.
Bei FB7170 und FB7270.

Bemerkt habe ich es auch erst, als ein Recovery nicht laufen wollte.
Ich war gerade in Canada und wollte eine FB7170 auf avme umbranden.
Frage nicht wie lange ich gesucht habe.

Wann und wodurch das passiert, ist mir aber ein Rätsel.

z.Z. habe ich eine FB7170, die z.Z, die IP 192.168.4.1 hat.
Vorher hatte sie lange die 192.168.3.1.
Im Urlader-Environment steht immer noch die 192.168.3.1.
Eigentlich habe ich mit der auch schon einiges angestellt (ar7cfgchanged, voipchanged, ...).
Ich warte schon darauf, wann die sich umstellt.
Kann eigentlich nur durch ein Update oder Recovery passiert sein,
oder beim entbranden mit der Pseudo-FW.

 

[PeterPawn]

Bemerkt habe ich es auch erst, als ein Recovery nicht laufen wollte.
[...]
Frage nicht wie lange ich gesucht habe.

Das ist ja auch nicht gerade die erste Stelle, wo man sucht, deshalb habe ich parallel dann immer einen Packet-Sniffer mitlaufen. Das hilft auch, wenn tatsächlich mal das Environment zerschossen wurde ... die tolle Fehlermeldug, daß die aktuelle Version nicht ermittelt werden konnte, beschreibt ja leider mehr das Ergebnis als die (mögliche) Ursache. Die kommt wohl grundsätzlich immer, wenn das FTP-Login nicht klappt, was auch immer die Ursache sein mag. Auch prinzipiell vom Inhalt her nicht falsch ... wenn auch nur wenig hilfreich.

Ich warte schon darauf, wann die sich umstellt.

Reden wir eigentlich über Freetz oder über aufgepimpte AVM-Firmware?

Auch dann würde ich solche abweichenden Notfall-IP-Adressen eher bei altem Kram tatsächlich für wahrscheinlicher halten als bei neueren Modellen. Auch wenn nicht mit jeder Labor-Version auch ein neuer Bootloader erscheint, hat der ja in den letzten 11 Jahren doch schon einiges mitgemacht und sich wohl am wenigsten von allem verändert. Trotzdem wurden auch da sicherlich im Stillen ein paar Bugs entfernt ...

Ich hätte zwar ein paar Ideen, was die Ursache sein könnte bzw. wie man sie umzingeln kann ... aber wenn das nur alle 4 Wochen oder noch weit seltener auftritt, würde ich mir nur ein Skript basteln, das in regelmäßigen Intervallen (dank cron meinetwegen alle 24 h) den richtigen Wert wieder herstellt, wenn er sich geändert hat. Das mache ich mit "fw_attrib" im Prinzip genauso ... es wird immer erst geprüft, ob die Firmware mir böse ist und bei Bedarf dann neu gesetzt, ob ich nun vom Hersteller autorisiert bin oder nicht.

 

[the.gangster]

Nochmal für mein Verständnis:
Die Urloader-IP hat doch nichts mit der Notfall-IP zu tun, die nach wie vor aus dem APIPA-Bereich stammt, oder?
Wäre ja sinnfrei, wenn die sich ändern würde.

 

[PeterPawn]

Urlader-IP steht im Environment, APIPA-Adresse in der ar7.cfg. Letztere kann per GUI nicht geändert und somit auch nicht verbastelt werden, leider steht sie aber tatsächlich immer in einer FRITZ!Box zur Verfügung.

Damit kann sie einerseits als "feste Adresse" verwendet werden, auch von Angreifern und auf der anderen Seite nervt das tierisch, wenn man mal mehr als eine FRITZ!Box in einen Netzwerksegment hat und eine davon tatsächlich mal über die Notfall-IP ansprechen will. Da es dann ein reines Glücksspiel ist, welche Box sich als Erste auf den ARP-Request meldet, gehe ich inzwischen grundsätzlich hin (man kann auch die ar7.cfg modifizieren und dann neu starten) und lasse mir per Skript nach 10 Minuten Laufzeit einer FRITZ!Box (es gibt sogar mit "set_modulemem" schon einen Punkt, wo man sich anhängen könnte, wenn man keinen eigenen crond o.ä. betreiben will) die IP-Adresse vom Interface löschen. Allerdings stellt der dsld die dann doch gerne mal wieder her (wogegen nur der Hersteller mit Zugriff auf den Quellcode des dsld etwas tun könnte, wenn "uptime > 600 (seconds)" ist), wenn er aus irgendwelchen Gründen neu gestartet oder konfiguriert wird, deshalb ist eine "regelmäßige Nachkontrolle" unerläßlich. Wenn man wirklich mal die Notfall-IP brauchen sollte, hat die Box in der Regel ohnehin schon mehrere Neustarts hinter sich und dann schadet auch ein weiterer nicht, wenn die 10 Minuten schon um sein sollten.

Dieser Vorschlag liegt bei AVM seit Januar 2013, als mich dieses Verhalten das erste Mal tierisch genervt hat. Ich weiß aus telefonischem Kontakt auch genau, daß er bekannt ist ... es gibt wahrscheinlich schwerwiegende Gründe, warum er nicht umsetzbar ist. Was für ein Glück, daß man damit als Angreifer ohnehin nichts anfangen könnte und all die Leute, die vor "festen" Adressen im LAN warnen und davon abraten, doch am Ende nur Aluhut- und Bedenken-Träger sind. Wenn AVM das einfach genauso handhaben würde wie bei den "Werkseinstellungen" bei vergessenem Kennwort, dann wären solche Kopfstände gar nicht notwendig, wie sie bei heise.de beschrieben werden.

 

[the.gangster]

Damit kann sie einerseits als "feste Adresse" verwendet werden, auch von Angreifern und auf der anderen Seite nervt das tierisch, wenn man mal mehr als eine FRITZ!Box in einen Netzwerksegment hat und eine davon tatsächlich mal über die Notfall-IP ansprechen will.

Klar, bei mehreren in einem Segment wird's (ohne eine zu Isolieren) zum Glücksspiel.
Oder man hat einen passend vorgefüllten arp-cache.
Aber wegen der Angreifer: Du meinst solche, die bereits physischen Zugriff auf Dein Netzwerk haben, oder? Schließlich wird der APIPA-Bereich ja nicht geroutet.