Fritzbox 6490 LAN1-Buchse tot!

[betaman2]

@KunterBunter

nur zur Info: 22,22 € /Stück
(zur Zeit nicht lieferbar)

 

[KunterBunter]

Na gut, "refurbished" kann wohl auch noch als "Retail" durchgehen.

 

[betaman2]

...in Originalverpackung, mit Netzteilen und allen Kabeln!
Übrigens habe ich die auf dem Arbeitstisch liegende 6490 am 12.02.1018 für 249,- € bei MEGA-Company Euronics XXL gekauft. Jetzt suche ich eine funktionierende "recovery.exe" für einen letzten Versuch vor dem Umtausch oder Endstation AP.

 

[PeterPawn]

@fritz.fichtl:
Die Beschreibung ist nun mal "zu schmal" ... was wäre denn z.B. ein "boot loop"? Das kann vom reinen Loop im Bootloader mit 10-15 Sekunden bis zum Restart nach mehr als 120 Sekunden gehen, wo dann der "init-start"-Watchdog zuschlagen könnte.

Auch werde ich persönlich aus dem Geschriebenen dahingehend nicht schlau, was denn nun "der Port ist tot" bedeuten soll. Gibt (bzw. gab) es gar keine Ethernet-Verbindung oder wollte nur der FTP-Server im Bootloader nicht auf LAN1 reagieren? Wie oft wurde das getestet oder wurde gleich für den zweiten Anlauf ein anderer Port verwendet? Reagierte die Box schon auf das UDP-Paket nicht oder erst auf den FTP-Verbindungsversuch? Mit welchen Tools wurde diese Feststellung getroffen? Wurden dabei alle Hinweise beachtet, was den "üblichen" Einsatz dieser Tools betrifft? Auch diejenigen, die darauf verweisen, daß es ggf. mehr als einen Versuch braucht? Ist LAN1 immer noch "defekt" bei beiden Boxen - je nachdem, was das im Kontext der vorhergehenden Fragezeichen auch heißen mag?

Alles Fragen, die auch in #1 und #8 (und in der "Beschwerde" in #16) noch offen bleiben ... da wird Dir hier wohl niemand eine halbwegs passable Erklärung anbieten können, solange man diese Infos nicht hat. Und die Auskuinft, daß Dir hier niemand helfen kann bei dieser dürftigen Informationslage, bringt Dich ja auch nicht direkt weiter ... also auch eher weniger verwunderlich, wenn darauf niemand (inhaltlich) reagiert (zumindest bisher bzw. bis zu dieser meiner Antwort).

----------------------------------------------------------

Übrigens habe ich die auf dem Arbeitstisch liegende 6490 am 12.02.1018 für 249,- € bei MEGA-Company Euronics XXL gekauft.

OK, das ist dann schon zu der Zeit (jedenfalls ein Jahrtausend später, was ich jetzt mal unterstelle - oder es war doch eine sehr, sehr frühe Version der Box), wo die 6490 schon als Retail-Version vertrieben wurde.

Wobei es da immer noch bemerkenswert ist, wenn ein Händler (in D und so verstehe ich das bisher) eine offenbar ja schon lange zuvor produzierte - 15 Monate "im Regal" sind schon eine Hausnummer - internationale Version an den Mann bringt, wo vermutlich jeder halbwegs informierte Kunde die "echte Retail-Version" mit Artikel-Nummer 2000 2778 erwartet hätte ... denn m.W. ist AVM von der Aussage in Punkt 7 der FAQ: https://avm.de/service/freie-routerwahl/faqs-zur-freien-routerwahl/ nie abgewichen.

Da das noch innerhalb der zweijährigen Gewährleistung ist, würde ich erst recht die Rechnung und das damalige Angebot noch einmal ganz genau prüfen, denn die internationale Version hat (jedenfalls soweit das bisher bekannt ist) schon einige (durchaus gravierende) Nachteile.

Ist diese Box denn inzwischen "von Hand" modifiziert? Wenn nicht, welchen Wert hat denn dann "firmware_version" in der Box? Ich hätte nämlich wieder darauf gewettet, daß für die 2000 2657 (also eine Box, die sich mit OEM "avme" beim JUIS meldet bzw. melden müßte nach den bisher bekannten Infos zu dieser "internationalen Version") gar keine aktuelle Firmware gibt - jedenfalls läuft die entsprechende Abfrage ins Leere. Wobei das auch dann gilt, wenn da "avm" als Branding eingestellt sein sollte (was denkbar wäre, denn das "avm"-Branding in Kombination mit "lgi" enthielt auch alle möglichen internationalen Einstellungen) ... m.W. gibt es über JUIS gar keine Updates für Versionen < 06.60 für die 6490. Zumindest hat noch niemand hier etwas darüber berichtet, daß eine solche Box irgendwie automatisch ein Update angeboten hätte, was nicht vom Provider initiiert wurde.

Ich bin aber auch dann einigermaßen verblüfft, wenn eine FRITZ!Box 6490 Cable mit dieser Artikelnummer und Firmware 06.51 überhaupt im GUI die Möglichkeit angeboten hat, das FRITZ!OS über eine Datei zu aktualisieren ... ich kannte bis zu diesem Moment nur Versionen vor 06.6x, die die Seite für das dateibasierte Update ausblenden. Es gab/gibt zwar (seit der 06.50 afaik) eine Einstellung GUI_FORCE_FIRMWARE_UPDATE in der guiflags.lua, aber diese war bisher in jeder Firmware, die mir für die 6490 unter die Finger kam, auf false gesetzt - vielleicht war diese 06.51 ja die große Ausnahme. Diese Version habe ich leider nicht in meinem Fundus. Wobei wohl auch anderen nicht klar war/ist, welches Branding so eine internationale 6490 denn nun wirklich hat(te): https://web.archive.org/web/2019010...retail-firmware-bei-fritz-box-cable-160#p1302

Jedenfalls ist bei diesem Kaufdatum (die vorherige Angabe lautete ja zwei Jahre früher - oder 998 Jahre später) ja die gesetzliche Gewährleistungsfrist (m.W. gelten die zwei Jahre in der gesamten EU) noch gar nicht abgelaufen und eine FRITZ!Box 6490 Cable, die man nicht ohne irgendwelche Mätzchen aktualisieren kann (immer unter der Voraussetzung, daß das auch so wäre/ist - und die Notwendigkeit des manuellen Downloads gehört da für mich dazu, denn AVM veröffentlicht die Firmware ja absichtlich nicht und bietet offziell nur das "Online-Update" an), würde ich als mangelhaftes Produkt gleich wieder beim Händler abgeben (der Mangel bestand dann ja von Beginn an) und eine "echte Retail-Version" einfordern ... auch hier natürlich nur so lange, wie die Information bei bzw. vor dem Kauf nicht übermittelt wurde, daß es sich um eine eher spezielle Version handelt. Wobei man beim stolzen Preis von 249 EUR (im Feb. 2018, wo der untere Straßenpreis der Retail-6490 bei ~180 EUR lag) ja davon ausgehen könnte, daß man tatsächlich eine vollwertige Box erstanden hat.

Es wäre jedenfalls arg überraschend, wenn diese FRITZ!Box mit der original vorhandenen Firmware 06.51 (auf die man ja nach einem einmaligen Update auch wieder umschalten könnte) überhaupt eine neuere Firmware finden würde ... selbst wenn sie eine Verbindung ins Internet hat.

Es wäre "für den Überblick" (auch für andere, s.o.) hilfreich, wenn Du mal in die Export-Datei der 06.51 schaust ... interessant sind die Angaben bei "OEM=" ganz oben im Header (also das Branding - wobei die Frage wäre (s.o.), ob das geändert wurde oder noch original ist - ggf. hatte diese Box auch von Beginn an "avm") und mit etwas Glück gibt es in der "ar7.cfg" in dieser Export-Datei auch schon den Wert "version" im Abschnitt "webui" ... da stünde dann die Buildnummer. Solltest Du noch irgendwo die Supportdaten aus einer 06.51 haben oder die Ausgabe von "system_status", steht die Buildnummer auch da drin.

Die ganz große Schule wäre es, wenn Du die Box wieder auf die 06.51 umstellen würdest und dann mal den Inhalt der "juis_boxinfo.xml" (einfach "fritz.box/juis_boxinfo.xml" im Browser eingeben, wenn das Gerät an dieser Box angeschlossen ist - Alternative wäre die IP-Adresse) ausliest ... die MAC-Adresse (als "Serial") kannst Du ja unkenntlich machen. Mit diesen Angaben könnte man dann jedenfalls auch ermitteln, ob es bei AVM eine aktualisierte Firmware für genau diese "Vorgängerversion" gibt ... nur mit einer erfolgreichen Abfrage für dieses Update wäre die Box überhaupt "vollwertig" in meinen Augen, weil sie dann auch die Firmware aktualisieren kann. Bei einer 06.51 sollte es diese Datei jedenfalls bereits geben - diese Version müßte auch schon über JUIS (anstelle der alten JASON-Schnittstelle) nach Updates suchen.

Ein guter Teil der Mißverständnisse bei Deinen Lesern rührte ja daher, daß hier jeder nach Deiner ersten Beschreibung davon ausging, Du hättest tatsächlich die Retail-Version mit der Artikelnummer 2000 2778 (also die "Einzelhandelsversion" - nach der Erklärung von @stoney sollte auch dieser Begriff geklärt sein) gekauft ... die gab es halt 2016 vor August noch gar nicht und die Auslieferungsfirmware für die Retail-Boxen (selbst wenn die Hardware praktisch identisch ist) war schon die 06.6x.

Du wärst ja auch nicht der Erste gewesen, dem bei diesen Beschreibungen Fehler unterlaufen ... und am Ende hast Du Dich ja auch um knapp zwei Jahre vertan beim Eingrenzen des Kaufdatums. Das ist also alles nicht böse gemeint - es widersprach bzw. widerspricht nur den bisherigen Erfahrungswerten und wenn man diese revidieren oder erweitern soll, ist eine vorherige Nachfrage ja schon sinnvoll um sicherzustellen, daß es sich nicht noch bei anderen Fakten um einen Irrtum handelt.

Es würde mich jedenfalls auch nicht wundern (egal wie die Update-Suche ausgeht), wenn die Box sich auch mit Branding "avm" anders verhält, als eine "normale" Retail-Version. Denn in der "rc.conf" wird - wenn die Retail-Version der Firmware installiert ist, was dann für einen Standardwert CONFIG_RETAIL=y sorgt ... ansonsten wird ein weiterer Test gleich übergangen - danach noch in einer weiteren Variablen nachgesehen und zwar in DMC:

##########################################################################################
## retail
##########################################################################################
if [ "$CONFIG_RETAIL" = "y" ] ; then
testretail=`grep DMC ${CONFIG_ENVIRONMENT}`
testretail=`echo ${testretail##DMC} | tr -d ' '`
for i in `echo ${testretail} | tr ',' ' '` ; do
case $i in
RTL=y) export CONFIG_RETAIL="y"; break; ;;
RTL=n) export CONFIG_RETAIL="n"; break; ;;
esac;
done
fi

Gibt es diese Variable in Deiner Box und enthält sie ein RTL=n, wird die Firmware - vollkommen unabhängig vom eingestellten Branding (ggf. auch erst bei der 6590) - ein paar Funktionen der Retail-Version nicht anbieten, weil das in einem export CONFIG_RETAIL=n endet und dieses Flag an vielen Stellen in den Lua-Dateien abgefragt wird. Seit wann genau AVM diese Variable dafür verwendet und welche Boxen mit einem entsprechenden Geburtsfehler ausgeliefert wurden, entzieht sich aber auch meiner Kenntnis - die Abfrage existiert seit 06.8x bei der 6490. Meines Wissens ist diese zusätzliche Abfrage auch nur in den DOCSIS-Boxen vorhanden.

Jetzt suche ich eine funktionierende "recovery.exe" für einen letzten Versuch vor dem Umtausch oder Endstation AP.

Das sollte sich nun aber tatsächlich herumgesprochen haben, daß es für die DOCSIS-Modelle keine Recovery-Programme von AVM gibt.

Sollte tatsächlich mal bei einem KNB ein solches "entfleuchen" (einige werden sich vielleicht noch an den "entfleuchten Key" in den alten DOCSIS-Firmwares erinnern, den heise.de so wunderbar in dieser Weise "umschrieben" hat), dürfte dieser "Spender" kaum über die notwendigen (Urheber-)Rechte zu Verbreitung dieses Programms verfügen.

Außerdem stellt sich der kundige Leser vermutlich die Frage, welches andere Ergebnis man vom Einsatz des Recovery-Programms wohl erwarten sollte. Das liest auch nur das Environment, schreibt ein neues TFFS und dann das neue OS ... das kann man alles auch von Hand machen.

Aber man muß es nicht und wenn es sich hier tatsächlich um einen Gewährleistungsfall handeln sollte, wäre der Austausch (denn der Händler wird wohl kaum nachbessern wollen) wohl die schnellere Lösung.

 

[NDiIPP]

... Ich hätte nämlich wieder darauf gewettet, daß für die 2000 2657 (also eine Box, die sich mit OEM "avme" beim JUIS meldet bzw. melden müßte nach den bisher bekannten Infos zu dieser "internationalen Version") gar keine aktuelle Firmware gibt - jedenfalls läuft die entsprechende Abfrage ins Leere.

M.W.n. wurden die Modelle mit der Artikel-Nr. 2000 2657 (6490 international) mit dem Wert "avm" und nicht "avme" bei der Variable firmware_version ausgeliefert. Diesbezüglich ist die im Web-Archiv zu findende Version der von dir (versucht) verlinkten Webseite leider nicht aktuell.

Es gab/gibt zwar (seit der 06.50 afaik) eine Einstellung GUI_FORCE_FIRMWARE_UPDATE in der guiflags.lua, aber diese war bisher in jeder Firmware, die mir für die 6490 unter die Finger kam, auf false gesetzt - vielleicht war diese 06.51 ja die große Ausnahme. Diese Version habe ich leider nicht in meinem Fundus.

Könnte es sich evtl. um die folgende Version handeln?
https://download.avm.de/firmware/64...Cable.en-de-es-it-fr-pl.141.06.51-35031.image

 

[PeterPawn]

Möglich wäre es, aber komisch - mal abgesehen davon, daß auch in dieser Firmware (die kannte ich auch mit ihrem "lgi" und "avm", wie ich nach dem Download feststellen mußte) das GUI_FORCE_FIRMWARE_UPDATE auf false gesetzt ist.

Das würde dann aber zumindest erklären, warum es über JUIS für diese Version keine Updates gibt - denn diese dürfte noch über die alte Schnittstelle danach suchen; jedenfalls fehlt ihr auch die juis_boxinfo.xml.

Wobei mir hier das Datum der Firmware (14.11.2016 - zumindest für den ARM-Core, der hier ja noch "tonangebend" war) nicht zur Seriennummer der Box (November 2015) zu passen scheint ... außer da hätte jemand doch schon zuvor ein Update gemacht. Wenn das nicht @betaman2 selbst war, stellt sich mir halt die Frage, wer das gewesen sein sollte - zumindest bei einer fabrikneuen (wenn auch schon etwas gelagerten) Box. Warum dann im Februar 2018 eine 06.51 auf die Box gekommen sein sollte und nichts Neueres (06.87 wäre da "state of the art" gewesen), wäre die nächste Frage, wenn er es doch selbst war - davor hat er ja keine Updates machen können, wenn er die Box noch nicht hatte.

Meine alten Skripte für die zuvor genutzte Update-Abfrage von AVM finde ich leider nicht mehr (veröffentlicht hatte ich erst mit der Einführung von JUIS) ... daher kann ich auch nicht prüfen (mit vertretbarem Aufwand), ob über diese die 06.51 oder eine neuere Version ebenfalls annonciert wird und die Box damit ein Online-Update machen könnte oder nicht.

 

[fritz.fichtl]

@PeterPawn
Wann der bootloop einsetzte ist inzwischen kein Thema mehr, da ich bei der Box über den LAN2 Anschluss den FTP-Server im Bootloader anhalten konnte und mit hilfe Deiner Eva_Tools das AVM OS auf die Box gespielt habe.
Nach dem Stromanschluss startet die Box jetzt normal durch. Ich kann auf das WebGUI über die LAN2 bis LAN4 Anschlüsse und über WLAN zugreifen. Nur wenn ich das LAN Kabel an den LAN1 Anschluss stecke reagiert das WebGUI auf keine Eingabe mehr.

Ein anhalten des FTP-Servers über ADAM ist nicht möglich, solange das LAN Kabel am LAN1 angeschlossen ist.

Weitergehende Tests habe ich bisher nicht durchgeführt. Ich werde morgen einmal mit iperf testen.

Ich spreche hier im Singular, da meine Aussagen für beide Boxen in gleicher Weise zutreffen.

 

[PeterPawn]

Ich habe immer noch nicht verstanden, ob nun die LAN1-Anschlüsse bereits auf der Ethernet-Ebene (also praktisch schon Layer1) nicht funktionieren oder ob nur das GUI darüber nicht reagiert - was ja auch an einer ungewöhnlichen Switch-Konfiguration liegen könnte, die dann tatsächlich etwas mit den Einstellungen zu tun hat. Sollte das irgendwo stehen, brauche ich wohl noch einen Hinweis, wo das wäre.

Wenn die LAN1-Ports an beiden Boxen hingegen "physisch" tot sind (d.h., es gibt gar keine Ethernet-Verbindung und zwar zu keinem Zeitpunkt), sind sie halt defekt. Dann ist natürlich die Erwartung, es würde irgendwo an einer Konfigurationseinstellung liegen (#8) auch schwer verständlich als Frage "an die Runde".

Ich kann nicht nachvollziehen, warum ein physikalischer Defekt nicht auch auf zwei Boxen gleichzeitig zutreffen sollte und über deren Historie (wo kommen die her, war das derselbe Besitzer, was hat der damit gemacht) wissen wir hier im IPPF ja absolut nichts.

Warum erscheint es Dir so plausibel, daß die Boxen zwar beide gleichzeitig in einem Boot-Loop feststecken (und dessen Ursache spielt - zumindest in meinen Augen - sehr wohl eine Rolle), aber nicht gleichzeitig physikalisch defekt sein sollten?

Da braucht nur jemand mit einer defekten PoE-Installation (bis hin zu falscher Verdrahtung) die PHYs gebraten haben - dann sind die Ports eben hinüber. Wenn Du solche Ursachen ausschließen kannst, weil Du eben doch nähere Infos zur Geschichte der Boxen hast, ist das zwar nett ... aber da uns die hier fehlen, KANN das doch alles nur Spekulation sein.

 

[betaman2]

@All,
ich möchte mich hiermit aufs Entschiedenste von meinem Jahrtausendfehler distanzieren!
Wenn man so in die "Zange" genommen wird, mit Rechnungsdaten und Versionsnummern, dann sollte man schon etwas exakter arbeiten. Also, mea culpa, mea maxima culpa!
Meine Angaben, bis auf den o.g. Lapsus, habe ich nach bestem Wissen und Gewissen (und vorliegender Datenlage) gemacht. Ich weiß, daß das notwendig ist, gerade auch bei den internationalen Versionen. Ich hätte aber nicht mit einer der derart widersprüchlichen Situation in puncto Herstellungs-, Softwarestand- und Verkaufsdatum gerechnet.
Der Kauf damals war etwas übereilt, weil wir mit dem Zulauf eines Umsetzers von DVB-S auf DVB-C gerechnet hatten, und eine schnelle Entscheidung sein mußte.
Im Übrigen bin ich keiner, der der Fritzbox unbedingt unter die Haube schauen muß, maximal ein Frixtender-Umbau findet bei mir statt. Selten Labor-Versionen, niemals Inhouse, kein Linux. Und auch keine kryptischen Befehle an Leute, die man aus dem 1. Buch Mose kennt.
Ich werde mich mal hinsetzen und den Informationsstand (jahrtausendbereinigt) dokumentieren.
Dann die vorgeschlagenen Software-Wiederherstellungen zur Beweissicherung. Es gibt also zu tun.
Dann melde ich mich wieder. Hier bin ich wieder.

1. Die alte Firmware ließ sich nicht installieren, Tricks will ich nicht anwenden.
2. Der Juischeck mit .XML funktionierte nicht, aber mit der ,exe, Bild im Anhang.
3. In der Exportdatei steht unter "webui": version = "35031\\n";
4. Eine Teleportation hat wohl doch nicht stattgefunden.

Jetzt funktioniert die Box mit folgenden Einstellungen:

Internet über Kabelanschluß, ist zwar nicht erfolgreich (nix Kabel), die Power/Cable Lampe blinkt ständig, geht aber seit Stunden.
An LAN1 steckt ein WLAN Range-Extender im Repeater-Modus als WAN-Anschluß,
an LAN2 und -3 stecken meine Notebooks mit Netzwerkkabeln und fest eingestellter IP-Adresse,
LAN4 sollte eigentlich ein Gastzugang sein, er funktioniert aber nicht in diesem Modus, also habe ich den Haken rausgenommen und LAN4 kommt auch ins I-Net.
Ich nehme an, die Fritze kann kein DHCP mehr.
Damit betrachte ich mein LAN1-Problem als erkannt, denn als Switch funktionieren alle LAN-Ports, und DHCP können LAN1 und LAN4 nicht mehr.
Wenn ich den Range-Extender als Router schalte, wäre es fast wie vor dem Defekt.

Vielen Dank für die Unterstützung, ich habe viel dazugelernt!
Vielleicht hilft es auch dem TO.

 

[fesc]

In den erweiterten supportdaten sind ab 7.xx alle switch-counter gelistet (RMON Counter Dump). Da koennte man mal nachschauen ob sich bei port 1 überhaup was tut.

Weiter unten sind die PHY register dumps (PHY MDIO Register Dump), auch da könnte man evtl irgendwelche Fehler aufstpüren, zumindest ob/welcher link erkannt wird (Ausgaben für phy_ar803x_0).

Die supportdaten müsstest Du ziehen wenn ein kabel (in einem separaten Netz) dran ist auf dem Datenverkehr ist.

 

[betaman2]

@fesc,

wenn Du mir bitte noch ein Programm/Editor zur übersichtlichen Darstellung des dumps nennen könntest, versuche ich es mal. Ich habe ja mehrere Fritzen zum Vergleich.
Wie sieht z.B. die Antwort auf ein DHCP-Discover-Paket bei der Fritzbox aus?
Ich glaube aber, das wird mir zu theoretisch....

 

[fesc]

Was die LAN1 Probleme betrifft:

Ich wuerde einfach mal irgendetwas an den lan1 port haengen (laptop, ..), .
Daraufhin ueber http://fritz.box/support.lua die erweiterten supportdaten herunterladen (mit weiterhin angeschlossenem port1). Das ist einfach ein ASCII file, darin sollten dann die entsprechenden Sektionen zu finden sein, einfach nach "RMON Counter Dump" und "phy_ar803x_0" suchen.

Nachdem port1 ja wohl geht wenn die Box im Kabelbetrieb ist kann es sich aber kaum um einen Hardwarefehler handeln. Einen Factory reset hast du probiert?

 

[PeterPawn]

@fesc:
Weißt Du eigentlich genau, ob der Bootloader der 6490 auch bei einem "soft reboot" den Switch komplett initialisiert? Und das auch noch korrekt und nicht nur als einfaches Rücksetzen, weil der halt vom letzten Startversuch noch irgendwie konfiguriert war? Unter Umständen sogar als WAN-Port, getrennt von den anderen?

Ein Versäumnis dabei und ein "Warmstart" durch den Benutzer wäre so ziemlich das Einzige, was mir als Erklärung dafür einfiele, warum ein per se funktionierender eth0-Port am Switch im Bootloader nicht als "LAN" erkannt wird bzw. von der CPU "nicht bedient" wird. Auch so ein Boot-Loop startet ja halt irgendwann mal die Box neu und wenn man darauf wartet, anstatt die Stromversorgung kurz zu unterbrechen, sollte das m.W. bei der 6490 noch funktionieren. Außer AVM hat dann doch noch einen neuen Bootloader erzeugt (und irgendwo installiert), der wie bei den GRX-Boxen nur nach einem "PowerOn-Reset" den FTP-Zugriff erlaubt.

Wenn AVM den Bootloader so ändern sollte, daß dort nur noch die beiden "inneren" Ethernet-Ports verfügbar sind, würde man das sicherlich kommunizieren - wobei so eine Konfiguration eben durchaus Sinn machen würde, denn sie vermeidet generell, daß ein Angreifer über LAN1 (eth0) bei LAN1-Routermodus oder über LAN4 (eth3) bei aktiviertem Gastnetz per LAN-Kabel die Box im Bootloader anhalten kann und dann - dank der standardmäßig aktiven Bridge zwischen den Ports - ungehindert durch die 6490 in das eigentlich abgeschottete Netz kommt.

 

[fesc]

Weißt Du eigentlich genau, ob der Bootloader der 6490 auch bei einem "soft reboot" den Switch komplett initialisiert

Genau weiss ich es nicht, ich würde es gerne mal verifizieren, aber meine 6490 hat wohl das zeitliche gesegnet.

Aber ich bin mir relativ sicher dass bei einem reboot zumindest die VLANs zurückgesetzt werden und der switch als flacher L2 swich auf allen ports fungiert. Denn so habe ich mir einmal eine loop generiert. Ob das allerdings schon in der firmware passiert (ist) oder erst später weiss ich nicht mehr.
Es würde mich auch wundern wenn der switch nicht zurückgesetzt wird, denn das würde bedeuten das schon der bootloader mit getaggten Paketen umgehen können müsste, je nach Konfiguration und Warm- oder Kaltstart.

Und generell ist der switch an sich im LAN1 Betrieb nicht anders konfiguriert (zumindest bei 7.x), ports 1..4 haben getrennte VLANs 1..4, das learning macht die CPU. Bei älteren (ich glaube bis 6.63) war das noch anders (alle in VLAN2, bis auf port 1 wenn in LAN1 betrieb), aber so wie hier beschrieben tritt das ja sowohl bei alten als auch 7.x auf.

Wenn AVM den Bootloader so ändern sollte, daß dort nur noch die beiden "inneren" Ethernet-Ports verfügbar sind ..

Ja, das würde Sinn machen, aber über welche ports man den bootloader erreichen kann muss man von AVM seite denke ich nicht kommunizieren, es ist ja zum Betrieb nicht nötig.

Ich kann mich an ein Problem erinnern bei dem sich die Box sehr seltsam verhalten hat wenn beim startup "viel" Traffic unterwegs war (das war die Sache mit den Performance-Problemen bei frühen 7.0x Boxen). Da hat es (bei mir) geholfen wenn man die Box ohne Netzwerk-Anschlüsse bootet und erst nachträglich alles einsteckt.
Vielleicht wäre das auch mal einen test wert.

Und nochwas: Die IP adresse des bootloaders ist ja nicht zwingend gleich der wie sie später in der GUI vergeben wird. Erstere richtet sich ja nach "my_ipaddress", und die bleibt ja zunächst 192.168.178.1 (oder ist das nur bei mir so weil ich zuviel rumkonfiguriert habe?). Kann es evtl sein dass es bei @betaman2 einen Adresskonflikt gibt? (wobei das auch nicht erklären würde warum es auf lan1 probleme geben sollte).

@fritz.fichtl
Ich bin etwas durcheinander gekommen, ich dachte die Probleme wären identisch. Aber so wie ich das lese geht bei Dir auf port1 "gar nix", während das bei @betaman2 nur im lan1 betrieb so ist.
Insofern wäre es bei Dir schon mal interessant ob sich auf dem lan1 port(s) überhaupt noch was tut (link LED irgendwo? Was zeigt denn die GUI an wenn das was drin steckt?). Und die Werte aus den Support Daten.

 

[betaman2]

@fesc,

ja, ich habe die erweiterten Supportdateien gezogen und kann sie mit "Notepad++" sehr übersichtlich betrachten. Die Abschnitte mit "RMON" und "phy" habe ich extrahiert und könnte sie als *.txt (8kB) oder als *.xls (24kB) anhängen, wenn Du möchtest. Ich selbst kann mangels Vergleichswerte nichts damit anfangen.
Ich denke aber, daß keine Auffälligkeiten in diesen Bereichen sind.
Die ganze Datei ist übrigens 1403kB groß.
"Zurückgesetzt" habe ich die Box mehrmals, sowohl mit "Werkseinstellungen", als auch mit der Telefonnummer #990*15901590*. Sie verhält sich nach dem Telefonreset genau, wie in #29 beschrieben.
Nach den "Werkseinstellungen" will sie Land, neues Passwort, Verbindung zum Provider.
Mit Provider kann ich nicht dienen, die Box "landet" beim Internet über Kabel.
Ich kann mir 1 von 6 Sprachen aussuchen (Deutsch steht an 1. Stelle) und weit mehr als 6 Länder.
Paßwort muß neu vergeben werden.

 

[fesc]

Nur die Ausschnitte schicken, die kompletten Supportdaten beinhalten durchaus private Daten die man nicht einfach an dritte schicken sollte.

 

[PeterPawn]

Thx for answering ...

aber so wie hier beschrieben tritt das ja sowohl bei alten als auch 7.x auf.

Die Beschreibungen sind halt einigermaßen unklar ... ich suche nur nach einer (für mich plausiblen) Erklärung, warum ein Problem wie in #1 auftreten könnte/sollte (und die Frage wurde ja später dahingehend erweitert, wo sich so eine Einstellung noch "verbergen" könnte), solange die Ports nicht komplett defekt sind (was ja auch vom Fragesteller in Zweifel gezogen wurde - deshalb verstehe ich es ja immer noch so, daß die Ports nunmehr in Ordnung wären, auch beim Fragesteller aus #1).

Da ich mal unterstellen würde, daß zum Zeitpunkt der "Boot-Loops" auf den Boxen noch eine Version < 06.8x installiert war (die VLANs für jeden einzelnen Port wurden iirc erst mit dem Umzug auf den ATOM-Core eingeführt), würde ich zumindest zu diesem Zeitpunkt noch davon ausgehen, daß die alte Konfiguration des Switches verwendet wurde.

Ich hatte halt die Hoffnung, daß Du etwas mehr über das "Rücksetzverhalten" des Switches wüßtest ... u.a., ob es unterschiedliche Kommandos mit unterschiedlicher "Tiefe" der Wirkung gibt (und ich wollte mich nicht erneut durch die Quellen graben).

Ich dachte mir eben, es gibt irgendwo ein RST-Signal für den Switch (was sicherlich beim PowerOn auch ausgelöst wird und dann tatsächlich "Grundstellung" befiehlt), aber gleichzeitig auch noch ein paar Verwaltungskommandos, die z.B. dazu dienen, nur Zähler und MAC-Tabellen zu löschen, während die Konfiguration beibehalten wird.

Die GPIO-Belegung der 6490 gibt nur zwei Pins her, die für ein solches (software-gesteuertes) Hardware-Reset in Frage kämen und das wäre einmal "extphy1_reset" und zum anderen "pcie_reset" (nach den spärlichen Infos in den Quellen eher fürs WLAN verwendet).

Daher erscheint es mir durchaus denkbar, daß der Switch vom Bootloader mangels Reset-Möglichkeit nur minimal "konfiguriert" wird und solange der Code dort davon ausgeht, der Switch wäre ansonsten in der Grundstellung, wäre das für mich die einzige halbwegs denkbare Erklärung, warum ein per se funktionsfähiger erster Ethernet-Port im Bootloader nicht von der CPU bedient wird bzw. von dort kommende Daten nicht verarbeitet werden.

Interessant wäre es halt auch noch, ob der Switch selbstständig die MAC-Tabellen löscht, wenn man einfach ein Kabel auf einen anderen Port umsteckt ... ansonsten könnte es ja auch noch sein (z.B. wenn die Meldung "Kabel gezogen" nicht richtig durchdringt, weil ein PHY doch eine Macke hat), daß die Pakete für diese MAC-Adresse schlicht auf dem falschen Port gesendet werden sollen.

 

[fesc]

@PeterPawn :
Eine Komponente die bei einem soft reset nicht mit-geresettet wird ist vorprogrammierter Ärger. Apple hat ja gerade seinen GAU mit sowas erlebt ;-)
Der switch/phy ist zwar ein BGA, aber man könnte es auf der anderen Seite relativ leicht messen (wenn man eine funktionierende Box hätte ..). Es gibt auch noch ein rst_out der CPU der (in einem anderen p6 design) mit diesem gpio verodert ist.

 

[betaman2]

@All,
heureka, ich habe seit ein paar Stunden wieder eine funktionsfähige FritzBox 6490!
Wie ich jetzt dazu komme, weiß ich selbst nicht.
Weil ich mein Elend für die Hilfsbereiten dokumentieren wollte, habe ich die Kiste mehrmals "soft" (Tel.Nr.) und "hard" (Werkseinstellungen) zurückgesetzt.
Zwischendurch immer die Erweiterten Support Dateien betrachtet, in der Hoffnung, Erkenntnisse zu gewinnen. Habe auch verschiedene Einträge gesehen, die mir bemerkenswert vorkamen. Dazu vielleicht später. Vielleicht freue ich mich auch zu früh...
Im Anhang die Auszüge der Supp., bemerkenswert der Unterschied im Juischeck-Bild.
Vielen Dank an @PeterPawn und @fesc !

 

[fesc]

Was auffällt:

Port 3:
Im Fehlertrace kommen auf port 3 keinerlei Pakete an, aber viele werden geschickt und der link ist oben.
Das ist jetzt kein Fehler, aber komisch, denn offensichtlich hat der switch mal etwas auf diesem port "gelernt", denn warum sollte er sonst unicast pakete hinschicken. Was hängt denn an port 3?

Im PHY ist der einizige Unterschied dass der FB-Port clock master ist, im Fehlerfall ist er slave. Wer master/slave ist wird bei der auto-negotiation ausgehandelt und ist mehr oder weniger Zufall. Man bräuchte also mehr snapshots um zu sagen ob das mit dem/einem Problem korreliert.

Port 1:
Der PHY Status sieht komisch aus. Im Fehler-trace steht der link auf
reg[0x11]: 0xbc10 >>> 1000Mbps, Full duplex
im gut-fall auf
reg[0x11]: 0x7c10 >>> 100Mbps, Full duplex

Auch die Unterschiede in anderen registern deuten mMn darauf hin dass ständig (?) der Link neu ausgehandelt wird.
Was hängt denn an port 1? Ist es möglich da mal einen Ethernet switch dazwischen zu schalten um zu sehen ob sich die Lage dann "beruhigt"?

Andererseits, wenn es jetzt geht ist ja alles gut, never change a running system ;-)