Hallo zusammen,
ich betreibe auf einer FRITZ!Box 7530 OpenWrt 25.12.6 mit Kernel 6.12.112
(IPQ4019, ARMv7). Für die Telefonie muss ich derzeit eine zweite FRITZ!Box
daneben betreiben. Das Festnetztelefon wird bei uns heutzutage nur selten
gebraucht, aber ganz ohne Telefonanschluss geht es auch nicht.
Ich hatte die vielleicht etwas verrückte Idee, die Telefonie-/DECT-Module aus
dem letzten FRITZ!OS-08.25-Image (Vendor-Kernel 4.4.271, ARMv7) per Reverse
Engineering zu analysieren und auf Kernel 6.12.112 zu portieren. Eine erste
Einschätzung – auch mithilfe einer KI – war: sehr schwierig, aber prinzipiell
nicht unmöglich. Bevor ich aber Monate investiere, möchte ich hier ehrlich
fragen: Lohnt sich das überhaupt, oder ist das ein Fass ohne Boden?
Was ich bisher gemacht habe:
Ich habe die folgenden Module aus dem Image isoliert und statisch analysiert:
Piglet_noemif.ko DECT-UART, Reset, Firmware-Loader
pcmlink.ko PCM/TDM, QCA-TDM/DMA, Audio-Slots
avm_dect.ko DECT-Stack, PCM-Mailbox, UOTA/Audio
dect_io.ko /dev/dect_io, Userspace-ABI
isdn_fbox_fon5.ko CAPI, FON/ISDN, Rufsteuerung
capi_codec.ko Codec-/DSP-Schicht
nlaudio.ko optionales Netlink-Audio
ulpcmlink.ko optionaler Remote-PCM-Transport
krtp.ko optionale RTP-Beschleunigung
Dazu kommen die Userspace-Daemons dect_manager, telefon und voipd, die im
Rootfs als uClibc-ARM-Binaries liegen.
Die wichtigsten Blocker sind aus meiner Sicht:
- Die AVM-Module sind fest für Kernel 4.4.271 gebaut; nur vermagic ändern
reicht natürlich nicht.
- Sie verwenden AVM-/QCA-spezifische Kernel-APIs, die OpenWrt 6.12 nicht
kennt: tdm_if_*, dakota_gpio_*, msm_dectuart_*, avm_get_hw_config_table,
AVM-FIQ-Helfer und weitere.
- Die DECT-Firmware wird über UART/GPIO geladen (Piglet).
- Der Audio-/PCM-Pfad hängt an QCA-TDM/DMA und den PCM-Slots von pcmlink.
- Die Userspace-Seite ist uClibc, OpenWrt verwendet musl.
Ich habe keine Ahnung, ob der DECT-Chip ohne die AVM-FIQ-/TDM-Infrastruktur
überhaupt sinnvoll ansprechbar ist. Deshalb möchte ich nicht behaupten, dass
ein Port leicht wäre – im Gegenteil.
Meine bisherigen Ergebnisse, ABI-Header, Protokollnotizen und lokale Mocks
liegen hier:
github.com
Im Repository sind bewusst keine AVM-Binaries, Firmware-Images oder
extrahierten Vendor-Skripte enthalten – nur Dokumentation, Header, Tools und
Mock-Tests. Die Extraktion aus dem Original-Image ist dort beschrieben.
Meine Fragen an die Runde:
1. Hat jemand so einen Port einer AVM-Telefonie-/DECT-Stacks schon einmal
versucht oder davon gehört?
2. Sind die AVM-APIs (tdm_if_*, dakota_gpio_*, msm_dectuart_*), der QCA-TDM-
Teil oder das DECT-UART-Protokoll irgendwo dokumentiert?
3. Gibt es einen realistischen Teilport – z. B. nur DECT oder nur
die FON-Seite – oder muss immer der komplette Audio-/TDM-Pfad mit?
4. Hat jemand Erfahrung mit AVM-Kernelmodulen, QCA-TDM/DMA oder DECT-
Firmware-Loading und hätte Lust, Teilbereiche zu übernehmen?
5. Oder ist die pragmatische Antwort: zweite FRITZ!Box behalten und die Zeit
lieber in etwas Sinnvolleres investieren?
Ich freue mich über jede ehrliche Einschätzung – auch wenn sie „lass es“
lautet. Mir geht es zuerst darum, den Aufwand realistisch einzuschätzen,
bevor ich weiter Zeit in die Analyse stecke.
Danke und viele Grüße
ich betreibe auf einer FRITZ!Box 7530 OpenWrt 25.12.6 mit Kernel 6.12.112
(IPQ4019, ARMv7). Für die Telefonie muss ich derzeit eine zweite FRITZ!Box
daneben betreiben. Das Festnetztelefon wird bei uns heutzutage nur selten
gebraucht, aber ganz ohne Telefonanschluss geht es auch nicht.
Ich hatte die vielleicht etwas verrückte Idee, die Telefonie-/DECT-Module aus
dem letzten FRITZ!OS-08.25-Image (Vendor-Kernel 4.4.271, ARMv7) per Reverse
Engineering zu analysieren und auf Kernel 6.12.112 zu portieren. Eine erste
Einschätzung – auch mithilfe einer KI – war: sehr schwierig, aber prinzipiell
nicht unmöglich. Bevor ich aber Monate investiere, möchte ich hier ehrlich
fragen: Lohnt sich das überhaupt, oder ist das ein Fass ohne Boden?
Was ich bisher gemacht habe:
Ich habe die folgenden Module aus dem Image isoliert und statisch analysiert:
Piglet_noemif.ko DECT-UART, Reset, Firmware-Loader
pcmlink.ko PCM/TDM, QCA-TDM/DMA, Audio-Slots
avm_dect.ko DECT-Stack, PCM-Mailbox, UOTA/Audio
dect_io.ko /dev/dect_io, Userspace-ABI
isdn_fbox_fon5.ko CAPI, FON/ISDN, Rufsteuerung
capi_codec.ko Codec-/DSP-Schicht
nlaudio.ko optionales Netlink-Audio
ulpcmlink.ko optionaler Remote-PCM-Transport
krtp.ko optionale RTP-Beschleunigung
Dazu kommen die Userspace-Daemons dect_manager, telefon und voipd, die im
Rootfs als uClibc-ARM-Binaries liegen.
Die wichtigsten Blocker sind aus meiner Sicht:
- Die AVM-Module sind fest für Kernel 4.4.271 gebaut; nur vermagic ändern
reicht natürlich nicht.
- Sie verwenden AVM-/QCA-spezifische Kernel-APIs, die OpenWrt 6.12 nicht
kennt: tdm_if_*, dakota_gpio_*, msm_dectuart_*, avm_get_hw_config_table,
AVM-FIQ-Helfer und weitere.
- Die DECT-Firmware wird über UART/GPIO geladen (Piglet).
- Der Audio-/PCM-Pfad hängt an QCA-TDM/DMA und den PCM-Slots von pcmlink.
- Die Userspace-Seite ist uClibc, OpenWrt verwendet musl.
Ich habe keine Ahnung, ob der DECT-Chip ohne die AVM-FIQ-/TDM-Infrastruktur
überhaupt sinnvoll ansprechbar ist. Deshalb möchte ich nicht behaupten, dass
ein Port leicht wäre – im Gegenteil.
Meine bisherigen Ergebnisse, ABI-Header, Protokollnotizen und lokale Mocks
liegen hier:
GitHub - Rockstein2/FRITZ.Box_7530-08.25-kernel-4.4.271-telephony-re: Reverse-engineering notes and tooling for FRITZ!Box 7530 DECT/telephony (FRITZ!OS 08.25, Linux 4.4.271): /dev/dect_io ABI, Piglet firmware loader, pcmlink TDM/PCM boundary and avm_
Reverse-engineering notes and tooling for FRITZ!Box 7530 DECT/telephony (FRITZ!OS 08.25, Linux 4.4.271): /dev/dect_io ABI, Piglet firmware loader, pcmlink TDM/PCM boundary and avm_dect stack. Resea...
github.com
Im Repository sind bewusst keine AVM-Binaries, Firmware-Images oder
extrahierten Vendor-Skripte enthalten – nur Dokumentation, Header, Tools und
Mock-Tests. Die Extraktion aus dem Original-Image ist dort beschrieben.
Meine Fragen an die Runde:
1. Hat jemand so einen Port einer AVM-Telefonie-/DECT-Stacks schon einmal
versucht oder davon gehört?
2. Sind die AVM-APIs (tdm_if_*, dakota_gpio_*, msm_dectuart_*), der QCA-TDM-
Teil oder das DECT-UART-Protokoll irgendwo dokumentiert?
3. Gibt es einen realistischen Teilport – z. B. nur DECT oder nur
die FON-Seite – oder muss immer der komplette Audio-/TDM-Pfad mit?
4. Hat jemand Erfahrung mit AVM-Kernelmodulen, QCA-TDM/DMA oder DECT-
Firmware-Loading und hätte Lust, Teilbereiche zu übernehmen?
5. Oder ist die pragmatische Antwort: zweite FRITZ!Box behalten und die Zeit
lieber in etwas Sinnvolleres investieren?
Ich freue mich über jede ehrliche Einschätzung – auch wenn sie „lass es“
lautet. Mir geht es zuerst darum, den Aufwand realistisch einzuschätzen,
bevor ich weiter Zeit in die Analyse stecke.
Danke und viele Grüße
