[Frage] 6490 Serial port?

Cubexed schrieb:

According to ftp.avm.de/fritz.box/fritzbox_6490_cable/firmware/deutsch/info.txt the latest one is 6.30, mine is 6.22

Zum Vergrößern anklicken....

Nevertheless there's no publicly available newer firmware (yet) ... currently new versions are spread to the devices only by the cable network providers. I'm not even sure, that the 6490 may be updated like any other devices - there's a point in the DOCSIS 3.0 spec, which reads like "the firmware has to be updated via the CVC mech, if you'd like to get a certification for your device" ... and the 6490 got this certification (it was the first one from AVM, earlier products (63x0) weren't certified afaik).

I cannot understand, when the reboot(s) occur which you're mentioning ... and the usage of "/dev/watchdog" to monitor the boot process duration is exactly the same as in every DSL device from AVM - only the time limits differ slightly from 120 to 240 seconds.

@kyle0r:
The 6490 shouldn't accept pseudo update files anymore/anytime - I'd like to state, it should be impossible to load files from the first 06.xx version up to the latest one ... what is the latest important security enhancement for DSL devices (denying unsigned images and downgrades), should be "best practice" for the DOCSIS devices a long time ago.

And if you'd like to enable the update functions with modifications to the "update pages" of the GUI, it's a "chicken or the egg" question ... without any access to the shell you cannot modify the GUI and/or change the firmware image. If you got this access, there no further need to use "pseudo images" anymore.

PeterPawn schrieb:

@kyle0r:
The 6490 shouldn't accept pseudo update files anymore/anytime - I'd like to state, it should be impossible to load files from the first 06.xx version up to the latest one ... what is the latest important security enhancement for DSL devices (denying unsigned images and downgrades), should be "best practice" for the DOCSIS devices a long time ago.

And if you'd like to enable the update functions with modifications to the "update pages" of the GUI, it's a "chicken or the egg" question ... without any access to the shell you cannot modify the GUI and/or change the firmware image. If you got this access, there no further need to use "pseudo images" anymore.

Zum Vergrößern anklicken....

I think that is a debate still worth having.

I wanted to be able to test a simple TCP socket connection to an external IP, unfortunately there is no diagnostic feature for that in the web interface.

So I went digging for a way of doing it via shell...

Relatively speaking I'm brand new to the 6490, its fresh "out of the box" as you know its came with 4 blank "reserve" partitions and has a recent OS, 6.24.

In [thread=284175]thread 284175[/thread] I tried the following without success:

1. using the dial code trick with DECT and also with direct patched phone
2. changing to avm brand to see if helped, after reading it changes other web menus
3. manual config editing

None of that worked. However through all the wonderful sharing of knowledge online I was able to execute commands on the 6490 (Pseudo update) to start telnet ...

Let me digress from the original topic for a moment.

After that life was better, I could progress the case with my direct socket connection problem and also increase my knowledge and understanding about the little box that brings me to the Internet . It has been a welcome little project and head holiday, while I'm off work sick for a few weeks.

The experience for me has been remarkable, through the short journey I've learned a lot about AVM/Fritz, practiced and improved my nixcraft etc. I've really be positively shocked by the amount of info and goodwill in people sharing online, especially on IPPF!

I'm very thankful and enlightened. My message in #19 was sincere.

Lastly, I'm responsible for running a number of hardware infrastructures which have near 100% uptime SLA's, and learning about my little Fritz!Box has actually given me some welcomed new ideas for concepts/architecture for the future. Including ways of potentially avoiding state loss when a hypervisor is lost in a bigger cluster of hv's...

Remember ... that is just one guys view on the Internet

check: https://www.xkcd.com/386/

P.S. PeterPawn, please send me a DM/PN with a good contact channel and I will send you something which is perhaps to your interest.

@kyle0r:
ippf (at) yourfritz (dot) de

but mails regarding 6490 and DOCSIS may be filtered (even if they are "false positives") ... I've got too much questions around this theme during the last 14 month and many people asked "secret questions" (and I've no idea, why they thought, my "private answer" would be another one than that in this forum) - mostly they wanted to know, how to the 6490 could be rooted.

I'm excited about what your "gift" could be ... if it's a link to infos, how to use "pseudo updates" with DOCSIS devices, I'm not really interested. I knew about that vulnerability too, but I thought, it has already been fixed a long time ago.

ich würd gern mal zum eigendlichen zurückkommen, auch wen das was hier im thread vorhanden ist auf anderen baustellen sehr aufschlussreich ist...

also back to the roots. serielle...
auf keiner der 3 möglichen bekomm ich irgendwas. mach ich was falsch? zumindest eva sollte reden wollen ... danach kann der output unterbunden werden... wenn nein, heist das für mich: open wire... aber: wo...
ich poste die tage mal bilder. vlt findet ja wer der besser sehen kann wo da was fehlt damit rx und tx auch da rauskommen, wo die anschlüsse eingelötet werden sollen ....

Ich tendiere inzwischen zu der Annahme, daß da noch ein Steuerregister im Puma6 beteiligt ist, wie man in "arch/arm/mach-avalanche/puma6/puma6_bootcfg_ctrl.c" sehen kann und daß dort die entsprechenden Bits (6, 7, 8) nicht gesetzt sind.

Die Symbole werden exportiert, damit stehen


auch anderen zur Verfügung. Wenn das kein "memory-mapped I/O" ist (man also nicht einfach z.B. mit dem "devmem"-Applet der Busybox den Wert dort ändern kann), dann müßte man sich halt ein kleines LKM schreiben (oder den Kernel gleich komplett austauschen), was die betreffenden Bits mal testweise anknipst oder auch erst einmal den Status dort ausliest - solange hier niemand aufschlägt, der die Puma6-Dokumentation im Schreibtisch hat, muß man eben erst einmal testen.

Die Funktionen klingen zwar vom Namen her erst einmal komisch, aber mir fehlt ansonsten jede Idee, was sich hinter UART0 bis UART2 ansonsten verbergen könnte und auch das zugehörige Header-File (arch/arm/mach-avalanche/include/arch-avalanche/puma6/puma6_bootcfg_ctrl.h) liest sich m.E. so, als würde eine funktionierende Ausgabe für die UART-Schnittstellen dort die entsprechend gesetzten Bits erfordern.

Ich habe an einer 6490 an den mittleren UART Anschluss ein passendes Kabel angelötet und siehe da, mit der 06.83 bekomme ich alle Ausgaben, die auf die Konsole gehen (dmesg, Userspace)!
Offensichtlich hat AVM den x86 Kernel ohne SERIAL_8250_CONSOLE_MUTE kompiliert.

Nur vom Bootloader bekomme ich nichts (auf diesem Port).

Gibt auch direkt eine root Shell auf der Konsole.

Habe mir noch ein 2. Kabel bestellt, mal sehen was auf dem UART vom ARM passiert.

@f666:
Hast Du eigentlich an dieser Stelle noch weitergemacht?

Ich war gerade dabei, ein paar Boxen mit FTDI232RL-Platinen auszustatten:

(7412/7490/7580 sind fertig, eine 6490 hatte ich gerade als letzte in der Mangel), damit ich auch der originalen AVM-Firmware auf die Finger sehen kann und dazu nicht erst irgendwelche zusätzlichen Dienste in die Firmware implementieren muß - so bleibt die Firmware dann tatsächlich absolut unverändert bei Tests und beim Dokumentieren.

Jetzt hatte ich für die 6490 genau noch zwei Pegelwandler übrig (hatte einen Fünfer-Pack geordert) und würde die Pfostenleisten für deren Anschluß auch gerne nur da einlöten, wo es tatsächlich etwas bringt. Welcher Anschluß ist jetzt wofür - das ist die wohl immer noch nicht abschließend geklärte Frage oder ich habe etwas übersehen in anderen Threads.

Wenn ich #27 richtig verstehe, hast Du auch den zwischen dem Tuner und dem Kühlkörper bestückt und da die Ausgaben des ATOM-Cores erhalten - das ist bei mir genauso (nachdem ich endlich eine NA-Firmware installiert hatte, was vorher nicht der Fall war und mich fast irre gemacht hat, weil bis zur 06.63 natürlich noch nichts aus der Seriellen rauskam und ich immer das Löten, den Wandler oder die Verkabelung im Verdacht hatte).

Aber was ist mit Bootloader und ggf. dem ARM-Core - hat Dir das zweite Kabel irgendwie weitergeholfen? Daß der ARM-Core ggf. eine eigene serielle Schnittstelle hat, ist ja noch nachvollziehbar - aber der Bootloader muß ja nun auf irgendeinem der beiden Systeme ausgeführt werden und damit ist der dritte wohl eher WLAN oder Xilinx.

Ich habe bei den anderen Boxen Pfostenleisten eingelötet (außer 7412, wo das nicht geht, weil der Heat-Spreader über den Löchern sitzt) und mit Patch-Wires die FTDI232RL angeschlossen und dabei die Mini-B-Buchsen auf der Wandler-Platine so an passenden Stellen eingesetzt (gerne sind ja auch die WLAN-Antennen im Weg, wenn es um die "Außenkanten" der Gehäuse geht - bei der 6490 habe ich das Loch zwischen den beiden TAE-Buchsen untergebracht), daß die von außen mit dem richtigen Kabel bei Bedarf genutzt werden können. Damit habe ich keine "fliegenden Kabel" an den Teilen und nur sehr unauffällige Durchbrüche im Gehäuse, solange kein Kabel angeschlossen ist.

Bei den anderen Modellen bin ich wie gesagt fertig ... bei der 6490 stellt sich mir die Frage, ob es sich lohnt, die noch einmal aufzuschrauben und den letzten Wandler für den ARM-Core einzusetzen, weil der mit passender Änderung am Kernel (bzw. es sollte ja auch ein nachgeladenes LKM ausreichen, wenn es an die Funktionen kommt) auch noch "geschwätzig" wird. Wenn Du da noch etwas gefunden (oder auch nur "negativ" getestet) hast, würden mich diese Funde interessieren - ansonsten reicht mir auch die "armconsole", um auf dem Core etwas nachsehen zu können.

f666 schrieb:

Ich habe im Thread zur seriellen Konsole letztes Jahr von meinen Erfahrungen etwas berichtet.
Mindestens seit 06.83 werden beide Kernel ohne SERIAL_8250_CONSOLE_MUTE kompiliert und die Konsolen funktionieren. /etc/inittab startet auch Loginshells.

Vom Bootloader bekomme ich allerdings überhaupt keine Ausgaben.

Zum Vergrößern anklicken....

Das ist immer noch der letzte Stand. Eventuell kann man den Bootloader zum Reden bringen, wenn man im richtigen Moment irgendwas zur Box sendet. Das habe ich aber noch nicht probiert und meine Entwicklungsbox hat Anfang des Monats den Geist aufgegeben.

Der dritte serielle Anschluss liefert nach dem Einschalten ein paar Meldungen (mit anderer Baud Rate wie die anderen beiden Konsolen), ich habe das auch noch nicht weiter analysiert. Wird wohl nicht das SoC sein, vielleicht der WLAN Chip.

Gibst Du mir noch einen Tipp, welcher Anschluß zum ARM-Core gehört? Das spart mir das Einlöten einer Pfostenleiste am falschen. Den ATOM-Core habe ich ja schon bestückt ...

PS: Der Link führt ja genau auf diesen Thread ... einen anderen, in dem die Anschlüsse zugeordnet wurden, finde ich auch nicht.

Rein von der Logik her würde ich den anderen Anschluß unterhalb des Kühlkörpers vermuten ... aber man weiß ja nie so genau.

EDIT: Ok, ich bin meinem Bauch gefolgt ... für weitere Leser: Der ARM-UART ist der Anschluß zwischen Kühlkörper und PCB-Kante, nicht der zwischen Kühlkörper und den TAE-Buchsen.

EDIT2: Jetzt habe ich auch das Zitat in #29 verstanden ... der Link steht halt hinter dem Pfeil.

Ich habe in zwei Terminals jeweils ein screen laufen:

screen /dev/ttyUSB0 115200
screen /dev/ttyUSB1 115200

Dann die Box ans Netzteil anschließen. Sobald der Bootloader die Kernel startet, bekomme ich die Ausgaben und am Ende des Startprozesses die Root Shells.

Die 3. Pinleiste hatte ich nur temporär angeschlossen, die Baudrate weiß ich nicht mehr.

f666 schrieb:

Ich habe in zwei Terminals jeweils ein screen laufen:

screen /dev/ttyUSB0 115200
screen /dev/ttyUSB1 115200

Zum Vergrößern anklicken....

könntest Du Bitte einen Screenshot posten, auf dem man die Platine und das "Zusatz-Soldering" sehen kann.

f666 schrieb:

Dann die Box ans Netzteil anschließen. Sobald der Bootloader die Kernel startet, bekomme ich die Ausgaben und am Ende des Startprozesses die Root Shells.

Zum Vergrößern anklicken....

Wäre es auch hier möglich den Consolen-Output zu posten, ggf. Anonymisieren (MACs, ...);

Links ATOM, rechts ARM

Da meine Box kaputt gegangen ist, habe ich die Kabel schon nicht mehr dran:



Die Ausgaben auf den Konsolen habe ich leider nicht gespeichert, da ist aber wenig spezielles drin. Was vom Kernel kommt, lässt sich auch über dmesg ansehen, plus die Meldungen von Userspace.

Hier die Ausgaben auf dem 3. seriellen Anschluss:

Zur Info:

Mit der FritzOS Version 7.00 hat AVM auf der 6590 die serielle Konsole wieder ausgeknipst:

Na dann wird das sicherlich zur Nagelprobe für die Gültigkeit der veröffentlichten Quellen, wenn man sich wieder (praktisch gezwungenermaßen) seinen eigenen Kernel bauen muß. Allerdings muß das (bei identischer Konfiguration zur AVM-Firmware und der einzigen Änderung, daß dieses "mute" wieder abgeschaltet wird) tatsächlich nur einer tun ... der Kernel steht deutlich unter GPLv2 und darf frei verbreitet werden, auch in binärer Form.

Wobei man der Vollständigkeit halber (und damit man bei nicht funktionierendem, selbstgebauten Kernel nicht in die argumentative Defensive gerät, weil er mit den Quellen für das falsche Modell 6590 gebaut wurde) wohl auch die Quellen für die 6490 noch mal "anfragen" sollte ... machst Du das gleich noch mit oder soll ich das machen?

Bereits getan, siehe https://www.ip-phone-forum.de/threads/neue-opensource-pakete-für-06-92.298384/page-2#post-2299138

thx for engagement