[Problem] 7490: LAN Ports kaputt?

[bolzomane]

Hi,

meine Fritzbox 7490 hat scheinbar ihren Geist (halb) aufgegeben: WLAN und Power/DSL blinkt nur noch.
Netzwerkports stellen keine Verbindung mehr her (Netzwerkkabel wurde entfernt).

Wollte mich aber nicht so schnell geschlagen geben, habe festgestellt das auf LAN3 die Netzwerkkabel Meldung nicht erscheint.
Eine IP Adresse wird jedoch auch nicht bezogen, WI nicht erreichbar. Also statische IP rein, mit dem ruKernelTool das o2 Branding entfernt, recoveryimage aufgespielt (6.60):
Leider gleiches Ergebnis. Das 6.50 lässt sich nicht flashen, alle weiteren Ports weiterhin tot.
Wieder mit ruKernelTool auf "europäisch" gestellt, Firmware 6.30 geflasht und siehe da, WLAN hört auf zu blinken. Auf dem Tablet eingerichtet, WI erreichbar!
DSL deaktiviert und auch das blinken der Power LED ist verschwunden.
Aber immer noch nichts machbar auf dem LAN Ports. Diagnose im WI ohne nennenswerte Erkenntnisse. Laut Energiemonitor/Diagnose/Startscreen alle LAN Ports unbelegt. Alle befinden sich außerdem im "Green" mode, ein ändern ist nicht möglich (keine Radiobuttons da).

Gibt es noch hoffnung das ein Softwareproblem vorliegt oder ist das die Hardware kaputt? Aufgeschraubt hab ich die Kiste noch nicht.
Weiterhin kann ich Recovery Images über LAN3 einspielen, trotz des Meldung das nichts angesteckt wäre.
Per WLAN kann ich ebenfalls Images aufspielen, auch Freetz wäre möglich (habe ich auf 3 anderen Boxen laufen selbst kompiliert). Ich weiß jedoch nicht ob freetz da überhaupt weiterhelfen kann..

Ich bin für jede Idee / Vorschlag dankbar und zu jeder Schandtat bereit!

ruKernelTool Info:

Box-Informationen:
    ProductID:                 Fritz_Box_HW185
    HWRevision:                185
    HWSubRevision:             5
    SerialNumber:              0000000000000000
    annex:                     B
    autoload:                  yes
    bootloaderVersion:         1.1964
    bootserport:               tty0
    country:                   99
    cpufrequency:              500000000
    firmware_info:             113.06.30
    firmware_version:          avme
    firstfreeaddress:          0x81116240
    flashsize:                 nor_size=0MB sflash_size=1024KB nand_size=512MB
    language:                  de
    linux_fs_start:            0
    maca:                      C8:0E:14:C7:4F:4D
    macb:                      C8:0E:14:C7:4F:4E
    macdsl:                    C8:0E:14:C7:4F:51
    macwlan:                   C8:0E:14:C7:4F:4F
    macwlan2:                  C8:0E:14:C7:4F:50
    memsize:                   0x10000000
    modetty0:                  38400,n,8,1,hw
    modetty1:                  38400,n,8,1,hw
    mtd0:                      0x400000,0x3400000
    mtd1:                      0x0,0x400000
    mtd2:                      0x0,0x40000
    mtd3:                      0x40000,0xA0000
    mtd4:                      0xA0000,0x100000
    mtd5:                      0x0,0x200000
    my_ipaddress:              192.168.178.1
    req_fullrate_freq:         250000000
    prompt:                    Eva_AVM
    sysfrequency:              250000000
    tr069_passphrase:          VEfSzpqKxkrj
    tr069_serial:              00040E-C80E14C74F4D
    urlader-version:           2964
    usb_board_mac:             C8:0E:14:C7:4F:52
    usb_device_id:             0x0000
    usb_device_name:           USB DSL Device
    usb_manufacturer_name:     AVM
    usb_revision_id:           0x0000
    usb_rndis_mac:             C8:0E:14:C7:4F:53
    wlan_key:                  37119204766984737734

  Flash-/Speichergrößen:
    Memsize:   268.435.456 Bytes (262.144 kB, 256 MB, 0,3 GB)
    mtd0:       50.331.648 Bytes (49.152 kB, 48 MB)
    mtd1:        4.194.304 Bytes (4.096 kB, 4 MB)
    mtd2:          262.144 Bytes (256 kB, 0,3 MB)
    mtd3:          393.216 Bytes (384 kB, 0,4 MB)
    mtd4:          393.216 Bytes (384 kB, 0,4 MB)
    mtd5:        2.097.152 Bytes (2.048 kB, 2 MB)

  ProductID:   Fritz_Box_HW185
  HW-Revision: 185  => FRITZ!Box 7490

 

[woprr]

In Originalzustand versetzen und auf Garantie zurück.

 

[thtomate12]

Lieber woprr,
vielen Dank für deinen hilfreichen Beitrag.

 

[bolzomane]

Da ich keine Rechnung mehr habe fällt der Umtausch aus. Daher auch eben die Frage hier im Forum ob ich selbst da noch etwas retten kann..

 

[PeterPawn]

Auch über WLAN müßten sich ja die Support-Daten einer gestarteten Box auslesen lassen. Wenn es wirklich Hardware-Probleme mit dem eingebauten Switch (an dem aber auch das WLAN und die CPU hängen) oder einem PHY für einen Ethernet-Port geben sollte (2 PHYs (LAN1/LAN2) sitzen im Chipsatz, die anderen sind extra Bauteile), dann steht das dort in der dmesg-Ausgabe, wenn die bis zum Start des Gerätes zurückreicht (also die Daten zeitnah zu einem Neustart auslesen).

Es kann sicherlich auch ein Hardware-Schaden vorliegen ... in aller Regel ist das aber ein Problem mit dem verwendeten Ethernet-Kabel oder dem "auto sensing" bei Ethernet, wo sich beide Teilnehmer an der Kommunikation über ein solches Ethernet-Kabel dann nicht über den verwendeten Übertragungsmodus einigen können. Das kann wg. Bauteiltoleranzen sogar so weit gehen, daß eben der eine Port funktioniert und der daneben dann wieder nicht - wenn das alles etwas "wacklig" ist. Bei korrekter elektrischer Verbindung und passenden Einstellungen klappt es aber meist problemlos.

Hier sollte man also (die FRITZ!Box nehmen wir mal als Fixpunkt an) zunächst mal andere Kabel, dann passende Einstellungen am verwendeten Gerät (an der FB ist da nichts einzustellen) und zum Abschluß dann ein anderes Gerät verwenden.

Wobei die berichteten fehlenden Einstellungen für GbE vs. FE bei den LAN-Anschlüssen im GUI der Box auch auf ein Problem bei der Initialisierung (und dann eben wirklich einen Hardware-Schaden) hinweisen könnten.

In jedem Falle würde ich die Box ohne eingestecktes LAN-Kabel starten, damit nicht ein Kurzschluß im Kabel am Ende für diese Probleme verantwortlich ist.

Auch eine Sichtprobe (mit der Lupe) der Kontaktzungen in den Ethernet-Buchsen ist sicherlich möglich und in diesem Zusammenhang dann auch die Prüfung auf mechanische Defekte. Diese Kontaktzungen sollten federn, wenn man sie mit einem Zahnstocher (die äußerste Spitze wegschneiden, daß man eine Fläche erhält, die auf den Kontakt drücken kann) vorsichtig(!) herunterdrückt und sie sollten auch frei von sichtbarer Korrosion sein, ansonsten hilft ein Glasfaser-Pinsel.

Mit ein wenig Pech kann schon eine verbogene Kontaktzunge die internen PHYs beide auf einen Schlag lahmlegen und wenn man dann noch denselben defekten RJ45-Stecker in LAN4 (der muß da doch irgendwie reingehen) gepresst hat, ist (reine Vermutung, weil ich so etwas auch schon gesehen habe) am Ende nur noch ein einzelner Port auch wirklich zu initialisieren.

 

[bolzomane]

Danke für die vielen Tipps, ich hab verschiedene Kabel und Netzwerkkarten probiert, an sämtlichen Ports.
Die Ethernet Buchsen aber ich gesichtet, jede Zunge einzeln getestet. Von Korrosion keine Spur..
Ich habe Gehäuse geöffnet, rein Optisch sieht das alles gut aus, vor allem die Kondensatoren habe ich genau betrachtet und bei der Gelegenheit auch minimalst Staub entfernt.
Leider alles ohne Erfolg.

UPDATE

Das vermutlich relevante aus der dmesg:

atmpvc_init() failed with -17
[avmnet][setup_phy] PHY phy_ar803x_1 hanging, trying to resetit. (10x Wiedeholt)
[avmnet][setup_phy] Giving up on hanging PHY phy_ar803x_1.
[avmnet]Module mac_7port_1: setup() failed on child phy_ar803x_1
[avmnet]Module swi_vr9: setup() failed on child mac_7port_1
[avmnet][avmnet_cfg_netinit] network module setup returned with error

 

[HabNeFritzbox]

http://fritz.box/?lp=support

 

[AlfonsS]

Muß nicht, kann aber sein!
Netzteil defekt!
Ähnliche Symptome gibt es, wenn das Netzteil schwächelt.
Die Ausgangsspannung kann zwar 12V sein, unter Last evtl. zusammenbrechen.
Wie verhält sich zum Beispiel der Port, wenn man WLan abschaltet usw. wegen
dem Stromverbrauch usw.
Ein normales Steckernetzteil mit 12 V 2 - 3 A sollte zum testen genügen.

 

[bolzomane]

Ich habe noch eine FB 7390 ich werde mal das Netzteil tauschen.

Hab außerdem gestern mal testhaber ein freetz auf basis 6.30 mit replace kernel gebaut und über WLAN eingespielt. Das läuft auch anstandslos, habe die Hoffnung mit cpmac da vielleicht noch was retten zu können. Ein funktionierender LAN port würde mir völlig reichen..

 

[PeterPawn]

Ich habe noch eine FB 7390 ich werde mal das Netzteil tauschen.

Gute Idee ... das ist dann mal schon per se zu schwach.

Vorher würde ich einen Blick in die Handbücher werfen (da steht der max. Strombedarf) und dann ein Netzteil verwenden, was den auch liefern kann ... wobei ich hier nicht wirklich glaube, daß es etwas bringt. Wie allerdings die Box derart etwas abbekommen konnte, ist mir ein Rätsel - aber sei's drum.

Irgendwo habe ich mal die Port-Verteilung am 7-Port-Switch für die 7490 aufgeschrieben (ich hoffe, daß es die 7490 war und nicht die 7362SL).

Wenn da in den Nachrichten nur ein einziger PHY als defekt auftaucht und der Rest einfach deshalb nicht geht, weil die Initialisierung der anderen dann gar nicht mehr versucht wird (aus dem Gedächtnis ist mir so, als wäre das eine Schleife, die bei Fehler abgebrochen wird), dann könnte man sicherlich durch einen eigenen Kernel (bis 06.30 sollte das auch gehen, ab Kernel-Version 3.10.73 nach meiner Meinung ja wg. unvollständiger Quellen nicht mehr) noch etwas retten, indem man für den Port 1 (das muß nicht LAN1 sein, siehe Quellen) einfach den Eintrag in der Netzwerk-(Hardware-)Beschreibung herausnimmt.

Wobei man das auch vorher wohl noch einmal testen kann ... im Bootloader sollte, wenn man die Box im EVA-FTP-Server "festhält" (wie das am einfachsten geht, habe ich auch bei vielen Gelegenheiten beschrieben, daher hier keine weitere unnütze Beschreibung meinerseits), dann auf weiteren Ports auch ein Link möglich sein, wenn tatsächlich nur ein einzelner PHY defekt ist.

 

[bolzomane]

Das andere Netzteil hat keine Unterschied gemacht.

Mit ruKernelTool habe ich die Box im EVA FTP gehalten und andere Netzwerkgeräte an den anderen Ports probiert. Ohne Erfolg.
Was mir ja wirklich ein Rätsel ist da eben der LAN3 funktioniert und ich sogar Firmwares flashen kann. Aber eben "normal" nicht nutzen kann.

Bleibt wohl nur noch der Versuch die LAN Ports per replacements Kernel zu deaktivieren.
Ich würde gerne sämtliche LAN Ports deaktivieren und dann einen nach dem anderen einschalten..
Patchen programmieren und kompilieren ist für mich kein Problem aber ich habe keine Ahnung wo ich danach suchen muss in den Kernel sourcen.
Man müsste ja wahrscheinlich erstmal das Modul aus dem Kernel entfernen..

UPDATE:
Habe make kernel-menuconfig gefunden. Ohne den Atheros F2 Phy device driver läßt sich der Kernel leider nicht bauen. Als modul läßt es sich ebenfalls nicht bauen..

 

[PeterPawn]

Die Konfiguration ist in der Datei "drivers/net/avm_cpmac/configs/config_HW185.h" beschrieben - wobei ich gerade keine 06.30-Quellen zur Hand und in der 06.60 nachgesehen habe. Ggf. stimmen also Zeilennummern nicht, dann mußt Du selbst die 06.60 mit der 06.30 vergleichen.

In "drivers/net/avm_cpmac/switch/ifx/7port/mac_7port.c" findest Du dann Deine Fehlermeldung in Zeile 302, dort ist außen herum auch die von mir schon erwähnte Schleife über das "children"-Array, die bei einem Fehler verlassen wird und damit wohl wirklich dafür sorgt, daß die nachfolgenden Einträge (port2 => eth1 und port4 => eth0) nicht mehr initialisiert werden.

Du mußt also mindestens den Port 1 auf dem Switch (das ist der, über den eth3 (aka LAN4) läuft) aus diesem Array entfernen - das ist in Zeile 190 der oben erwähnten Konfiguration.

Noch einmal ... die Zeilennummern beziehen sich auf eine andere FRITZ!OS-Version, die Projektion auf die 06.30 mußt Du selbst hinbekommen.

- - - Aktualisiert - - -

Über "Module aus dem Kernel entfernen" solltest Du besser nicht wirklich nachdenken ... lies Dich lieber in aller Ruhe ein, ich vermute mal, dann ändert sich "Dein Plan" noch etwas.

 

[bolzomane]

Danke für die Hilfe, hab alles gefunden.
Könnte ich nicht einfach das return auskommentieren und somit einen fehler "dulden". Hätte vielleicht den Charme das alle defekten defekt bleiben aber funktionierende verbleiben?!

Ich baue es jetzt erstmal wie von dir beschrieben.

Noch eine Frage: Nachdem ich den Kernel mit make kernel-precompiled gebaut habe, einfach make - dann wird der kernel im Image übernommen?

 

[PeterPawn]

Wenn die restlichen beiden wieder funktionieren, ändert ja auch das auskommentierte "return" nichts ... wenn aber noch andere Referenzen existieren und hinterher anderer Code über das Array läuft, der eine erfolgreiche Initialisierung zuvor erwartet, hast Du den nächsten Fehler.

Da das "eth3" ist, könnte es ohnehin noch Probleme in der Folge geben, wenn anderer Code (z.B. der im kdsld/ctlmgr, der für das Gastnetz verantwortlich zeichnet) dann ein "eth3"-Interface irgendwo erwartet. Aber das kann man dann Schritt für Schritt erkunden ...

 

[bolzomane]

Das Gastnetz habe ich vorsorglich deaktiviert. An der Meldung hat sich nichts geändert. Wie kann ich denn sicher gehen das der neue Kernel im Image ist?
. Muss ich ein make clean machen damit er im image landet? Kann natürlich ins syslog schreiben..

 

[PeterPawn]

grep -i "hw185.*7port" /proc/kallsyms

sollte dann keinen "port_1" enthalten.

- - - Aktualisiert - - -

Wobei ... das muß gar nicht stimmen, wenn das Symbol trotzdem an anderer Stelle eingelinkt wird oder ungenutzte nicht entfernt werden.

 

[woprr]

Schraub mal auf und check auf gebrochene Lötstelle bei den LAN Buchsen.

 

[bolzomane]

grep -i "hw185.*7port" /proc/kallsyms

Probiere ich heute Abend

Schraub mal auf und check auf gebrochene Lötstelle bei den LAN Buchsen.

Hab ich schon einmal gemacht, ich kann aber gerne mal ein Foto der Lötstellen machen, vielleicht erkenne ich das einfach nicht.

Habe nochmal eine Frage zum Procedere bezüglich Kernel ob der gebaute so wirklich Teil des images wird:
1) make clean
2) make kernel-clean
3) codeänderungen an den kernel sourcen
4) make kernel-precompiled
5) make menuconfig
6) make

 

[PeterPawn]

Die Änderungen nicht von Hand ausführen, sondern als Patch-File im richtigen "make"-Unterverzeichnis ablegen, z.B. in https://github.com/PeterPawn/freetz/tree/master/make/linux/patches/2.6.32.61/7490_06.30 - als Basis natürlich den ausgecheckten Trunk verwenden, ich habe nur meinen Freetz-Fork verlinkt, damit man das nachsehen kann.

Änderungen direkt an den Quellen können mit etwas Pech auch wieder überschrieben werden, wenn im Rahmen des Build die originalen Quellen neu ausgepackt werden ... ob das beim Kernel auch so ist (bei den Paketen ist es definitiv so), weiß ich nicht genau, teste ich jetzt auch nicht.

Also:

1) "normalen" Build ausführen
2) richtiges Source-Verzeichnis suchen (irgendwo in source/kernel-bla)
3) originales File vor der Änderung sichern
4) Änderung ausführen
5) Patch-File mit "diff" erzeugen und am richtigen Ort (s.o.) ablegen
6) make kernel-clean
7) make
8) Getränk besorgen
9) Image testen

Das wäre mein Vorschlag ... es kann sein, daß es beim Kernel unnötig ist, weil da vielleicht nicht automatisch neu ausgepackt wird (reine Annahme, weil ab und an ein "kernel-clean" notwendig ist - ich suche die Abhängigkeiten der Make-Targets jetzt nicht raus, das ist mir zu unübersichtlich).

Vielleicht schreibt ja auch @er13 noch etwas, ob die Abhängigkeiten dort auch das Arbeiten mit Patch-Files "erzwingen" - wenn ich Änderungen an Paketen im Fork erstelle oder für die Veröffentlichung aus anderen Toolchains in Freetz übernehme und teste, dann wie oben beschrieben; halt ohne "kernel-clean" und bis zur Abklärung korrekter Syntax (bzw. weil ich selten ein Image als Ergebnis will) mittels "make <package>-precompiled", was hier unnötig sein müßte, weil man beim Entfernen von Code (hoffentlich) keine Syntax-Fehler fabrizieren sollte.

 

[bolzomane]

Ich habe gestern entsprechende Patches erstellt und platziert, bisher noch mit keinen Positiven Ergebnissen, ich lande entweder im Bootloop und somit ohne Chance zu wissen was los ist oder es ist keine Änderung feststellbar.
Ich werde wohl noch ein bisschen "Try and Error" betreiben müssen.