Erstellt vor 7 Jahren

Zuletzt geändert vor 4 Jahren

#957 assigned defect

dtmfbox funktioniert mit aktuellem Freetz-Trunk nicht

Erstellt von: Mulder Verantwortlicher:
Priorität: normal Meilenstein: freetz-future
Komponente: packages Version: devel
Stichworte: Beobachter: buehmann
Product Id: Firmware Version: 74.04.85freetz-devel-5422

Beschreibung (zuletzt geändert von oliver)

Ich habe das dtmfbox Paket im Menüconfig ausgewählt. Leider erhalte ich bei Anklicken der Konfigurationsmöglichkeiten im Freetz-Webinterface nur die folgende Meldung:

Fehler: dtmfbox&sort=0&page=status: Unbekanntes Paket

Anhänge (8)

rc.dtmfbox.patch (720 Byte) - hinzugefügt von oliver vor 7 Jahren.
Fix errors in rc file
dtmfbox-cgi_1.diff (261.3 KB) - hinzugefügt von JMC vor 7 Jahren.
dtmfbox-cgi patch
dtmfbox-cgi_3.diff (283.9 KB) - hinzugefügt von JMC vor 7 Jahren.
dtmfbox-cgi patch new version
dtmfbox-0.5.0-gcc-4.5.3-Os.patch (1.9 KB) - hinzugefügt von hm vor 6 Jahren.
Workaround für gcc-4.5.3 -Os Problem
dtmfbox-0.5.0-fix-null-ptr-and-max-suboptions.patch (1.4 KB) - hinzugefügt von hm vor 6 Jahren.
Optional: Bereinigung von plugin_execute_cmd()
dtmfbox.diff (6.3 KB) - hinzugefügt von db1ras vor 4 Jahren.
dtmfbox-cgi.diff (263.6 KB) - hinzugefügt von db1ras vor 4 Jahren.
nur-zum-vergleich-dtmfbox-cgi-mww.diff (4.6 KB) - hinzugefügt von db1ras vor 4 Jahren.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (79)

comment:1 Geändert vor 7 Jahren durch Mulder

Alle dtmfbox_*.cgi Dateien erzeugen die Ausgabe "Unbekanntes Paket", z.B.

Fehler: dtmfbox_main.cgi: Unbekanntes Paket

comment:2 Geändert vor 7 Jahren durch cuma

Wie oliver schon im IPPF schrieb:
Das Problem mit dtmfbox wird wohl nur bodega beheben können, da der Download auf seinem Server liegt.

comment:3 Geändert vor 7 Jahren durch oliver

  • Beschreibung geändert (Diff)

comment:4 Geändert vor 7 Jahren durch oliver

Ich hab mir das dtmfbox-Paket mal genauer angesehen. Leider hat bodega das auch als "Standalone" Version ohne Freetz entwickelt. Deshalb sind die Skripte sehr groß und unübersichtlich. Momentan weiß ich nicht was wir mit dem Paket machen sollen. In meinen Augen wäre es am Besten, wenn wir ein komplett neues Webinterface dafür schreiben, aber wer will/soll das machen?

comment:5 Geändert vor 7 Jahren durch oliver

(In [5612]) * dtmfbox: Remove svn option from menuconfig

  • Put files in our svn instead of copying from source
  • Rewrite Makefile
  • refs #957


TODO: Repair webinterface

comment:6 Geändert vor 7 Jahren durch cuma

  • Komponente von avm nach packages geändert

comment:7 Geändert vor 7 Jahren durch oliver

  • Status von new nach assigned geändert
  • Verantwortlicher auf buehmann gesetzt

@Andreas
Please look after it if you find time to.

comment:8 Geändert vor 7 Jahren durch kraut

Gibt es schon etwas neues? Bin ebenso in dieses Problem gelaufen und würde mich über einen Fix sehr freuen.

Grüße
Thomas

comment:9 Antwort: Geändert vor 7 Jahren durch JMC

Abgesehen vom fehlenden Webinterface (bei mir tauchts nichtmal in der Liste auf) ist mir was anderes aufgefallen:

  • Mit der aktuellen rc.dtmfbox lässt sie sich auch über rc.custom oder telnet nicht starten. Kommt die busybox applet Fehlermeldung.
  • Kopiete ich aber meine "alte" rc.dtmfbox aus dem ursprünglichen 0.5.0er Paket rüber lässt sich dtmfbox zumindest von Hand starten

comment:10 als Antwort auf: ↑ 9 Geändert vor 7 Jahren durch oliver

Replying to JMC:

Kommt die busybox applet Fehlermeldung.

Soll mir meine Glaskugel die Fehlermeldung verraten?

comment:11 Geändert vor 7 Jahren durch JMC

Sorry - ich war per VNC drauf und hatte c&P gemacht - allerdings ohne das einfügen…
"Error: Please use busybox with needed applets enabled."

comment:12 Geändert vor 7 Jahren durch JMC

Erster Fehler gefunden:
In Zeile 35 in der rc.dtmfbox ist B_CMD_MISSING="0" statt BB_CMD_MISSING="0"

Allerdings geht dann der Busyboc check immer noch in die Hose obwohl die busybox die applets hat. Das entfernen der \ vor den " in Zeile 41 wirkt allerdings auch hier:

root@fritz:/var/tmp# ./rc.dtmfbox check_busybox
Testing /bin/busybox … done.

Geändert vor 7 Jahren durch oliver

Fix errors in rc file

comment:13 Antwort: Geändert vor 7 Jahren durch viktor

still not good, sorry.
busybox check is ok, but it has problems with the modreg part.

rc.dtmfbox:

modreg cgi "dtmfbox&sort=0&page=status" "dtmfbox-Status"

does not work, because puts the .cgi to the end. I hacked modreg, but it only made things worser:

rc.dtmfbox:

modreg cgi "dtmfbox&sort=0&page=status" "dtmfbox-Status"

modreg:
	conf)
		pkg=$2 id=$3 title=$4
		if [ "$id" = _index ]; then
			if [ ! -z $(echo "$pkg" | grep "\.cgi") ]; then
				cgi="$pkg"
			else
				cgi="$pkg.cgi"
			fi
		else
			cgi="$pkg/$id.cgi"
		fi
		echo "$cgi"
		#file_exists_or_die "/mod/usr/lib/cgi-bin/$cgi"
		replace "^$pkg|$id|" /mod/etc/reg/conf.reg "$pkg|$id|$title"
		touch /mod/var/cache/menu.stale

now some menu entries appears, but it says when clicked:
Fehler: Invalid path

So I guess modreg should be used differently…

comment:14 Geändert vor 7 Jahren durch viktor

modreg cgi "dtmfbox.cgi&sort=0&page=status" "dtmfbox-Status"

comment:15 als Antwort auf: ↑ 13 Geändert vor 7 Jahren durch buehmann

Replying to viktor:

So I guess modreg should be used differently…

Yes, it is not allowed (and it never was) to pass CGI parameters like this.

comment:16 Geändert vor 7 Jahren durch viktor

ok. then we have these lines. how should they be used? modreg file maybe?

modreg cgi "dtmfbox&sort=0&page=status" "dtmfbox-Status"

modreg cgi "dtmfbox&sort=1&page=dtmfbox_cfg" "dtmfbox-Basis"

modreg cgi "dtmfbox&sort=2&page=script_cfg" "dtmfbox-Skript"

modreg cgi "dtmfbox&sort=3&page=menu_cfg" "dtmfbox-Menü"

modreg cgi "dtmfbox&sort=4&page=scripts" "dtmfbox-SkriptEdit"

comment:17 Geändert vor 7 Jahren durch buehmann

No, modreg extra probably (and maybe a single modreg cgi for the main page). The parameters should be moved to some wrapper scripts, which are then registered.

comment:18 Geändert vor 7 Jahren durch oliver

(In [5853]) * dtmfbox: Fix broken busybox check (refs #957)

comment:19 Geändert vor 7 Jahren durch oliver

  • Meilenstein von freetz-1.2 nach freetz-1.2.1 geändert

comment:20 Geändert vor 7 Jahren durch cuma

Wäre es nicht besser dtmfbox solang in "unstable" zu schieben?

comment:21 Geändert vor 7 Jahren durch cuma

(In [6118]) dtmfbox: moved to unstable (refs #957)

comment:22 Antwort: Geändert vor 7 Jahren durch JMC

Ich hab gerade von 5919 auf den aktuellen Trunk geupdated - seitdem lässt sich dtmfbox garnicht mehr starten. Neu ausgecheckt und alles - bekomm es nicht mehr zum laufen. Weder mit meiner alten rc.dtmfbox noch mit der aktuellen aus dem trunk. Die menu.cfg ist vorhanden und seit september auch unangetastet. Mit dem alten Image lief es noch…
Was mir gerade noch eingefallen ist: Es gab doch vor kurzem ein Ticket das die default startup-Werte für die pakete geändert hat… Da es ja kein webinterface mehr für DTMFBOX gibt - könnte es damit zusammenhängen?

 09:19:57 Found controller #5 with 5 B-channel(s)
 09:19:57 CAPI registered (ApplID: 7, B-Channels: 12)
 09:19:57 Build a-law/pcm table buffer
 09:19:57 CAPI initialized!
 09:19:57 [plugin.menu] Loading /var/dtmfbox//menu.cfg ...
Segmentation fault
failed!
root@fritz:/var/media/ftp/uStor01/dtmfbox#

comment:23 Geändert vor 7 Jahren durch JMC

Ich hab mal ein bisschen rumprobiert so ein wrapper script hinzubekommen… so wirklich will es nicht (ich hab aber auch keine ahnung davon und mich ein bisschen an vorhandenen sachen orientiert) - die hilfe bekomme ich schonmal aufgerufen per menü. allerdings verschwindet dann das freetz menü und ich sehe den quelltext vom cgi… nicht ganz so wie es sein sollte ;)

Es gibt aber doch auch im dtmfbox paket die "einzelnen" cgi seiten im mww Ordner. Könnte man die nicht evtl. einbinden?

comment:24 Geändert vor 7 Jahren durch oliver

Meine Idee war für dtmfbox ähnlich wie für das wol-cgi einen eigenen Webserver zu starten. Eventuell müssen da auch einige meiner Änderungen wieder zurück genommen werden.

Probier doch mal, ob du mit diesem Konzept weiter kommst. Die Schwierigkeit besteht darin dtmfbox zu sagen, dass dtmfbox unter Freetz läuft aber für das Webinterface die vollen Seiten bereitstellen soll und nicht nur die Frames für Freetz.

comment:25 Geändert vor 7 Jahren durch JMC

Ich habs nach einigem rumprobieren hinbekommen ein eigenen webserver für die dtmfbox oberfläche zu starten. Allerdings mit dem fast gleichen Ergebnis:
die dtmfbox_help.cgi erscheint als quelltext, ebenso die dtmfbox_scriptedit.cgi
die meisten seiten bleiben einfach "leer" (auch im quelltext)
aber immerhin die dtmfbox_status seite bekomme ich schonmal…
"dtmfbox stopped!"

Aber was mir gerade einfällt:
dtmfbox hat ja schon eine Webserver-Funktion eingebaut. Ich habe gerade mal das Paket im menuconfig weggelassen und gemäß der "alten" usb anleitung installiert. Siehe da: Eigener Server auf Port 6767 (in der config eingetragen) und der läuft sogar… Jetzt muss ich nur noch rauskriegen wie man das doofe ding dazu bekommt auch mit eingebautem paket zu starten…

comment:26 Geändert vor 7 Jahren durch JMC

Ich habs am laufen - die Kombination ist allerdings so nicht wirklich "trunk" fähig…
Ich hab die Sachen aus dem "normalen" mipsel paket von hier (http://dtmfbox.v3v.de/dl/dtmfbox-0.5.0_mipsel.tar) genommen, mit eingebunden und mit dem rc.dtmfbox script aus dem paket kommt dabei am ende auch ein lauffähiges Webinterface raus…

Es gibt noch ein paar Baustellen an denen ich etwas verzweifel:

  • im derzeitigen Status gibt es 2 getrennte start scripte. rc.dtmfbox für die dtmfbox selber und ein zweites für das webinterface - ich weiß auf anhieb aber nicht wie ich die zusammenbauen kann. ich bekomms nicht hin - wenn ich es zusammen mache wird das webinterface nicht gestartet bevor das paket installiert ist… daher habe ich daraus 2 pakete gemacht, einmal dtmfbox-cgi und einmal das normale dtmfbox paket
  • das paket ausm aktuellen trunk läuft bei mir nicht mehr (seg fault beim starten der dtmfbox) - das tar paket läuft, ist aber fast 200kb größer wenn ich das richtig sehe.

derzeit ist es noch so, dass das starten des webinterfaces unterbunden wird weil die dtmfbox nicht installiert ist…
ausserdem muss vorher manuell der DTMFBOX_PATH gesetzt werden - warum auch immer…
export DTMFBOX_PATH=/var/media/ftp/uStor01/dtmfbox-0.5.0

Und ich muss einen symlink immer von hand anlegen
ln -s /usr/mww-dtmfbox/cgi-bin/dtmfbox.cgi /var/mod/usr/lib/cgi-bin/dtmfbox.cgi

Wenn man von diesen kleinen Punkten absieht habe ich aber jetzt ein laufendes Webinterface und eine laufende DTMFBOX ;)

Muss das ganze nochmal bereinigen… die frage ist aber wie erstell ich aus dem ganzen kram einen patch den ich anhängen kann?
(wobei… ich hab ja in packages/[…] gearbeitet… kann man das so überhaupt als patch machen?)

Alles in allem ist das sicherlich nicht das "level" an Qualität normalerweise erwartet wird - sorry.

comment:27 Geändert vor 7 Jahren durch JMC

So mittlerweile auch im richtigen Ordner gebastelt. Ich habe ein zusätzliches Paket dtmfbox-cgi gebaut nach dem vorbild des wol-cgi paketes. Allerdings habe ich nun ein kleines Problem das mich seit Stunden in den Wahnsinn treibt:

  • Nachdem ich das eigene Paket gemacht habe bekomm ich das webif nicht mehr zum laufen. Es läuft, aber scheinbar findet er die dateien im cgi-bin ordner nicht mehr oder er sucht seinen cgi-bin ordner irgendwo anders. Sie sind da, ich kanns nicht nachvollziehen. Im richtigen Ordner startet der Webserver auch, z.B. das java phone applett könnte ich über den browser auch runterladen - das liegt ja im documentroot
  • bestimmte Links müssen nach jedem reboot von hand angelegt werden. Ich hab schon ewig rumgesucht, finde aber nicht warum die für dieses Paket nicht automatisch angelegt werden.
cp /etc/default.dtmfbox-cgi/dtmfbox-cgi.cfg /mod/etc/conf/
ln -s /usr/mww-dtmfbox-cgi/cgi-bin/dtmfbox.cgi /var/mod/usr/lib/cgi-bin/dtmfbox-cgi.cgi
ln -s /etc/init.d/rc.dtmfbox-cgi /var/mod/etc/init.d/rc.dtmfbox-cgi
ln -s /etc/default.dtmfbox-cgi/ /mod/etc/default.dtmfbox-cgi
ln -s / /var/mod/pkg/dtmfbox-cgi

Ich häng meinen Patch mal an, vielleicht hat ja noch jemand ne Idee… Ich komm nicht mehr weiter.

Geändert vor 7 Jahren durch JMC

dtmfbox-cgi patch

comment:28 Antwort: Geändert vor 7 Jahren durch JMC

Es liegt garnicht am aufteilen der Pakete, dass die cgi-bin dateien nicht gefunden werden. Ich habe gerade mal das "alte" startup-script genommen das beim download paket dabei ist. Das rc.dtmfbox aus dem download einmal ausgeführt (install und dann foreground) → Webinterface geht…

Jetzt muss man nur noch rausbekommen warum es dann auf einmal geht…

comment:29 Antwort: Geändert vor 7 Jahren durch JMC

ln -sf /bin/busybox /var/tmp/sh
Das war im alten rc.dtmfbox drin… hab den entsprechenden eintrag in den .cgi auf #!/bin/sh geändert - patch folgt später, muss langsam mal los ins Büro

Hat denn jemand ne Idee zu den Links die ich nach jedem reboot von hand anlegen muss?

comment:30 als Antwort auf: ↑ 28 Geändert vor 7 Jahren durch sf3978

Replying to JMC:

Es liegt garnicht am aufteilen der Pakete, dass die cgi-bin dateien nicht gefunden werden. Ich habe gerade mal das "alte" startup-script genommen das beim download paket dabei ist. Das rc.dtmfbox aus dem download einmal ausgeführt (install und dann foreground) → Webinterface geht…

Jetzt muss man nur noch rausbekommen warum es dann auf einmal geht…

Ist evtl. das "alte" startup-script ausführbar und das "neue" startup-script & Co., noch nicht ausführbar?

comment:31 als Antwort auf: ↑ 29 Geändert vor 7 Jahren durch sf3978

Replying to JMC:

Hat denn jemand ne Idee zu den Links die ich nach jedem reboot von hand anlegen muss?

Die Links kannst Du auch mit dem Paket (Ordner make/…) auf die Box installieren/flashen.

comment:32 Geändert vor 7 Jahren durch cuma

Ich glaube diese Links werden irgendwo von irgendeiner modlib* angelegt wenn irgendeine Bedingung zutrifft

comment:33 Geändert vor 7 Jahren durch buehmann

/usr/bin/modload ist der Ausgangspunkt; dort werden die meisten dieser Links für alle Pakete angelegt.

comment:34 Geändert vor 7 Jahren durch cuma

Ah genau. Die entsprechenden Dateien (cgis) müssen ausführbar sein

comment:35 Geändert vor 7 Jahren durch JMC

ausführbar ist alles… Ich häng jetzt mal meinen Patch an - nach aufrufen der Zeilen unten läuft das interface. Ich schaff es derzeit aber nicht eine laufende libmenu.plugin.so zu bekommen, mit meiner alten dtmfbox auf meinem usb-stick läufts aber ohne probleme.

Patch ist anbei, einzig die links fehlen noch damit das ganze automatisch abläuft…

cp /etc/default.dtmfbox-cgi/dtmfbox-cgi.cfg /mod/etc/conf/
ln -s /usr/mww-dtmfbox-cgi/cgi-bin/dtmfbox.cgi /var/mod/usr/lib/cgi-bin/dtmfbox-cgi.cgi
ln -s /etc/init.d/rc.dtmfbox-cgi /var/mod/etc/init.d/rc.dtmfbox-cgi
ln -s /etc/default.dtmfbox-cgi/ /mod/etc/default.dtmfbox-cgi
ln -s / /var/mod/pkg/dtmfbox-cgi
/etc/init.d/rc.dtmfbox-cgi

Geändert vor 7 Jahren durch JMC

dtmfbox-cgi patch new version

comment:36 Geändert vor 7 Jahren durch JMC

Was mir noch einfällt bzw auffällt:

man muss die DTMFBOX nach jedem reboot auch neuinstallieren, scheinbar fehlt irgendwo die Einstellung, dass er den letzten Pfad speichern soll. Den mechanismus das er es im startup script erkennt gibt es ja schon… ich such gerade wohin man sowas schreibt damit es beim booten geladen wird und probier mal mein glück… Bin für jeden Tip dankbar ;-)

comment:37 Antwort: Geändert vor 7 Jahren durch JMC

Zumindest bei den fehlenden Links bin ich etwas schlauer geworden…
das Problem ist wohl, dass das neue Paket dtmfbox-cgi nicht in static.pkg landet
das wird wohl beim bauen des Images gemacht in der fwmod mit

  for pkg in $(static_packages); do
[...]
( echo "$pkg_name" >> "${FILESYSTEM_MOD_DIR}/etc/static.pkg" )
[...}

Ich konnte aber keinen Hinweis darauf finden wie man ein Paket als static_package bekommt?

comment:38 Geändert vor 7 Jahren durch JMC

Sorry wenn ich doppelt poste…
Es war tatsächlich das +x - die sachen hatten zwar bei mir im test ein +x
ich hab aber nochmal neu ausgecheckt und meinen patch angewendet → kein +x bei den files.
Files mit +x versehen → webgui startet

Ich weiß nicht warum es nicht mit +x versehen wird, speichert der diff keine berechtigungen?

Wenn die dateien unter make entsprechend mit +x evrsehen sind startet alles automatisch und auch die einstellungen werden entsprechend gespeichert und alles

Könnte das mal jemand gegenchecken? Ich denke, dass alles so läuft (und wenn es eingecheckt ist kommen die dateien ja mit richtigen +x ausm trunk…)

comment:39 Geändert vor 6 Jahren durch buehmann

  • Beobachter buehmann hinzugefügt
  • Verantwortlicher buehmann gelöscht

Ich sehe, dass ich hier noch immer als Verantwortlicher eingetragen bin. Diese Verantwortung würde ich gerne abgeben, da ich dtmfbox nicht nutze. Bei Fragen zum Webinterface im Allgemeinen helfe ich natürlich gerne weiter.

comment:40 Geändert vor 6 Jahren durch JMC

Wie gesagt, einen kompletten lauffähigen patch habe/hatte ich ja - ich kann mir nur immer noch nicht erklären warum die Dateien im fertigen Image kein +x haben. Wenn Sie das haben läuft das ganze wieder…

Hab eben nochmal was rumprobiert mit meinem alten Trunk, habs aber immer noch nicht hinbekommen…

comment:41 Geändert vor 6 Jahren durch cuma

Nun, "chmod +x" sollte helfen. Meinst du oben den "dtmfbox-cgi_3.diff" mit dem dtmfbox wieder funktioniert? Man sieht bei diesem Patch schlecht die Änderungen, hast du das mit "svn move" gemacht? Welche Dateien brauchen da ein x?

comment:42 Geändert vor 6 Jahren durch JMC

Ja, der letzte diff war lauffähig. Richtig, chmod +x sollte helfen. Checke ich neu aus und füge danach den Patch hinzu haben die Dateien aber kein +x mehr… Kann man das nicht mit im diff speichern? Da ich mit dem svn selber nicht sooo vertraut bin hab ich nicht svn move genutzt. Wenn ich mich recht entsinne (hatte für die letzten Tests alles mit +x versehen - es ist ja auch schon ein paar Monate her) dann die .cgi und die .cfg damit es beim Image bauen entsprechend berücksichtigt wird und alles richtig eingebunden wird ins Image.

comment:43 Geändert vor 6 Jahren durch buehmann

Ja, Attributänderungen wie +x kann man nicht im Diff speichern (bzw. SVN schreibt das zwar als Hinweis raus, aber patch ist für so etwas nicht gemacht).

comment:44 Geändert vor 6 Jahren durch cuma

Ich check das mal so ein damit es hier weitergeht. Wird aber noch einiges an Arbeit sein, da einiges überflüssiges drin ist wie Abfrage ob mit Freetz installiert oder BusyBox. Den Syntax finde ich auch sehr seltsam.
@JMC: Kannst du das mal testen?

Man sieht übrigesn nicht überall das "kopiert von", das betrifft alle Dateien in make/dtmfbox-cgi/files/root/usr/mww-dtmfbox-cgi/cgi-bin/

Zuletzt geändert vor 6 Jahren von cuma (vorher) (Diff)

comment:45 Geändert vor 6 Jahren durch cuma

In [7076]:

dtmfbox-cgi: patch by JMC, small changes by me (refs #957)

comment:46 Geändert vor 6 Jahren durch JMC

So, da bin ich wieder. Hab eben nochmal fleissig rumprobiert, DTMFBOX taucht auch auf als Paket, ohne zusätzlichen Eintrag im freetzmenu.

Allerdings taucht dtmfbox-cgi nicht als startbares Paket auf in der Liste. Das ist das Problem das ich auch hatte - beim erstellen des Images wird dtmfbox-cgi nicht als Paket erkannt und dann irgendwelche Links nicht gesetzt…

Mit den Schritten aus Post 35 gehts - nur im Webinterface taucht dtmfbox-cgi nicht auf :(

Edit:
Nach den Schritten aus Post 35 taucht dtmfbox-cgi auch im Menü auf, dtmfbox ebenfalls mit dem Status von dtmfbox-cgi

Wenn nur diese Links erstellt werden würden…

Zuletzt geändert vor 6 Jahren von JMC (vorher) (Diff)

comment:47 Geändert vor 6 Jahren durch frankglaser

Zusätzlich zu den Schritten aus Post 35 habe ich versucht dtmfbox von hand zu starten:
rc.dtmfbox start
dann bekommt man den Fehler
dtmfbox not installed

Wenn man im script nachschaut, wann diese Meldung kommt, sieht man, dass dies bei der Prüfung des Ordners / Links:

/var/dtmfbox

geschieht.

Jetzt bleibt natürlich die Frage wo der hinzeigen muss und was dort drin sein sollte?

Getestet mit einer 7390 und dtmfbox aus dem trunk [8137]

comment:48 Geändert vor 6 Jahren durch JMC

Auf der 7390 funktioniert dtmfbox m.w. nach garnicht - zumindest auf meinen beiden boxen nicht.

Du musst neben den schritten aus #35 vor dem starten die dtmfbox erst übers webif konfigurieren

comment:49 Geändert vor 6 Jahren durch frankglaser

Übersetzt wurde dtmfbox schon mal ohne Fehler.
Das Binary liegt auch unter /usr/sbin/dtmfbox
Wenn ich das starte, bekomme ich den Fehler keine dtmfbox.cfg vorhanden.
Es wäre demnach zumindest schonmal ausführbar.

Mir ist gerade noch aufgefallen:
Das dtmfbox.cfg http://freetz.org/browser/trunk/make/dtmfbox/files/root/etc/default.dtmfbox/cfg/dtmfbox.cfg ist doch ein cfg file für dtmfbox aber nicht für das freetz package.
Hat das nicht ein völlig falsches Format, wenn ich mir zum Bsp das vom dtmfbox-cgi anschaue, das sollte stimmen: http://freetz.org/browser/trunk/make/dtmfbox-cgi/files/root/etc/default.dtmfbox-cgi/dtmfbox-cgi.cfg

Update:
Wenn ich dtmfbox mit dem Parameter -cfg starte:
dtmfbox -cfg etc/default.dtmfbox-cgi/dtmfbox-cgi.cfg
Dann nimmt er die cfg zwar an, aber ich bekomme 1280x die Meldung:
Found controller #x …
Dann wird die Box so langsam, das nur noch ein neustart hilft.
Was ja auch soweit logisch erscheint, die cfg stimmt nicht und dtmfbox versucht für jeden controller einen buffer anzulegen.

Zurück zum dtmfbox-cgi, durch die Posts von Comment 35 lässt sich das ja starten, aber fehlen dort nicht Einträge? Wenn ich das richtig verstehe sollte sich doch die gesamte dtmfbox Konfiguration über das freetz Menü dtmfbox erledigen lassen?

Auf Port 89 habe ich jetzt ein WebIf, das bietet aber keine Einstellmöglichkeiten.
Komisch finde ich aber das da steht dtmfbox v0.5.0 (USB), ich wollte es doch im internen Flash.

Zuletzt geändert vor 6 Jahren von frankglaser (vorher) (Diff)

comment:50 als Antwort auf: ↑ 22 Geändert vor 6 Jahren durch hm

Replying to JMC:

 09:19:57 Found controller #5 with 5 B-channel(s)
 09:19:57 CAPI registered (ApplID: 7, B-Channels: 12)
 09:19:57 Build a-law/pcm table buffer
 09:19:57 CAPI initialized!
 09:19:57 [plugin.menu] Loading /var/dtmfbox//menu.cfg ...
Segmentation fault
failed!
root@fritz:/var/media/ftp/uStor01/dtmfbox#
(gdb)
[...]
01:52:26    capi_ctrl.c CAPI initialized!
01:52:27      plugins.c [plugin.menu] Loading /var/dtmfbox//menu.cfg ...

Program received signal SIGSEGV, Segmentation fault.
0x2ab6531c in memcpy () from /lib/libc.so.0
(gdb) bt
#0  0x2ab6531c in memcpy () from /lib/libc.so.0
#1  0x00418aa8 in plugin_execute_cmd (argc=3) at plugins.c:126
#2  0x2aba8638 in read_menu () at menu.c:84
#3  0x2aba4d0c in plugin_init (cmd=<optimized out>) at menu.plugin.c:347
#4  0x00418ea8 in plugins_init () at plugins.c:59
#5  0x00403ca8 in main (argc=<optimized out>, arg=<optimized out>) at dtmfbox.c:230

Mit mipsel_gcc-4.5.3_uClibc-0.9.29 tritt dieser Fehler auf, wenn mit -Os optimiert wurde. Wenn man -O2 an CFLAGS in dtmfbox-0.5.0/plugins/menu.plugin/Makefile anfügt oder das vorkompilierte Plugin aus http://dtmfbox.v3v.de/dl/dtmfbox-0.5.0_mipsel.tar installiert, tritt der Fehler nicht mehr auf. Ebenso tritter er mit -Os nicht mehr auf, wenn die app_xxx Makros in dtmfbox-0.5.0/plugins/menu.plugin/menu.plugin.h wie folgt umdefiniert werden:

#if 0
    #define app_msg(x)  dtmfbox(2, "-log1", x)     // Logging
    #define app_err(x)  dtmfbox(2, "-log2", x)
    #define app_dbg(x)  dtmfbox(2, "-log3", x)
    #define app_dbg2(x) dtmfbox(2, "-log4", x)
    #define app_dbg3(x) dtmfbox(2, "-log5", x)
#else
    /* gcc-4.5.3 -Os bug? */

    int is_null(const void *ptr);
    // Logging
    #define app_msg(x)  { if (!is_null(dtmfbox)) dtmfbox(2, "-log1", x); }   
    #define app_err(x)  { if (!is_null(dtmfbox)) dtmfbox(2, "-log2", x); }
    #define app_dbg(x)  { if (!is_null(dtmfbox)) dtmfbox(2, "-log3", x); }
    #define app_dbg2(x) { if (!is_null(dtmfbox)) dtmfbox(2, "-log4", x); }
    #define app_dbg3(x) { if (!is_null(dtmfbox)) dtmfbox(2, "-log5", x); }
#endif

Die Funktion is_null() ist ein Einzeiler, der aber z.B. in dtmfbox-0.5.0/plugins/menu.plugin/funcs.c *extern* untergebracht werden *muss*:

int is_null(const void *ptr) { return ptr==NULL; }

Warum allerdings der Funktions-Zeiger "dtmfbox" überhaupt null sein sollte, ist damit natürlich nicht geklärt. Vielleicht kann mal jemand dtmfbox unter der Kontrolle von valgrind laufen lassen.

Zum -Os Problem selbst:
http://git.busybox.net/uClibc/commit/?id=82f8d0bce10403deab704871e638edc24e7933ee

Geändert vor 6 Jahren durch hm

Workaround für gcc-4.5.3 -Os Problem

Geändert vor 6 Jahren durch hm

Optional: Bereinigung von plugin_execute_cmd()

comment:51 Geändert vor 5 Jahren durch cuma

  • Meilenstein von freetz-1.2.1 nach freetz-1.3 geändert

Oder doch lieber gleich freetz-future…

comment:52 Geändert vor 5 Jahren durch er13

In 9466:

dtmfbox:

  • remove annoying trailing whitespaces added in r7076
  • refs #957

comment:53 Geändert vor 5 Jahren durch er13

In 9469:

pjproject:

  • add misiing REBUILD_SUBOPTS
  • refs #957

comment:54 Geändert vor 5 Jahren durch er13

In 9470:

dtmfbox:

  • revise .mk-file (autoconf/libtool fixes, missing REBUILD_SUBOPTS)
  • add missing dependencies
  • add (a bit reworked) patches by hm provided in #957
  • untested, i.e. feedback is highly appreciated
  • add libmenu.plugin.so.0.0.1 to the list of "external'ed" files
  • refs #957

comment:55 Antwort: Geändert vor 5 Jahren durch er13

In 9471:

dtmfbox:

  • change download site, the previous one is down
  • refs #957

comment:56 als Antwort auf: ↑ 55 ; Antwort: Geändert vor 5 Jahren durch Suchiman

Replying to er13:

  • change download site, the previous one is down

$(PKG)_SITE:=@SF/dtmfbox.berlios

Ich denke du hast das .de vergessen?

comment:57 Geändert vor 5 Jahren durch er13

In 9472:

pjproject:

  • revise .mk file

prjproject & dtmfbox:

  • use magic (C|LD)FLAGS to reduce package size
  • refs #957

comment:58 als Antwort auf: ↑ 56 ; Antwort: Geändert vor 5 Jahren durch er13

Replying to Suchiman:

Ich denke du hast das .de vergessen?

Welches .de? dtmfbox.berlios ist nur ein Pfad unter @SF, keine Adresse einer Website.

comment:59 als Antwort auf: ↑ 58 Geändert vor 5 Jahren durch Suchiman

Replying to er13:

dtmfbox.berlios ist nur ein Pfad unter @SF, keine Adresse einer Website.

Achso okay, tut mir leid. Habe mich nur gewundert weil es vorher ein ganzer Domain Name war und dann nur noch eine Adresse die ohne .de im Browser ungültig war.

comment:60 Geändert vor 5 Jahren durch JMC

Also gemäß ippf funktioniert es wohl auf einer 7270v3 im aktuellen Format - aber nur mit den Schritten aus Comment 35 - also mit dem +x - ich bekomm es nicht hin, dass die dateien ein +x haben und daher das Problem in Comment 37…

comment:61 Geändert vor 5 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-future geändert

Wie alles andere "unstable"

comment:62 als Antwort auf: ↑ 37 Geändert vor 5 Jahren durch hm

Replying to JMC:

Zumindest bei den fehlenden Links bin ich etwas schlauer geworden…
das Problem ist wohl, dass das neue Paket dtmfbox-cgi nicht in static.pkg landet
das wird wohl beim bauen des Images gemacht in der fwmod mit

  for pkg in $(static_packages); do
[...]
( echo "$pkg_name" >> "${FILESYSTEM_MOD_DIR}/etc/static.pkg" )
[...}

Ich konnte aber keinen Hinweis darauf finden wie man ein Paket als static_package bekommt?

Dieses Problem liegt in der Funktion pkg_name() in "trunk/tools/freetz_functions". Darin wird "-cgi" einfach per sed - Ausdruck abgeschnitten; pkg_name "dtmfbox-cgi-0.1" liefert dann nur "dtmfbox", was es bereits gibt. Mit einer entsprechend geänderten pkg_name() -Funktion enthält "trunk/build/modified/filesystem/etc/static.pkg" dann auch dtmfbox-cgi. Damit startet die FB sowohl dtmfbox als auch dtmfbox-cgi (auf Port 89), und zwar ohne die in Kommentar #27 als Workaround aufgeführten Befehle.


comment:63 Geändert vor 5 Jahren durch JMC

Würde denn eine Änderung des Namens in dtmfboxcgi reichen? Oder sollte die Funktion tatsächlich angepasst werden - das hätte wahrscheinlich Nachwirkungen in anderen Fällen, oder?

comment:64 Geändert vor 5 Jahren durch er13

In 9992:

dtmfbox:

  • select required busybox applets
  • refs #957, refs #1786

comment:65 Geändert vor 5 Jahren durch JMC

Hab als ganz dreckigen Umweg jetzt mal die Funktion angepasst (da ich auf Anhieb keinen Ausschluss beim sed hinbekommen habe) - aber nicht lachen! :)

pkg_name()
{
        local name=$1
        echo "$name" | sed -r -e 's/-(alpha|beta|rc|(un)?stable|.)[0-9]*$//i' -e 's/-[0-9a-f]{12}$//' -e 's/-[0-9][^-]*$//' -e 's/dtmfbox-cgi$/dtmfbox-cgi-cgi/' -e 's/-cgi$//'
}

Edit:
Damit ist das -cgi da und läuft auch - allerdings stürzt die 7390 nach einer Zeit ab wenn dtmfbox läuft. Das war aber glaub ich schon "immer" auf der 7390 so

Damit ist dtmfbox-cgi auch in der static.pkg drin. Nachher mal testen ob das ganze auch auf einer 7390 läuft

Zuletzt geändert vor 5 Jahren von JMC (vorher) (Diff)

Geändert vor 4 Jahren durch db1ras

Geändert vor 4 Jahren durch db1ras

Geändert vor 4 Jahren durch db1ras

comment:66 Geändert vor 4 Jahren durch db1ras

Ich habe mich die letzten Tage mit dtmfbox beschäftigt, da es für ältere Boxen weiterhin interessant ist und des Webinterface wieder in einen benutzbaren Zustand gebracht. Jedoch ohne einen weiteren Webserver zu starten, da dieser nur unnötig RAM auf der ohnehin knapp bemessenen Box belegt. Auf dem Freetz-Webinterface befindet sich nun ein Redirect zum dtmfbox-Webinterface.

Leider kann man in das System-Menü keinen Eintrag hinzufügen oder ich weiß nicht wie, denn dort wäre die Option IMHO besser aufgehoben gewesen, so wie die Redirects zur Rudi-Shell und dem AVM-Webinterface.

Änderungen im dtmfbox-Paket (Initscript) in der Reihenfolge ihres Auftretens im diff:

  • Abfrage der verfügbaren Busybox-Befehle für Freetz entfernt, da unnötig und müllt nur /var/log/mod.log zu
  • "/etc/init.d/rc.dtmfbox install ram" ohne Angabe eines Pfades funktioniert nun wie vorgesehen
  • Pfade zu espeak, madplay und checkmaild werden gesetzt wenn mitcompiliert
  • dtmfbox-cgi wird registriert, wenn mitcompiliert
  • Hilfe wird wie bei allen anderen Freetz-Initscripten nur noch bei Angabe einer ungültigen Option angezeigt, dies müllt dann auch nicht mehr /var/log/mod.log zu
  • Hilfe zeigt nun auch die verfügbaren Installationsmethoden an
  • dtmfbox wird nun beendet bevor es deinstalliert wird
  • Hilfe gibt nun das Initscript mit korrektem Pfad aus

Änderungen im dtmfbox-cgi-Paket (dtmfbox-Webinterface) in der Reihenfolge ihres Auftretens im diff:

  • der Freetz-Webserver wird nun wieder mitverwendet, Pfade entsprechend angepasst und unnötige Dateien entfernt
  • dtmfbox_webphone.cgi wird nun korrekt entfernt wenn ohne Webphone gebaut
  • Hilfe-Link wird aus dem Webmenü entfernt, wenn ohne Hilfe gebaut
  • Es wird nun "Installieren" anstatt "Pfad ändern" angezeigt, wenn noch keine Installation vorliegt

Zusätzlich zu den beiden diffs für das dtmfbox und dtmfbox-cgi-Paket hänge ich noch einen an welcher die verschobenen Dateien miteinander vergleicht. Letzterer dient nur zum besseren Vergleich und ist nicht dazu gedacht ihn direkt anzuwenden.

Damit funktioniert bei mir dtmfbox mit Webinterface nun wieder soweit wie zu Freetz 1.1.3-Zeiten. Ich habe auch die ganzen Stolpersteine bezüglich der Installation entfernt. Ich frage mich allerdings ob es so eine gute Idee war das Webinterface in ein eigenes Paket zu packen, da es die Routinen zum Speichern der Konfiguration enthält.

Ist es eigentlich gewünscht die ganzen Ausnahmen für nicht-Freetz-Systeme weiterhin in den Scripten zu belassen?

comment:67 Geändert vor 4 Jahren durch oliver

Ich wäre dafür die Ausnahmen zu entfernen, da diese die ganzen Skripte total unleserlich machen. Ich hatte mich vor einiger Zeit auch mal versucht, aber irgendwann aufgegeben.

comment:68 Geändert vor 4 Jahren durch cuma

Jup, die ganzen Dringe sind nur noch drin weil sie noch niemand rausgeworfen hat. Dies ist so weil irgendwann diese multi-installer Version in den Trunk kopiert wurde und sich noch niemand darum gekümmert hat. Alles in 1 Package zusammen zu legen fände ich auch ok.

comment:69 Geändert vor 4 Jahren durch er13

Das was db1ras gemacht hat, hört sich für mich nach einem Fork an. Ist der Aufwand es überhaupt wert, i.e. könnten wir es vielleicht doch einfach rausschmeissen?

Wenn wir uns doch fürs Beibehalten entscheiden, dann hätte ich nichts dagegen, dass wir uns nur um die Methode "installation in freetz" kümmern (i.e. alle anderen einfach entfernen). Es ist möglicherweise sogar sinnvoll (nachdem wir schon eine Kopie eines Teils des Codes aus dem original-tarball haben), den ganzen Quellcode an die entsprechenden Stellen unter files zu kopieren und alle Anpassungen nicht über Patches, sondern ganz normal über freetz-svn-repository einzupflegen. Dass der Autor von dtmfbox es irgendwann mal weiter entwickelt, glaube ich nicht mehr.

comment:70 Geändert vor 4 Jahren durch cuma

Es war ja die Idee es im Trunk aufzunehmen und alles unnötige rauszuwerfen. Wenn es noch benutzt wird und da sich jemand gefunden hat der dies anpassen möchte ist doch prima
Zu Erinnerung: Es funktionierte nicht mehr, da es Änderungen am Freetz-Webif von buehmann gab

comment:71 Geändert vor 4 Jahren durch cuma

In 11440:

dtmfbox: update by db1ras (refs #957)

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.