Moin Moin,
ich habe nun einen SPP im Zulauf und möchte versuchen die Community in diesem Bereich zu unterstützen.
Ich komme aus dem "Linux ist für Server, Windows für den Desktop und Mac für Leute die es mögen"-Lager und bringe diverse Erfahrungen von anderen Gerätschaften aller Art mit. (Kennt noch jemand die "T-Online Vision" Set Top Box?, Fonera V1.0, und neueres)

Ziel hier im Beitrag ist es den SFP-Anschluss grundlegend benutzbar zu machen und Kompatibilität mit verschiedenen Modulen an einer Stelle zusammen zu fassen.
OB der Anschluss irgendwann für Ftth Nutzbar sein wird sei mal dahingestellt, mir geht es um die Nutzung als Verbindung zum Switch.

Falls jemand bereits Versuche in dieser Richtung gemacht hat und dem SPP Informationen entlocken konnte, immer gerne in die Schwarmintelligenz damit.

Nachdem sich Hermes entschied mir dann doch das Paket zu liefern, kam heute der Speedport Pro an.
Folgende mini-gbics habe ich getestet:

Microsens MS100200D -> Link zum Switch hergestellt -> kompatibel
Pandacon PDA-GLC-SX-MM -> Link zum Switch hergestellt -> kompatibel

Fiberxon FTM-3012C-SLG -> Kein Link, kein leuchten -> inkompatibel


Per Wireshark war dem SPP bisher keine Kommunikation zu entlocken.
Die derzeitige Vermutung ist, das Interface ist zwar "up" aber es ist an Softwareseitig an keine Bridge verbunden.
Ich habe am Switch immer mal ein aktivitäts-Blinken auf dem Port, es kann aber sein das dies vom Switch Richtung SPP ist und daher nicht auf den anderen Ports in Wireshark auftaucht.
Beim Test der Module konnte ich natürlich noch nicht sichergehen das auch der Speedport seinerseits den Link wirklich als hergestellt betrachtet, ich gehe aber davon aus, da die selben Konstellationen auch in anderen Switchen laufen.

Mein Hybrid-Anschluss wird erst in rund 3 Wochen geschaltet, so lange kann ich damit noch ausgiebig spielen.
Grundsätzlich läuft der SPP von der Bedienung her aber im vergleich zum SPH sehr geschmeidig. Abgesehen von ein paar Fehlern in der Oberfläche und diesen unnötigen Feature-Einschränkungen/Gängelungen seitens der Telekom eigentlich ganz brauchbar.

Fortschritt - oder so ähnlich

Um weiter zu kommen habe ich mich auf der Suche in die tiefen des SPP gemacht und diesen erst mal zerlegt.
Wo ich schon dabei war, habe ich den SPI-Flash ausgelesen der sich auf der "Rückseite" beim reset-Knopf befindet.
An sich relativ ernüchternd, nichts was weiterhilft, bei bedarf kann ich die Dumps mal zur Verfügung stellen.
Es gibt einen 2. SPI-Flash der sich auf der "Vorderseite" in dem Schirm befindet. Aufgrund der Enge komme ich hier ohne einschneiden oder ablöten des Schirmes nicht zum auslesen ran, dürfte auch erst mal keine relevanten Infos zu meinem Thema enthalten. Wenn jemand hier Bedarf hat kann ich aber auch diesen mal auslesen.

Die Serielle Konsole mit Bootloader (UEFI-shell!!!) Zugriff befindet sich an 2 Testpunkten bei 2 Widerständen und 2 Kondensatoren "ums eck" der Onboard DECT2 / ZB (ZigBee?) Antenne auf der Karte mit dem PCIe Slot.
Mittig zwischen der Lötseite vom PCIe Port und dem Stromanschluss.
Der Obere ist SPP-TX und der untere ist SPP-RX
Man kann die Bootsequenz einfach per ESC abbrechen und dann in der EFI-Shell rumwuseln.
Wenn der Speedport normal gebooted wird werden typischerweise keine Eingaben mehr angenommen und somit nichts weiter möglich.

Die komplette Bootlog habe ich angehangen.


Einstecken von SFP-Modulen und herstellen von Links hat leider keinerlei Konsolenoutput gebracht.
Auf jeden Fall ist der Weg nun geebnet weitere Analysen durchzuführen.
P.s. bei mir fehlte schon beim Zerlegen auf der Platine der Rückseite die Schraube unten links. Hat das auch jemand von euch festgestellt?

Ich ergänze die Tage noch mal Bilder.


-- Edit --
WTF, korrigiert mich aber es ist eine x86 Intel Atom CPU in dem Speedport Pro. Leider findet man weder bei Google noch auf der Intel Seite relevantes zu Intel Atom CPU CE2734...

Hier sind Bilder aller 4 Seiten
Die Pins für die Serielle Konsole sind markiert -> .

Hier sitzt (einer) der Flash-Speicher, diesen habe ich ausgelesen. Zudem fehlte bei mir hier eine Schraube ->

Es lässt sich übrigens eine USB-Tastatur verwenden und der Kernel reagiert beim normalen Boot auf Sysrq Keys.
Im UEFI lässt sich die Tastatur auch benutzen.
Leider habe ich heute morgen als ich vom RX-Testpunkt abgerutscht bin und an die in der nähe liegenden Induktivität gekommen bin, meinen TX-Kanal vom USB Wandler frittiert, daher kam ich in Sachen Boot-Sequenz noch nicht weiter.
Morgen sollte ein neuer Wandler da sein.
Während des "Early-Boots" bis zum Wechsel auf Init sind die USB-Geräte noch nicht verfügbar weil der Treiber wohl erst im Anschluss geladen wird, daher lässt sich ohne TX-Kanal nur mit USB-Tastatur zwar per Boot-Parameter eine Shell ausführen, allerdings keine eingaben durchführen.
Sobald ich wieder einen funktionierenden Wandler habe, denke ich, lassen sich dort Eingaben machen.

Ich konnte zudem noch beobachten, wenn man "länger" in UEFI verbleibt, also ein paar viele Sekunden bis wenige Minuten, dann schlägt der normale Boot Vorgang fehl. Es scheint als booted parallel ein anderer Chip (vermutlich ein DSP, für den dürfte auch der 2. Flash-Speicher unter der Metallabdeckung hier sein ->
Wenn das ganze also zu weit auseinander läuft dann schlägt der Synchronisationscheck fehl und es stürzt ab.


// Edit: Ich habe den Trick mit dem unterbrechen des Boot Prozesses schon gelesen, da es hier "anders" aufgebaut ist wird es wohl nicht so einfach funktionieren.
Ist aber wohl auch gar nicht nötig, da man sich einfach per UEFI mittels Boot-Parametern eine Shell verschaffen kann. Sobald ich wieder eine Serielle Konsole habe kann ich dies verifizieren. Sollte es entgegen den Erwartungen nicht klappen, dann könnte man das aber noch mal versuchen.

Zum Thema UEFI konnte ich zudem noch 2 Dinge feststellen,
a) USB-Tastatur geht, USB-Stick geht nicht. Wodran dies liegt weis ich nicht. Es könnte sein das die SD-Karte funktioniert, habe ich aber noch nicht getestet.
b) Netzwerk innerhalb von UEFI geht nicht. Ich konnte in einem Forum einen Hinweis dazu finden, welcher entweder heißt das jemand bewusst UEFI dazu bringt das Netzwerk nicht geht oder es eine Version ist in der es eine Umstellung gab und daher für ein paar Versionen Netzwerkunterstützung auf UEFI-Ebene fehlschlägt.

Also hängt es bei weiteren versuchen auf UEFI-Ebenen derzeit an dem alten Henne-Ei Problem, ich benötige wohl Treiber/Tools um auf Sticks und Netzwerk zu kommen, wofür ich wiederum einen Weg brauche auf entweder nen Stick oder Netzwerk zuzugreifen um dieses laden zu können...

Als Ausblick lässt sich zumindest aufgrund der fortschrittlichen Komponenten erahnen was für ein riesen Potential die Kiste hat. Sollten sich keine Spezialtreiber-Probleme ergeben und evtl. ein paar Kernel-Hacker zur Unterstützung finden sollte sich das System komplett modifizieren und funktional halten lassen.
Eventuell gibt es auch im allgemeinen HAAP-Tunnel Bonding Bereich entsprechende Durchbrüche und anhand der Daten lässt sich das Bonding auf eine reguläre Linux Box auslagern oder zumindest sämtlicher störender Kram modifizieren und abschalten.

// Update: USB-Stick geht doch. Ein USB3.0 Stick wird nicht erkannt, ein USB2.0 Stick schon.
Der Fehler beim Netzwerk ist:

Am Grund angekommen - root

Dank des neuen USB2TTL Wandlers konnte ich weiter den init-Vorgang "bearbeiten".
Es gibt so viele relevante Infos, ich weis gar nicht wo ich anfangen soll.
Als System läuft ein schwer modifiziertes openwrt auf dem besagten Intel CE2734.
Es gibt eine "start-cfg.xml" und andere files mit sämtlichen Zugangsdaten und Konfigurationseinstellungen, HAAP, Bonding, LTE, DSL-Autoconfig.

Ich arbeite gerade an einem persistenten Root-Zugang.
Dabei müssen 3 dinge getan werden:
/etc/passwd um login-Daten ergänzt werden
dropbear gestartet werden
die firewall angepasst werden um port 22 zu erlauben.

Grundsätzlich ist das overlay-filesystem aber eh direkt veränderbar.

Im Endeffekt ist mit dem wühlen nach dem SFP-Port auch meine ursprüngliche Suche am Ziel. In der start-cfg.xml lässt sich sehen das der SFP-Port für einen FTTH-Mode voreingestellt wird und somit zum WAN gehört.

Ich konnte noch keine groben Lücken finden mit denen sich über das web-interface Befehle ausführen lassen, also dürfte der derzeitige Weg zum modifizieren nicht um die serielle Konsole rum kommen.
Man kann zwar theoretisch den gesamten Vorgang auch "Headless" über eine Usb-Tastatur machen, aber dann müsste man rund 1000 Zeichen blind fehlerfrei eintippen (Eben den abgebrochenen Init-Prozess fortführen mit nem pre-init schritt, dann wechsel aufs normale init und hier alle normalen init schritte händisch ausführen...).

Jo, mit binwalk habe ich mir das Firmware-File während meiner Versuche angeschaut um zu schauen wo ich 'live' noch interessantes finde bzw. es besser Copy-Pasten zu können und da schon über einige obskure Dinge gestolpert.
Ich frage mich ja ob es mit der OpenWRT community/Lizenz vereinbart wurde bzw. überhaupt fähig ist, das Programmteile davon so genutzt werden.
Man hat über /dev/ttyUSB3 auf ne CDC Schnittstelle Zugriff, allerdings bekomme ich bei meiner (generischen, nicht-hybrid) Telekom Sim immer zurückgegeben das die Pin falsch ist. Ich habe das vielfach versucht, es gibt auch nie einen Sim-Lock.

Kann ich per AT-Kommando irgendwie prüfen ob er die Sim Überhaupt erkannt hat (Die Funktion der SIM+Pin habe ich nach meinen Versuchen am SPP in einem Smartphone verifiziert, da ging die Pin beim 1. Versuch)?

Ich habe hier einen µC in ner Box, der macht im Prinzip genau so etwas mit den automatischen Eingaben. Der wurde in ner Firma verwendet die darüber Automatische Logins als Anmeldetaster durchgeführt hat (an irgendwelchen Fertigungsmaschinen)
Habe dafür irgendwann mal das Programm optimiert/angepasst als es von win xp zu 7 und zu 10 ging.
Im Prinzip könnte es aber auch mit nem Zwitter gehen, also Eingabe+USB-Stick,
auf den USB-Stick Abzug vom im Early-Boot verwendetem System (mit Anpassung das im nächsten Boot-Schritt auf dem MTD eben z.B. der vorhandene Dropbear oder telnetd startet, die firewall angepasst, und das root-Kennwort geändert wird) also quasi ein 'Chainloading'.

Bei den Überlegungen wäre es aber genau so gut möglich, einen usb2serial Adapter in den Speedport zu stecken, an diesem mittels Nullmodem Adapter auf nen serial2usb Adapter an den PC zu gehen und in UEFI einfach als Console-Kernelparameter den Usbport zu übergeben. Dann wären die 'blinden' eingaben auf so etwas wie 10 Sek lang während Poweron "Esc" hämmern, fs1:\ncd boot\ncd efi\nbootkernel -c console=ttyUSB4,115200n8 loglevel=8 rootwait root=/dev/mtdblock0 mtdparts=RAM0:0x%08x@0x00000000(RootFileSystem-RAM) ro phram.phram=RAM0,0x%08x,0x%08x BoardID=0xE5 BoardRev=0x10 vmalloc=382M cma=78M oder so ähnlich eingeben und fertig.
Wie gesagt, falls sich jemand mit UEFI auskennt, evtl. lässt sich ja die Ausgabe von UEFI-selbst ja einfach auf nen USB-Terminal ausgeben.
Am besten (leider aber auch gut von TCom fixbar), wäre natürlich eine Lücke im Webserver die ein Ausführen von Code ermöglicht.
Da dies ja oftmals blind erfolgen muss wären die Informationen mit welchen schritten man dropbear/telnet aktiviert und nutzbar bekommt dafür natürlich schon sehr von Bedeutung, falls ich es nicht schon mal irgendwo geschrieben habe poste ich die erforderlichen 4 Befehle dafür mal die Tage.

In der Tat habe ich genau das getan. Aber ohne Ergebnis. Wird erkannt etc.. aber ohne Zugriff und die Möglichkeit das zu confen geht's halt auf /dev/ttyS0
Man kann halt zusätzliche Ports so benutzen oder auch die Lan-Schnittstelle vom Dock etc.. insofern der Treiber im Kernel ist.
Ich habe mir inzwischen mal ein Busybox compiliert mit mehr Funktionen, mit ner Festplatte an der Kiste kann man schon einiges rumspielen.
Leider gibt's keinen Kernel Support für NFS o.ä.
Am Kernel dürfte sich auch nicht viel machen lassen wenn man keine eigenen UEFI-Signaturen in den Bootloader erlaubt bekommt.
Da kenne ich mich wie gesagt zu wenig aus um zu wissen womit oder wie ich ihn dahingehend beeinflussen kann.
Die ganze Entwicklungsseite ist bei Intel ja leider teilnehmenden Firmen vorbehalten. Daher gibt's keine Doku und keinen Code um auch nur im Ansatz nen eigenes Linux lauffähig zu bekommen mit mehr Kernel-Features als das was er da mitbringt.
"Intel Puma 7 " ist das Stichwort, siehe intel.de/content/www/de/de/con…-kit-7-product-brief.html
Vielleicht bin ich auch einfach nur zu Blöd da gerade mehr Infos von Intel zu erhalten.

Am 11. sollte mein Hybrid ja "live" gehen, leider hat der Techniker wohl den falschen Port geschaltet, entsprechend habe ich noch nicht mal mehr DSL seit dem Wechsel zur Telekom. Morgen Vormittag kommt der Techniker und solls beheben. Es bleibt spannend, dann kann ich den Speedport Pro mit meinem SSH-Zugang mal in Betrieb sehen
Vielleicht sollte ich (obwohl es ein Kauf Gerät ist) die Kiste erst mal wieder ins Gehäuse packen.
Die serielle Schnittstelle brauche ich ja erst mal nicht bis ein tiefgreifendes update kommt. Denke aber selbst da könnte man sich was verankern das er nach nem update ssh wieder startet (ggf. sogar mit soviel separaten Files wie möglich, nicht das die Telekom einfach mal dropbear und telnetd löschen, wie bei anderen Geräten...)

Nach Update 120133.2.5.035.0, Stand 05/2020 ist wohl erst mal kein Dropbear mehr installiert.
Da aus unbekanntem Grund meine Serielle Konsole vom Speedport gerade keine Daten mehr Überträgt muss ich erst mal einen neuen Weg suchen, um Zugang zu erhalten.
Mein Cronjob wird wohl noch ausgeführt, zumindest läuft telnet, wofür aber keine Zugangsdaten funktionieren.

telekom.de/hilfe/geraete-zubeh…ro/firmware-speedport-pro