Freetz FritzBox 7570

soso

Mitglied
Mitglied seit
17 Mai 2005
Beiträge
445
Punkte für Reaktionen
1
Punkte
18
Hallo,
ich will freetz-linux 1.2.1 für eine FritzBox 7570 nutzen. Beim Erstellen des Images bekomme ich zunächst die Fehlermeldung:
make *** [dl/fw/fritz.Box_Fon_WLAN_7570_vDSL.en-de-fr.75.04.91.image] Fehler 3
Habe danach das Image 75.04.92 von der AVM Seite runtergeladen, nach /dl/fw abgespeichert und in ...75.04.91 umbenannt.
Jetzt bekomme ich die Fehlermeldung:
downloading...make: ***[dl/fw/Fritzbox7270-source-files-04.86.tar.gz] Fehler 1

Hat jemand eine Idee?
 
ich will freetz-linux 1.2.1 für eine FritzBox 7570 nutzen.
Bitte nicht! Nimm Freetz-Trunk aber bitte nicht die mittlerweile total veralteten Freetz-Versionen 1.21 oder 2.0! Das gilt auch für die alte 7570. Dann wird auch gleich die passende Firmware-Version von AVM (Ver. 4.92 anstatt 4.91) verwendet.

Das wäre zumindest die erste beste Idee bevor man irgendwie weitermacht.
 
Die Anleitung scheint nicht mehr zu stimmen da inzwischen ein Domain-Wechsel von freetz.org nach freetz.github.io stattgefunden hat.
Ich habe inzwischen freetz-linux-1.4.1 von hier: https://sourceforge.net/projects/freetz-linux/
heruntergeladen und in die VirtualBox importiert.
sudo apt-get update und sudo apt-get upgrade -y laufen ohne Probleme durch aber svn checkout http://svn.freetz.org/trunk freetz-trunk funktioniert nicht da die Domain geändert wurde. Das Verzeichniss Freetz-Linux in der VirtualBox ist komplett leer.
Ferner funktioniert das gesammte obere Menu der Seite: https://freetz.github.io nicht mehr.
 
Ich verteh nur Bahnhof.
Was muss ich tun um eine Freetz-Entwicklungsumgebung in der VirtualBox zu bekommen?
 
OK, git clone https://github.com/freetz/freetz.git ersetzt jetzt das svn checkout!
Ich habe jetzt die Entwicklungsumgebung.

Mein letztes Freetz-Projekt ist schon ein paar Jahre her und basiert auf freetz-1.1.4. Seit der Zeit scheint sich so einiges geändert zu haben. Ich will jetzt mein UltraVNC-Repeater Plugin einbinden. Unter freetz-1.1.4 funktionierte das folgendermaßen:

1. Unter /freetz-1.1.4/make/ das Projekt in die Config.in unter menue "Testing" source/make/uvncrepeater/Config.in einfügen.
2. unter /freetz-1.1.4/make/ ein neues Verzeichniss uvncrepeater anlegen und die Makefiles dort hin Kopieren.
3. Unter /freetz-1.1.4/source/ ein neues Verzeichniss für meine Source-Files anlegen und die Source-Files dort hin kopieren.
4. In make menueconfig mein Projekt aktiveren und mit make ein neues Image bauen.

Bevor ich jetzt unter freetz-1.4.1 etwas versemmele will ich noch mal nachfragen:

1. Unter freetz/make/ gibt es jetzt die Config.in.generated ersetzt die die Config.in und kann ich da mein Projekt einfügen? Warum heist die Datei …generated? Wird die aus anderen Quellen generiert?
2. Unter freetz/source/ gibt es jetzt ein Verzeichniss: target-mipsel_gcc….
In diesem Verzeichniss sind jetzt wohl die Ordner mit den Quelldateien untergebracht. Kann ich meinen Ordner einfach dort hin kopieren? Muss ich noch irgend was unter make editieren da die Quelldateien jetzt an einem anderen Ort stehen? Oder findet der die automatisch?
 
Die Config.in.generated wird aus allen Unterverzeichnissen in "make" generiert.

Um da ein eigenes Projekt/Programm einzufügen, brauchst Du also nur das passende Verzeichnis anlegen.

Darin muß dann wiederum eine Datei "<package>.mk" liegen, die auf verschiedene "make"-Makros zugreifen kann und eines davon wäre dann "$(PKG_LOCALSOURCE_PACKAGE)", mit dem man "ansagen" kann, daß die Quellen für das Paket nicht aus dem Internet kommen sollen, sondern aus dem lokalen Unterverzeichnis "src".

Wie das ansonsten geht und was da in einem "mk"-File als Beispiel definiert sein kann, kannst Du Dir in meinem "decoder"-Projekt ansehen: https://github.com/PeterPawn/decoder

Das Projekt ist in dieser Form dafür gedacht, um einfach in ein Unterverzeichnis im "make"-Zweig einer Freetz-Installation eingebunden zu werden (das muß dann allerdings auch "decoder" heißen, weil das "mk"-File diesen Namen trägt) und mit den beiden Dateien "Config.in" und "decoder.mk" hast Du zumindest mal zwei "Vorlagen", wie das aussehen könnte. Die Make-Makros sind irgendwo (in Ansätzen zumindest) dokumentiert und man kann einige davon durchaus sinnvoll nutzen, wenn man das eigene Projekt in den Build-Prozess bei Freetz einbetten will.

Unterhalb von "source" brauchst/solltest Du nichts ablegen ... da landen die entpackten und gepatchten Quellen der Pakete und dort vorgenommene Änderungen sind schneller wieder weg, als man gucken kann, wenn nach einer Änderung im "make/<package>"-Verzeichnis die Quellen dann neu "entpackt" (bzw. bei einem lokalen Paket dann halt nur aus "src" kopiert) werden.

Abgesehen davon solltest Du noch mal Ordnung in die Zahlen (und vielleicht auch in die Gedanken) bringen ... mal ist von "freetz-1.1.4" die Rede, mal von "freetz-1.4.1" (und mit der letzteren Nummer gibt es durchaus auch noch ein "freetz-linux"-Image: https://sourceforge.net/projects/freetz-linux/) und eigentlich könnte man ja auch gleich das neue 1.5.1-Image nehmen, wenn das irgendetwas mit der Version des Linux-Images zu tun haben soll. Wobei man ein Image mit der Nummer 1.4.1 irgendwie auch nicht "schon vor ein paar Jahren" benutzt haben kann, denn die 1.4.1 gibt es ja auch erst seit 2 1/2 Jahren. Ich hoffe, Du verstehst, warum die Zahlen "etwas wirr" erscheinen und der Text rundherum keinen richtigen "Kontext" bildet.

Aber vollkommen egal, welches Image man nun mit welchem VM-Host (oder auch "native") benutzt ... nach einem "git clone ..." ohne Angabe eines Zielverzeichnisses, entsteht ein Verzeichnis "freetz" mit dem Klon und warum sollte man dieses Verzeichnis jetzt "freetz-1.4.1" (oder auch "freetz-1.1.4") nennen? Welchen Bezug hätte diese "Nummer", wenn man das oben erwähnte "git clone" verwendet hat? Wieso könntest Du dann:
Bevor ich jetzt unter freetz-1.4.1 etwas versemmele will ich noch mal nachfragen:
unter freetz-1.4.1 irgendetwas "versemmeln"?

Vor allem kann man eigentlich nur wenig falsch machen ... funktioniert die eigene Kopie des Freetz-Master-Repos nicht mehr, weil man darin Unsinn verzapft hat, klont man das einfach in ein anderes Verzeichnis (nach der URL darf ja auch noch ein lokaler Verzeichnisname stehe, unter dem das gespeichert werden soll) erneut und kann dann wieder "von vorne" beginnen und den eigenen Fehler beim zweiten Anlauf einfach weglassen.
 
  • Like
Reaktionen: gismotro
@PeterPawn
Ich habe das uvncrepeater plugin zuletzt 2010 compiliert. Das mk-File sieht wie folgt aus:

Code:
$(call PKG_INIT_BIN,014)
$(PKG)_SOURCE:=repeater$($(PKG)_VERSION).zip
$(PKG)_SITE:=http://koti.mbnet.fi/jtko/uvncrepeater
$(PKG)_DIR=$(SOURCE_DIR)/Ver014
$(PKG)_BINARY:=$($(PKG)_DIR)/repeater
$(PKG)_TARGET_BINARY:=$($(PKG)_DEST_DIR)/usr/bin/repeater
$(PKG)_SOURCE_MD5:=3005ebbb2f9442cbea4cbcaa71925dbf

$(PKG_SOURCE_DOWNLOAD)
$(PKG_UNPACKED)
$(PKG_CONFIGURED_NOP)

$($(PKG)_BINARY): $($(PKG)_DIR)/.configured
   PATH="$(TARGET_PATH)" \
       $(MAKE) -C $(UVNCREPEATER_DIR) \
       CC="$(TARGET_CC)" \
       CFLAGS="$(TARGET_CFLAGS)"

$($(PKG)_TARGET_BINARY): $($(PKG)_BINARY)
   $(INSTALL_BINARY_STRIP)

$(pkg):

$(pkg)-precompiled: $($(PKG)_TARGET_BINARY)

$(pkg)-clean:
   -$(MAKE) -C $(UVNCREPEATER_DIR) clean

$(pkg)-uninstall:
   $(RM) $(BIP_TARGET_BINARY)

$(PKG_FINISH)

Leider ist die Seite: http://koti.mbnet.fi/jtko/uvncrepeater inzwischen nicht mehr online. Beim make wird immer versucht ein repeater014.zip runterzuladen. Ich habe aber die Quelldateien. Die stehen indem Unterordner Ver014 im Ordner make/uvncrepeater. Was muss ich am mk-File ändern um das Runterladen zu überspringen?
 
Beim make wird immer versucht ein repeater014.zip runterzuladen. Ich habe aber die Quelldateien. Die stehen indem Unterordner Ver014 im Ordner make/uvncrepeater. Was muss ich am mk-File ändern um das Runterladen zu überspringen?

einfach die Datei repeater014.zip in das Verzeichnis dl kopieren;
dann wird der Download-Versuch übersprungen.
 
So, ich hab das repeater014.zip online gestellt. Das runterladen klappt jetzt. Leider tritt aber noch ein Fehler beim make uvncrepeater-precompiled auf:
Code:
freetz@freetz-linux:~/freetz$ make uvncrepeater-precompiled
WARNING: The header file readline/readline.h was not found in /usr/(local/)include.
---> package/uvncrepeater: preparing... mkdir -p source/target-mipsel_gcc-4.6.4_uClibc-0.9.29/Ver014; tools/unzip dl/repeater014.zip -d source/target-mipsel_gcc-4.6.4_uClibc-0.9.29/Ver014 -J 1
Archive:  dl/repeater014.zip
  inflating: EventListener$1.class
  inflating: EventListener$MyTableModel.class
  inflating: EventListener.class
  inflating: EventListener.java
  inflating: In.class
  inflating: In.java
  inflating: ListenerThread$1.class
  inflating: ListenerThread.class
set -e; shopt -s nullglob; for i in make/uvncrepeater/patches/*.patch; do tools/freetz_patch source/target-mipsel_gcc-4.6.4_uClibc-0.9.29/Ver014 $i; done;
    applying patch file make/uvncrepeater/patches/100-cross_compile.patch
    can't find file to patch at input line 3
    Perhaps you used the wrong -p or --strip option?
    The text leading up to this was:
    --------------------------
    |--- Makefile.orig  2010-03-02 10:52:48.000000000 +0100
    |+++ Makefile       2010-03-02 10:53:48.000000000 +0100
    --------------------------
    No file to patch.  Skipping patch.
    1 out of 1 hunk ignored
    ----------------------------------------------------------------------
ERROR: modpatch: Error in patch-file make/uvncrepeater/patches/100-cross_compile.patch
make: *** [source/target-mipsel_gcc-4.6.4_uClibc-0.9.29/Ver014/.unpacked] Fehler 2
freetz@freetz-linux:~/freetz$
Das 100-cross_compile.patch ist nicht von mir und sieht folgendermaßen aus:
Code:
--- Makefile.orig   2010-03-02 10:52:48.000000000 +0100
+++ Makefile   2010-03-02 10:53:48.000000000 +0100
@@ -1,27 +1,28 @@
+CC=g++
 CFLAGS=-Wall
 repeater: repeater.o repeaterproc.o openbsd_stringfuncs.o iniparser.o readini.o repeaterutil.o repeaterevents.o
-   g++ $(CFLAGS) -o repeater repeater.o repeaterproc.o openbsd_stringfuncs.o iniparser.o readini.o repeaterutil.o repeaterevents.o
+   $(CC) $(CFLAGS) -o repeater repeater.o repeaterproc.o openbsd_stringfuncs.o iniparser.o readini.o repeaterutil.o repeaterevents.o
 repeater.o: repeater.cpp
-   g++ $(CFLAGS) -c repeater.cpp
+   $(CC) $(CFLAGS) -c repeater.cpp
 repeaterproc.o: repeaterproc.cpp
-   g++ $(CFLAGS) -c repeaterproc.cpp
+   $(CC) $(CFLAGS) -c repeaterproc.cpp
 openbsd_stringfuncs.o: openbsd_stringfuncs.cpp
-   g++ $(CFLAGS) -c openbsd_stringfuncs.cpp
+   $(CC) $(CFLAGS) -c openbsd_stringfuncs.cpp
 iniparser.o: iniparser.cpp
-   g++ $(CFLAGS) -c iniparser.cpp
+   $(CC) $(CFLAGS) -c iniparser.cpp
 readini.o: readini.cpp
-   g++ $(CFLAGS) -c readini.cpp
+   $(CC) $(CFLAGS) -c readini.cpp
 repeaterutil.o: repeaterutil.cpp
-   g++ $(CFLAGS) -c repeaterutil.cpp
+   $(CC) $(CFLAGS) -c repeaterutil.cpp
 repeaterevents.o: repeaterevents.cpp
-   g++ $(CFLAGS) -c repeaterevents.cpp
+   $(CC) $(CFLAGS) -c repeaterevents.cpp
 clean:
     rm -f *.o repeater
Unter freetz-1.1.4 läuft das make problemlos durch. Da hat sich vermutlich was beim Handling der patch-Dateien geändert.
Wie muss ich die patch-Datei ändern damit es wieder läuft?
 
So ich bin einen Schritt weiter.
Das Plugin wird jetzt richtig compiliert. Nach dem flashen der Firmware taucht nach dem Freetz-login das Paket unter Status -> Freetz info -> FREETZ configuration -> Packages -> uvncrepeater auf. Aber unter Status -> Services ist nichts zu sehen. Da müsste ein Eintrag: "start stop restart" sein. Das zugehörige rc.uvncrepeater habe ich in "freetz\make\uvncrepeater\files\root\etc\init.d" abgespeichert. Das rc.uvncrepeater sieht so aus:
Code:
#!/bin/sh

export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin
export LD_LIBRARY_PATH=/mod/lib

DAEMON=repeater
DAEMON_CONF=/tmp/flash/uvncrepeater.ini
DAEMON_LOG=/var/log/uvncrepeater.log

init() {
        echo "copy uvncrepeater.ini to $DAEMON_CONF"
        cp /etc/uvncrepeater.ini $DAEMON_CONF
        }

start() {
        echo -n 'adduser uvncrep...'
        adduser -D -H uvncrep
        if [ ! -r /tmp/flash/uvncrepeater.ini ]; then
                init
        fi
        echo -n 'Starting uvncrepeater...'
        if [ -z "$(pidof "$DAEMON")" ]; then
                $DAEMON $DAEMON_CONF > $DAEMON_LOG 2>&1 &
                exitval=$?
                if [ "$exitval" -eq 0 ]; then
                        echo 'done.'
                else
                        echo 'failed.'
                fi
        else
                echo "$DAEMON is already running"
        fi
}

stop() {
        echo -n 'Stoping uvncrepeater...'
        killall $DAEMON > /dev/null 2>&1
        exitval=$?
        if [ "$exitval" -eq 0 ]; then
                echo 'done.'
        else
                echo 'failed.'
                exit $exitval
        fi
}

case "$1" in
        ""|start)
                start
                ;;

        stop)
                stop
                ;;
        restart)
                stop
                sleep 1
                start
                ;;
        status)
                if [ -z "$(pidof "$DAEMON")" ]; then
                        echo 'stoped'
                else
                        echo 'running'
                fi
                ;;

        reset)
                if [ ! -z "$(pidof "$DAEMON")" ]; then
                        stop
                fi
                init
                start
                ;;
        *)
                echo "Usage: $0 [start|stop|restart|status|reset]" 1>&2
                exit 1
                ;;
esac

exit 0

Hat sich da was geändert?
 
Damit ein Paket am GUI "teilnehmen" kann, muß es entsprechend registriert sein. Wie das geht, wo man Beispiele findet (neben den vielen anderen Paketen, die bereits in Freetz enthalten sind), findet man im alten Wiki, welches den Weg nach GitHub angetreten hat: https://freetz.github.io/wiki/help/howtos.html

Wenn davon dann Einzelheiten nicht klar sind, lohnt die Nachfrage vermutlich ... aber eine gesonderte "Nacherzählung", welche Schritte notwendig wären, dürfte überflüssig sein, denn Du kannst Dich ja auch dort informieren.

Und ja ... Deine Vermutung ist wohl korrekt, es hat sich seit Freetz 1.2 (woher das 1.4.1 kam, habe ich ja immer noch nicht verstanden) einiges im Alauf verändert. Jedenfalls wird das gezeigte "rc"-File eher nicht in der Lage sein, das Paket am GUI anzumelden ... das zeigt aber schon der allerflüchtigste Blick in so ziemlich jedes andere File mit ähnlichen Aufgaben aus anderen Paketen, den man sogar direkt im GitHub-GUI riskieren kann, hier mal am Beispiel des "dropbear"-Pakets: https://github.com/Freetz/freetz/blob/master/make/dropbear/files/root/etc/init.d/rc.dropbear
 
Und ja ... Deine Vermutung ist wohl korrekt, es hat sich seit Freetz 1.2 (woher das 1.4.1 kam, habe ich ja immer noch nicht verstanden) ...

Ich denke hier sind zwei sachen vermischt worden.

Bei Freetz 1.2 ist m.E. die Freetz-Stable-Version 1.2 gemeint, wo hingegen bei 1.4.1 der Update der Ubuntu-Umgebung der VM gemeint ist.

Wenn ich mich noch richtig erinnere hatte Silent-Tears damals passend zu Freetz 1.2 eine Buildumgebung 1.2.1 bereit gestellt ( https://sourceforge.net/projects/freetz-linux/) diese ist mit der Zeit bis zur 1.5.1 upgedatet worden

1.2.1 = Ubuntu 9.10
1.3.1 = Ubuntu yyy
1.4.1 = Ubuntu 14.4 (Danke an tuxedonet)
1.5.1 = Ubuntu 18.4.1

https://www.ip-phone-forum.de/threads/buildumgebung-freetz-linux.199449/#post-1400234
 
Zuletzt bearbeitet:
Die Freetz Build Umgebung 1.4.1 hatte einen Aufbau nach 14.04 LTS und nicht 16.4.1 soweit ich mich erinnere.
 
Stimmt, von 14.04 LTS hab ich die damals selber auf 16.04 upgedatet. Da das aber noch 32-Bit war, habe ich 1x eine 1.5.1 als Update auf 18.04.1 vom alten Freetz-Linux gemacht und eine eigene Version 1.5.1 64-Bit auf Ubuntu 18.04.01
 
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.