FB 6591 verschiedenes

Vermutlich scheitert das schon daran die Spezifikation zu finden, die ist nämlich offensichtlich nicht frei Verfügbar. Da wäre Reverse Engineering wohl der erfolgsversprechendere Ansatz.

Das "die Specs" abweichen ist so ja erstmal nicht schlimm, das Problem ist eher das die Zertifikate nicht für 3.1 gedacht sind. Da kommt es dann auf die Gegenstelle an ob die Wert darauf legt das alles ordentlich abläuft oder ob die sagt "Zertifikat ist Zertifikat, egal ob es eigentlich dafür gedacht ist oder nicht".
 
  • Like
Reaktionen: depadre
Gut spätestens dann bin ich raus, da fehlt mir einfach die Erfahrung und das Wissen. Vielleicht ließen sich ja sogar die Zertifikate der Vodafone Station aka Aris dafür misbrauchen, aber ich weiß, da bewege ich mich auf dünnem Eis. Danke für die Hinweise.

Besteht die Chance, die 6591 mit Retailfirmware hinter die Vodafone Station im Bridge Mode zu nutzen oder läuft der Verbindungsaufbau im Bridge Mode auch über den Router, der sich um das NAT kümmert?
 
Vielleicht ließen sich ja sogar die Zertifikate der Vodafone Station aka Aris dafür misbrauchen, aber ich weiß, da bewege ich mich auf dünnem Eis.
Dann hast du das Problem gleich doppelt (einmal raus und einmal wieder rein), mal ganz davon abgesehen das Arris SecureBoot nutzt (und somit nur signierte Firmware läuft) und der Speicher im TG3442 als BGA ausgeführt ist (falls du doch irgendwie SecureBoot umgehen können solltest ist das interessant), viel Spaß beim löten ;) Die Serielle Schnittstelle ist dort selbstverständlich an die SecureBoot Fuses gekoppelt, die ist dementsprechend dann deaktiviert.

Tatsächlich sind die Hürden noch etwas höher, aber ich denke da braucht man nicht weiter drauf einzugehen.

Besteht die Chance, die 6591 mit Retailfirmware hinter die Vodafone Station im Bridge Mode zu nutzen oder läuft der Verbindungsaufbau im Bridge Mode auch über den Router, der sich um das NAT kümmert?
Da kommen wir der Sache schon näher. Das würde funktionieren, ob man damit die volle Geschwindigkeit erreicht muss man ausprobieren. Theoretisch möglich wäre es.
 
Da sind meine Kompetenzen sehr beschränkt, wie ich feststelle. Ich müsste das UEFI Secure-Boot aushebeln und dann via Lötverbindung den Chip bespielen..

Da kommen wir der Sache schon näher. Das würde funktionieren, ob man damit die volle Geschwindigkeit erreicht muss man ausprobieren. Theoretisch möglich wäre es.

Leider bekomme ich lediglich folgende Fehlermeldung:
Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)

Habe mit der alten 6490 getestet, die als Zertifikatsspender angedacht war, dort funktioniert der Bridge-Mode nach Umstellung mit dem Aris-Modem.

Hast du eine Idee? Habe ich den Bridge-Mode falsch verstanden?
 
Neustart des Modems nach dem abziehen der 6490 gemacht? Funktioniert IPv4 wenigstens?
 
  • Like
Reaktionen: depadre
PUUUUH ich hab das ganze Thread einmal durchgelesen und meine FB 6591 Cable UC erfolgreich auf 7.13 gebracht.
Artikelnummer 2000 2858 - BIOS CGM2.86C.597968.R.1809251311 09/25/2018
Ich habe meine FB über Kleinanzeigen erworben gehabt und musste nach der Registrierung bei Unitymedia feststellen, dass sie sich nicht updaten lässt und ich steckte in der Version 7.03 fest.
Jetzt war die Box über mich bei Unitymedia schon registriert - JA! Und ich konnte meine Internetgeschwindigkeit in der Übersicht der FB sehen - JA! Jedoch konnte ich nicht im Internet surfen. Alle Seiten ergaben einen timeout.
Nach dem Update mittels Patch auf 7.03 7.13 - BOOM alles funktioniert!
JEDOCH haben ich meine Telefon-Zugangsdaten erst vorgestern bekommen und bis heute habe ich diese nicht zum laufen bekommen.
Bei der Einrichtung unter "Eigene Rufnummern" gibt es im Drop-Down-Menu "Telefonie-Anbieter" keinen Eintrag für Vodafone oder Unitymedia :confused:
Ich habe nur die Möglichkeit meine Rufnummer über "Andere Anbieter" zu registrieren, doch bis heute kein Erfolg :(
Jetzt weiß ich natürlich nicht, ob die Registrierung wegen MIR oder wegen Unitymedia oder wegen dem Flash nicht funktioniert.
Hier sind meine Einstellungen:

unity-tel.jpg

Sollte ich noch einmal flashen? Andere Version ausprobieren??

Bild geschrumpft gemäß Boardregeln by stoney
 
Zuletzt bearbeitet von einem Moderator:
Warum solltest du noch einmal flashen? Du steckst doch eh in der Version 7.03 fest, sagtest du.

Leider vertippt. Ich habe die Anleitung hier auf Seite zwei benutzt und meine Box von 7.03 auf 7.13 geupdated!


JETZT bin ich auf der Suche nach einem Client Programm für IP-Telefonie, um meine Telefon-Zugansdaten damit zu testen. Bin auf PhonerLite gestoßen und spiele gerade mit den ganzen Einstellungen herum. Bis Dato leider ohne Erfolg? Gibt es alternativ-Programme?
 
Zuletzt bearbeitet:
Das macht ja irgendwo so gar keinen Sinn
Ohne Secure-boot und fehlerfreier Firmware ist es wohl eher lückenbehaftet, aber als klon-"hindernis" hat es sich ja schon mal bewährt. Reiner Zugriff auf das Filesystem reicht nicht mehr.
Denn nun mass man schon eigenen Code ausführen können um an die Daten zu kommen bzw. (noch schwerer bis unmöglich ohne Hestellerschlüssel) einer Box fremde Daten unterzujubeln.
Und wenn man ein eigenes CMTS hat: was nützt einem das Auslesen wenn man es nicht wieder woanders aufspielen kann.
 
aber als klon-"hindernis" hat es sich ja schon mal bewährt.
Dafür würde es halt auch ausreichen, wenn man nur den privaten Schlüssel (die meisten können halt nur nicht zwischen "Zertifikat" und "privatem Schlüssel" unterscheiden und auch diejenigen, die das können, verwenden es oft genug synonym, um sich weitere Erklärungen zu sparen) entsprechend sichert - ohne den kann man zwar das Zertifikat auslesen/klonen, aber da das CMTS seine eigenen Antworten ja dann mit dem - in diesem Zertifikat enthaltenen - öffentlichen Schlüssel "unkenntlich" macht, kann man dessen Antworten ohne den passenden privaten Schlüssel nicht lesen.

Aber wenn man das anders implementiert hat ... auch gut. Ist das nicht einfach nur ein TPM, was da im Chipset implementiert ist und was den Key für die Verschlüsselung dieses "trusted store"-Formats dann liefert bzw. die Daten auch gleich ver- bzw. entschlüsselt, damit der Key das TPM nicht verläßt?

Dann wäre eine "komplette Verschlüsselung" halt merkwürdig/unnötig für den gesamten "store" (wie auch immer der aussieht), weil dann schon jeder Zugriff auf das Zertifikat ja eine TPM-Operation erfordert - es sei denn, man speichert das dann doch wieder nach dem (einmaligen) Entschlüsseln irgendwo im RAM (für die Laufzeit des Systems) als entschlüsselte Daten.

Das würde natürlich den Sinn und Zweck der Verschlüsselung wieder konterkarieren ... ob ich das aus dem Filesystem oder aus "/dev/(k)mem" auslese, macht keinen echten Unterschied (wenn der Zugriff auf das Device möglich ist). Sicher ist das Ganze nur dann, wenn ich die tatsächlich schützenswerten Daten (hier eben den PrivKey) nur dann entschlüsseln lasse, wenn ich sie gerade akut benötige und sie ansonsten auch nicht im RAM speichere oder nur mit einer zusätzlichen Sicherung (eben auch wieder verschlüsselt, ggf. mit einem "runtime key") und sogar den Speicherplatz für einen entschlüsselten PrivKey wieder explizit lösche (damit das auf dem Stack/Heap oder in irgendeinem Page-File nicht doch noch zum "leak" kommt).

Auch bei DOCSIS 3.1 ist ja der private Schlüssel des CM nur zum Dekodieren der Antwort mit dem "Authorization Key" (im Rahmen von BPI+) erforderlich (iirc) ... alles danach arbeitet mit "derived keys" und da wird dann eigentlich gar kein Zugriff auf den privaten Key mehr benötigt. Ob/wie zusätzliche Zugriffe auf das CM-Zertifikat erforderlich sind (nach der "authorization phase"), weiß ich gerade nicht ... möglicherweise gibt es das tatsächlich auch nicht und dann wäre das "jeder Zugriff" halt auch kein echter Nachteil (da schwächelt die Argumentation gg. die Verschlüsselung des Zertifikats dann etwas).

Gerade bei der Nutzung eines solchen TPM gäbe es ja aber eigentlich keinen (plausiblen) Grund, die Implementierung irgendwie "geheimzuhalten" (da sorgt ja dann das TPM für die Sicherheit der Daten) ... ich habe mich bisher für den Puma7 nicht wirklich interessiert, aber findet man nicht da auch die Patches von Intel irgendwo im Internet?

Denn das ist ja wohl immer noch ein Linux-Kernel und auch wenn AVM wohl mal wieder eigene Wege beschreitet, werden andere Hersteller ja vermutlich deutlich näher an den Intel-Quellen arbeiten. Wobei das ganze NvramDB-Zeug ja ohnehin Userland ist und vermutlich auch beim Puma7 weiterhin verwendet wird (reine Vermutung, ich habe noch nicht mal das AVM-OpenSource-Paket bei mir entpackt) ... das fällt dann halt nicht mehr unter die GPL.

Aber auch für ein ggf. vorhandenes TPM benötigt man ja Treiber und selbst wenn die als LKM ausgeführt sind, müßte es irgendwo im Kernel doch ein paar "Verbindungen" dahin geben, so daß ich nicht glaube, daß das wirklich alles ohne Patches für den Vanilla-Kernel auskommt.
 
Das hast du alles richtig erkannt nur hast du eine Annahme getroffen (die auch stimmt) aber die bei der Entwicklung scheinbar nicht getroffen wurde: Du gehst davon aus, das SecureBoot deaktiviert oder lückenhaft ist. Wenn es das nicht wäre, dann wäre das ganze wieder egal.

Tatsächlich ist es noch schlimmer als den Key nur im RAM zu speichern, das wird deutlich wenn man schaut wo er ist und wo er gebraucht wird und welchen Weg er dafür nehmen könnte. Auch da wird von einer sicheren Plattform ausgegangen die nicht kompromittiert wird.

NvramDB gibt es weiterhin.

Den Source Code für das TG3442 hatte ich vor einiger Zeit mal angefordert und auch bekommen, den findet man deshalb jetzt auch im Internet (sogar in der fast aktuellsten Version).
 
Ich kann jetzt über PhonerLite und meinen Zugansdaten telefonieren.
Allerdings NUR wenn ich meinen SIP credential
von ssl104v6.telefon.unitymedia.de
auf ssl104v4.telefon.unitymedia.de ändere

Jetzt kommt der Knüller:
Nach einem Neustart meiner Fritzbox funktioniert Telefonie einwandfrei?!?!?!
Musste ich meine Telefonie erst anstoßen mittels PhonerLite??
Sehr strange... Ich fasse jetzt nichts mehr an. ES LÄUFT! \(◦'⌣'◦)/
 
hast du die konsole schon per lan kabel aktiviert ?
die Konsole geht auch ohne diesen Widerstand

Hallo @saggirus ,

da meine Atomconsole auch keinen Mucks mehr von sich gibt die kurze Frage, was genau Du mit "per lan Kabel aktiviert" meinst? Meinst Du damit den Befehl "quote SETENV kernel_args mute=0" in der EVA-Konsole?
Falls nein, wäre das dann nämlich ggf. interessant für mich! Falls ja, schade ;-)


Hintergrund: Ich kam nach dem erstmaligen Anlöten von Pins schon an diese Konsole dran und konnte meine Box (älteres BIOS) damit glücklicherweise flashen. Allerdings total instabil (wahrscheinlich durch Wackelkontakt). Das wollte ich dann korrigieren. Nach meinem 2.Versuch geht aber leider nix mehr und ich bin mir eigentlich auch sicher, dass ich die Anschlüsse in der Platine durch mein laienhaftes Lötvermögen zerschossen habe (Heute würde ich gar nicht mehr löten! Bei meinen Versuchen mit der ARM-Console habe ich festgestellt, dass man wunderbar temporär arbeiten kann, wenn man diese Anschluss-PINs (3 noch am Stück) einfach nur "geschickt" in die Löcher einsteckt, so dass sie Kontakt haben). Die 3 Löcher (TX/RX/GND) an meiner ATOM-Konsole sehen durch meine Lötarbeiten mittlerweile jedenfalls aus, als hätte eine Bombe eingeschlagen ;-) Aufgrund Deiner obigen Antwort habe ich aber wieder die Hoffnung bekommen, dass ich die Konsolenausgabe durch einen mir noch unbekannten Befehl doch noch irgendwie zum Leben erwecken könnte. Über die ARM-Console (die funktioniert einwandfrei) scheint ja nicht alles möglich zu sein - insbesondere dann, wenn ich mir die Box bei meinen ganzen Versuchen irgendwann in der Zukunft doch einmal zerschießen sollte - was ich natürlich nicht hoffe.
(ssh auf der Box läuft aktuell wunderbar, falls es darüber eine Analysemöglichkeit oder ähnliches für die Konsole gäbe)
 
Wenn du die Leiterbahn vom Lötpunkt abgerissen hast oder einen Widerstand "demontiert" hast dann muss man das natürlich wieder reparieren wenn es funktionieren soll. Den Widerstand kann man notfalls überbrücken und mit der Bahn nimmt man einen Glasfaserstift zum entfernen des Lötstoplacks und lötet dann einen Draht auf die Bahn und an den Pin. Das hat dort ja noch alles ganz humane Maße, das lässt sich auch noch mit nem 3mm Lötkolben noch löten. Zumindest habe ich schon halb so große Dinge mit einem 3mm Lötkolben gelötet weil das Wechseln der Lötspitze zu lange gedauert hat ;) Das kann man aber ja immer noch machen wenn es so weit gekommen ist das du den Anschluss wirklich brauchst.
 
  • Like
Reaktionen: teufel2k und jha4711
Hallo, ich wollte kurz mitteilen, das die Anleitung hier auch mit der aktuellen Labor Version 07.19-79491 funktioniert.

Kann mir bitte nochmal jemand den Zugriff per SSH erklären? Ich komme nur bis zur Abfrage der Zugangsdaten. Adam2, Root, mein Benutzername für das Webinterface funktionieren nicht.
Ich kann für Updates natürlich immer wieder die Serielle ATOM Konsole verwenden, aber schöner wäre ein SSH Zugang. Vielleicht hat hier jemand einen Tipp?
 
[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht]

... Funktion mit aktueller LaboFW kann ich bestätigen - Link-Update ist bereits als Pull request ins Repo eingereicht.

@Botschafter
Die von dir genannten Zugangsdaten gelten nur für FTP.
SSH Zugangsdaten für den "root" User legst du selbst fest.
Ist in der Anleitung von @fesc (https://bitbucket.org/fesc2000/ffritz/src/6591/) in der Readme unter "First Use" beschrieben.
Schau mal, ob Du damit weiter kommst.
 
Zuletzt bearbeitet von einem Moderator:
...aber schöner wäre ein SSH Zugang. Vielleicht hat hier jemand einen Tipp?

Eine Möglichkeit besteht im Zugang über die sogenannte "ssh public key authentication"

Dafür brauchst Du ein "passendes" Schlüsselpaar bestehend aus einem "private key" und einem "public key".
Wenn Du das das erste mal machst, musst Du Dir die Schlüssel generieren (Suchbegriff: ssh-keygen -t rsa).

Der private key bleibt auf Deinem PC, der public key kommt in die Datei ~/.ssh/authorized_keys auf die Box.
Danach brauchst Du für "ssh [email protected]" kein Passwort mehr (ggf. jedoch das Passwort zum Entsperren Deines lokalen private keys).

Deine Herausforderung ist jetzt, den public key auf die Box zu bringen. Hierfür gibt es bei den gepatchten Boxen einen Telnetdaemon, der bis ca. 10 Min. nach dem Booten aktiv ist. Über den kannst Du dann den public key auf die Box bringen. Die Methode hat abhängig von den Systemen ggf. strenge Sicherheitsanforderungen. So muss auf manchen Systemen das .ssh Verzeichnis und diese Keys (i.d.R ~/.ssh/id_rsa bzw. ~/.ssh/authorized_keys) nur für den Besitzer lesbar sein. Bei Problemen also ggf. auch diese Berechtigungen auf Deinem PC/Linux/mac prüfen.

In der Anleitung von @fesc findest Du unter Punkt 5....

Nach dem reboot sollte fuer einige Zeit ein telnet daemon laufen. Einloggen, ssh login credentials vergeben (passwd oder pubkey nach /.ssh/authorized_keys), sichern (nvsync), fertig.
Der telnet service wird nach ein paar Minuten terminiert.

Viel Erfolg
 
Zuletzt bearbeitet:
Danke, das hilft mir schon etwas weiter.
Die Keys zu erzeugen war auch kein Problem. Aber wo auf der Box finde ich die erwähnte ~/.ssh/authorized_keys Datei?
Login per Telnet bis zu 10 Minuten nach dem neustart würde funktionieren, aber mein Passwort wird doch zurückgewiesen. Das ist ja mein grundlegendes Problem :).
Darüber hinaus komme ich nicht.
Oder verstehe ich etwas grundlegend falsch? Finde ich die ~/.ssh/authorized_keys Datei vielleicht in dem zu flashenden Firmware Image? Falls ja wo?
 
Die Datei muss ja erst noch angelegt werden, deswegen ist sie noch nicht vorhanden.
 
Verstehe. Aber wo muss ich Sie ablegen? In der Firmware vor dem Flashen oder auf der Box per FTP oder NAS?
Einfach im Hauptordner?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.