Freetz

Aus Zebradem WIKI
Zur Navigation springenZur Suche springen
http://www.zebradem.com/wiki/images/3/3d/Freetz_motd.png
http://www.zebradem.com/wiki/images/3/3d/Freetz_motd.png



Was ist eigentlich Freetz ?

Freetz wurde am 2. Februar 2008 ins Leben gerufen. Freetz, eine Zusammensetzung aus dem englischen free (= frei) und dem deutschen Namen Fritz, ist ein Software-„Baukasten“ für Entwickler und setzt die Entwicklungswerkzeuge des freien Betriebssystems Linux voraus. Mit Freetz können versierte Anwender auf der Original-Firmware des Herstellers aufbauende, funktional modifizierte Firmware-Versionen für die diverse DSL-, LAN-, WLAN- bzw. VoIP-Router der Marken Fritzbox bzw. Speedport und die auf ihnen beruhenden Geräte bauen und diese auf das betreffende Gerät transferieren. Es werden eine Vielzahl von Erweiterungspaketen sowie Möglichkeiten, nicht benötigte Funktionalität der Original-Firmware zu entfernen, angeboten. Die Bandbreite der Einflussmöglichkeiten reicht vom Einbinden diverser Linux-Dienste bis zum expliziten Ausblenden störender Trägerbänder im DSL-Spektrum, um Anschlüsse mit hoher Dämpfung zu optimieren.
Durch die MIPS CPU s die in der Fritzbox verbaut wurden , ist es möglich auch EMU s auf der Fritzbox laufen zu lassen , und somit Die Fritzbox als CS Server zu verwenden Achtung: Die Installation einer modifizierten Firmware führt zum Verlust der Gewährleistung des Herstellers!


Wie entstand Freetz?

Es gibt einige Vorläufer von Freetz. Daniel Eiband (bekannt als "Danisahne") hat vor einigen Jahren, aufbauend auf Vor- und Zuarbeiten anderer kreativer Köpfe (Erik Andersen, Christian Volkmann, Andreas Bühmann, Enrik Berkhan u.a.), den sog. Danisahne-Mod (kurz: DS-Mod) ins Leben gerufen. So wie heute mit Freetz, konnte und kann man auch damit Firmware-Modifikationen bauen, allerdings noch für ältere Firmware-Versionen mit Linux-Kernel 2.4. Da einige Router noch immer auf Kernel 2.4 basierende Firmwares haben, ist Version ds-0.2.9-p8 des DS-Mod für jene Geräte immer noch aktuell. Für die Mehrzahl aktueller Geräte war der direkte Vorläufer zu Freetz jedoch die von Oliver Metz ins Leben gerufene Version ds26 (zuletzt ds26-15.2), welche ausschließlich für Firmwares mit Kernel 2.6 geeignet ist. Selbiges gilt auch für Freetz, denn Freetz ist Stand heute (20.01.2008) nichts anderes als die aktuelle Entwicklerversion von ds26, nur mit neuem Namen.


Wozu überhaupt ein neuer Name, wo doch DS-Mod inzwischen so bekannt ist?

Es gibt mehrere Gründe dafür. Zum einen ist seit gut einem Jahr Daniel nicht mehr aktiv an der Weiterentwicklung von ds26 beteiligt gewesen, zum anderen hat er bei SourceForge schon etwa ebenso lange begonnen, eine von Grund auf neue DS-Mod-Version - nennen wir sie mal inofiziell DS-Mod NG (Next Generation) - zu entwickeln, deren aktueller Stand in einem öffentlich zugänglichen Quellcode-Repository auf der Projekt-Webseite einzusehen ist. Wir wollen Daniel seinen Projektnamen nicht streitig machen und auch nicht in Konkurrenz zu ihm treten, sondern hoffen im Gegenteil, daß er eines Tages wieder mehr Zeit für sein Projekt haben wird und schlußendlich beide wieder in ein gemeinsames münden, um alle Vorteile in einem Produkt zu vereinen. Zurzeit ist es jedoch so, daß beide Projekte sich deutlich auseinander entwickelt haben: DS-Mod NG hat eine sehr saubere Struktur, ist jedoch noch lange nicht fertig, Freetz (bzw. bisher ds26) ist hundertfach im Einsatz und wird eher während der laufenden Entwicklung immer wieder mal Refactoring-Maßnahmen unterworfen. Wo zuletzt in der Presse (z.B. PC-Welt) vom DS-Mod gesprochen wurde, war Freetz alias ds26 gemeint.

Warum Firmware modifizieren?

Es können zwar einzelne spezielle Dateien (character devices) unter /var/flash/ bearbeitet werden und sie behalten den Inhalt auch über einen Reboot hinweg, jedoch trifft das nicht auf den Rest des Dateisystems zu. Der Inhalt dieser character devices landet in einer eigenen Flash Partition, die sehr klein ist. Der überwiegende Teil des Dateisystems ist ein read-only Squashfs Image, welches in einem Firmware Update enthalten ist. Um (größere) Dateien dauerhaft in die Firmware einzubinden müssen sie in dieses Squashfs Image gelangen, welches unter anderem in Freetz implementiert ist.

Quellcode

Der Quellcode von Freetz kann aus dem Subversion-Repository bezogen werden: Stabile Version

Je nach Gerätetyp wird eine der nachstehenden Versionen benötigt:

freetz-1.1.2 (Kernel 2.6)

svn co http://svn.freetz.org/tags/freetz-1.1.2/

Alternativ kann der stable-branch-1.1 genutzt werden. Hier sind evtl. Fehler im Release 1.1.x gefixt.

svn co http://svn.freetz.org/branches/freetz-stable-1.1/ 

Eventuell vorhandene Änderungen am stable branch erhält man mit:

svn up
  • Bevor ihr nach einem "svn up" ein neuen Fehler meldet, stellt bitte sicher, dass der Fehler nach einem "make dirclean" noch immer auftritt.

ds-0.2.9-p8 (Kernel 2.4)

svn co http://svn.freetz.org/tags/ds-0.2.9-p8/ ds-0.2.9-p8
  • Entwicklerversion

Diese Version ist ausschließlich für Profis gedacht, die sich u.U. selbst zu helfen wissen! Sie ist ständigen Änderungen unterworfen und funktioniert möglicherweise nicht oder nur eingeschränkt.

svn co http://svn.freetz.org/trunk freetz-trunk

Update auf die neueste Entwicklerversion

svn up
  • Bevor ihr nach einem "svn up" ein neuen Fehler meldet, stellt bitte sicher, dass der Fehler nach einem "make dirclean" noch immer auftritt.

Man kann auch eine bestimmte Revision auschecken, falls z.B. die aktuelle nicht funktionieren sollte. Dabei einfach $revision durch die gewünschte Revision ersetzen.

svn co http://svn.freetz.org/trunk/ freetz-trunk -r $revision


Aussehen

Momentan gibt es nur ganz wenige Möglichkeiten, das Aussehen von FREETZ- oder auch von AVM-Webinterface zu verändern. Bei AVM hängt es damit zusammen, dass man die Urheberrechte von AVM auf ihre Webseiten nicht verletzen will. Bei FREETZ-WebIF ist es mehr historisch gewachsen: Bei der Vielfalt der vorhandenen Pakete ist es momentan nur schwer denkbar globale Änderungen im WebIF-Design durchzuführen. [1] [2]

Bibliotheken (libraries)

Bibliotheken (im Nachfolgenden "libs" genannt") zu Paketen, die abgewählt wurden, werden nicht automatisch mit abgewählt. Um nach der Abwahl diverser Pakete auch die nicht mehr benötigten libs zu entfernen (damit das Image nachher auch tatsächlich nicht zu groß wird) gibt es das folgende make target:

make config-clean-deps


Addons

Apache, php, samba ect. Siehe Freetz Wiki: [3]

Emus

lauffähige Emus

CCcam
NewCs
Camd3
Mpcs
oscam
Scam
Mgcamd
MBox
*box
sbox
Hypercam

Addon Zusammensetzung

  • rc.file
  • cgi file
  • config files

Addon Varianten

  • Addon USB-Stick
hiermit wird der Speicher wenig belastet , da binary,liberarys und configs auf einem USB Stick ausgelagert werden. dieses ist somit
die gängigste Variante 
  • Addon intern
hiermit wird der interne Speicher genutzt. Diese Variante wird weniger genutzt , da die Fritzboxen damit an seine Grenzen gebracht
wird. In Einzelfällen kann es aber ohne Probleme verwendet werden

Möglichkeiten

Man kann sich die Addons für seine Bedürfnisse anpassen oder für neue Anwendungen auch neue Addons erstellen

Pakete & CGI-Erweiterungen

siehe Freetz Wiki: [4]


Erstellen von Firmware-Images (make/Build)

Was bedeuten die einzelnen make-targets (z.B. dirclean, distclean, config-clean-deps etc.)? ¶

A: Die make-targets beeinflussen den Build-Prozess bei der FW-Erstellung. Viele der folgenden Infos entstammen ( diesem Thread).

1. Aufräumen:

make clean
     
make <Paket>-clean:

ruft normalerweise das clean-Target des Source-Makefiles auf. Dieses wird typischerweise alle generierten Dateien (vor allem Object-Dateien, Libraries und ausführbare Programme) löschen. Ein nachfolgendes make wendet keine geänderten Patches an, sondern erstellt nur die o.g. Object-Dateien, Libraries und ausführbare Programme neu (compilieren). Z.B. räumt make mc-clean so das Paket "Midnight Commander" (mc) auf.

make <Paket>-dirclean:

löscht das gesamte Verzeichnis des Pakets. Ein nachfolgendes make wird die Quellen neu auspacken, die Patches anwenden, das Paket konfigurieren und dann compilieren. Nur der letzte Schritt (compilieren) wird nach make <Paket>-clean (s.o.) ausgeführt.

make dirclean:

führt, wie der Name schon sagt, ein "Verzeichnis-Aufräumen" durch. Hierbei werden unter anderem die Verzeichnisse /packages, /source, /build, /toolchain/build, toolchain/target (und ein paar andere Sachen(?)) gelöscht, sodass bei erneutem Ausführen von make alles neu gebaut werden muss. Dies ist empfehlenswert, wenn sich Aufgrund eines svn up eine neu gebaute Firmware nicht so Verhält, wie man es erwartet. Alternativ kann man, wenn man weiß, an welchem Packet es liegt, dieses auch via make <Paket>-dirclean einzeln löschen (siehe oben). Zu erwähnen sei noch, dass nach einem make dirclean der Bau der Firmware natürlich länger dauert, da ja alles neu gebaut werden muss.

make tools-distclean:

löscht die Tools (busybox, lzma, squashfs, usw.)

make distclean:

Hier werden zusätzlich zum make dirclean auch noch die Downloads sowie die Tools gelöscht.

make config-clean-deps:

Wenn bei make menuconfig Pakete abgewählt wurden, sind ggfs. noch Shared Libraries ausgewählt, die nicht mehr benötigt werden (dies kann menuconfig nicht automatisch erkennen). Diese kann man dann manuell unter 'Advanced Options'→'Shared Libraries' abwählen - die benötigten lassen sich nicht deaktivieren. Alternativ kann man dies automatisch mittels make config-clean-deps erledigen lassen.

make kernel-dirclean:

löscht den aktuell entpackten Source-Tree des Kernels, um von komplett sauberen Kernel Sourcen zu kompilieren (wichtig wenn was an den Patches geändert wird)

make kernel-clean:

analog make <Paket>-clean

make kernel-toolchain-dirclean:

löscht den Kernel-Compiler

make target-toolchain-dirclean:

löscht den Compiler für die uClibc und die Binaries (ausführbare Programme)

2. Vorbereitungen:

make world:

Vorraussetzung ist eine Toolchain (siehe Cross-Compiler / Toolchain erstellen). Sollten jemals Probleme mit nicht vorhandenen Verzeichnissen auftauchen, so kann ein make world Abhilfe schaffen. In der Regel sollte das aber nicht nötig sein.

make kernel-toolchain:

kompiliert den Kernel und auch für das target (Fritzbox) Aus historischen Gründen wurde die Bezeichnung als kernel-toolchain belassen, obwohl damit wie gesagt nicht nur der Kernel gebaut wird, sondern auch Pakete (s.u.).

make target-toolchain:

kompiliert die Pakete für das target (Fritzbox)

make kernel-menuconfig:

Die Konfiguration des Kernels wird danach wieder nach ./make/linux/Config.<kernel-ref> zurückgespeichert.

make kernel-precompiled:

Damit werden der Kernel und die Kernel Module kompiliert.

make menuconfig (Quelle): Zum Konfigurieren von Freetz kommt das Programm conf/mconf zum Einsatz, welches dem ein oder anderen vielleicht von der Konfiguration des Linux Kernels bekannt ist. Die  ncurses Variante mconf kann mit dem Kommando make menuconfig aufgerufen werden.

Übrigens: Eine Hilfe zu den einzelnen Punkten kann direkt in menuconfig durch Eingabe von "?" aufgerufen werden. Und nach Eingabe von "/" kann man von allen Ebenen aus nach beliebigen Zeichenfolgen suchen - sehr praktisch.


Anleitungen

Freetz Image erstellen

Anleitung Freetz flashen bis zum CS Server einrichten

Links

ZebraDem - Bei Fragen und Problemen zu Freetz

|}