Hörer abheben -> Aktion ODER check per script ob Hörer abgehoben ?

[buehmann]

Wie könnte man diese Funktion integrieren, bzw wie bekommt man ein GNU grep auf die Box ?

Hi, wie wäre es als Alternative, wenn du das grep an der Stelle weglässt und das "von Hand" erledigst?

dtrace ... | while read -r line; do
  case $line in
     *"Calling party number: 0#1234567"*) ... ;;
  esac
done

Andreas

 

[level20peon]

Neue Optionen kommen nicht davon in die Busybox, daß man hier schreibt, daß man sie vermißt. Do kannst einen entsprechenden Patch an Busybox schicken und schauen, ob er aufgenommen wird.

Das ist mir bewusst. Für einen Patch habe ich nicht genug Ahnung der Materie, das scheidet für mich also aus.

Um GNU grep aufzunehmen, muß man es nur übersetzen. Aber oben hast Du schon geschrieben, daß es Dir zu groß ist.

Im Moment habe ich wieder knapp 200KB frei, das könnte eventuell passen. Aber auch hier weiß ich nicht wie das funktioniert. Ich kann hier im Forum und auf der Freetz.org Seite auch kein Tutorial finden, wie man bei einer Übersetzung vorgehen würde. Aber trotzdem, vielen Dank für die Hinweise

Hi, wie wäre es als Alternative, wenn du das grep an der Stelle weglässt und das "von Hand" erledigst?

dtrace ...

Andreas

Das funktioniert leider nicht in "Echtzeit". Die Ausgabe erfolgt erst, nachdem die $line mehrfach auftaucht. Nachdem ich also den Hörer mehrmals abgehoben habe werden alle vorhergehenden Ereignisse überhaupt erst ausgegeben.

 

[RalfFriedl]

Ich kann hier im Forum und auf der Freetz.org Seite auch kein Tutorial finden, wie man bei einer Übersetzung vorgehen würde.

Es gibt bei Freetz durchaus eine Seite über die Erstellung eigener Pakete.

 

[buehmann]

Das funktioniert leider nicht in "Echtzeit". Die Ausgabe erfolgt erst, nachdem die $line mehrfach auftaucht.

Dann dürfte die Ausgabe von dtrace gepuffert sein, so dass du auf der Leserseite immer dieses Problem haben wirst.

 

[WLAN-VoIP-Fan]

Hi,

gibt es denn schon Vortschritte?

Gruß.

 

[level20peon]

Hallo,

nein, es gibt keine Fortschritte. Da es softwareseitig scheinbar unmöglich ist das Ganze umzusetzen wüsste ich auch nicht, was ich nun noch ausprobieren könnte.

 

[pumbo]

Auch wenn der Thread schon etwas älter ist... Vielleicht interessiert's ja noch den ein oder anderen.

Ich hatte genau das gleiche Problem mit line-buffered und habe einen Ansatz, wie man es lösen kann.

Hintergrund: Nur dann, wenn die Ausgabe eines Befehls direkt auf ein tty (also dorthin, wo man "was sieht", z. B. ein Terminal) geleitet wird, erfolgt die sichtbare Ausgabe ungepuffert, das heißt, man sieht sie sofort.

Wird die Ausgabe auf allerdings irgendetwas anderes außer einem tty umgeleitet, puffert der Linux-Kernel 4 KB an Daten. Jedes vernünftige Programm ruft daher regelmäßig fflush() auf, damit wird der Puffer geleert und tatsächlich weitergeleitet. Das macht dtrace aber nicht.

Es gibt in Linux jedoch auch Pseudo-TTYs. Sie verhalten sich wie normale TTYs, können aber von beiden Enden per Software angesprochen werden. Sie finden sich immer in Paaren (Master und Slave). Z. B. ist /dev/ttyp0 ein Master und /dev/ptyp0 ein Slave. Alles, was man nun in den Master oder Slave reinschreibt, kommt auf der anderen Seite (Slave oder Master) wieder heraus. Die Kommunikation erfolgt grundsätzlich ungepuffert.

Somit funktioniert folgendes Konstrukt:

Einerseits:
# dtrace -* -s > /dev/ttyp0

Andererseits:
# grep "irgendwas" /dev/ptyp0

Das endgültige "Telefonklingeln-bei-Türklingeln"-Skript ist noch nicht fertig, dürfte aber erstmal machbar sein.

 

[level20peon]

dtrace -c5 -s > /dev/ttyp0

ergibt bei mir

-sh: can't create /dev/ttyp0: Input/output error

 

[RalfFriedl]

puffert der Linux-Kernel 4 KB an Daten.

Das stimmt so nicht, die C Library macht das.

Jedes vernünftige Programm ruft daher regelmäßig fflush() auf

Das kommt auf die Definition von "vernünftig" an. Es gibt schließlich einen Grund, warum in der Library ein Puffer implementiert wird. Dass es für diesen Einsatzzweck ungünstig st heißt noch nicht, dass es generell falsch ist.

 

[pumbo]

@level20peon

Hmm, gestern hat's noch funktioniert. Es scheint aber zu gehen, wenn man ptyp0 und ttyp0 vertauscht.

 

[level20peon]

Ich habe nun mal gnu-grep für die Fritzbox gebaut und es damit getestet. Leider wird immer noch gebuffered, wenngleich auch nicht so viel. Dann habe ich gelesen, dass pcregrep multiline pattern matching unterstützt und es mal damit ausprobiert, weil ich dachte, dass eventuell die schiere Anzahl an Zeilen bei der dtrace Ausgabe ein Problem darstellen könnte. Leider funktioniert es hiermit auch nicht besser, denn wenn man "--line-buffered" bei pcregrep aktiviert, deaktiviert dies automatisch die multiline Funktionalität und man ist am Ende wieder bei der gnu-grep Funktionalität angelangt.

 

[pumbo]

Falls es noch interessiert: Bei mir funktioniert es jetzt seit einiger Zeit. Meine Konfiguration: An Fon2 hängt das Klingelrelais. Wenn die Klingel betätigt wird, schaltet das Relais durch, dadurch wird Fon2 abgehoben. Fon2 habe ich eine imaginäre Internetrufnummer zugeordnet, dadurch kommen die Aktivitäten bei dtrace raus. Bei entsprechender Aktivität wird per AT-Kommando Fon1 angerufen.

Problem 1: Die Pufferung der Ausgabe von dtrace habe ich mit Umleitung über Pseudo-TTYs unterdrückt. Dadurch habe ich nun zwei Skripte - eins startet dtrace und leitet die Ausgabe um und das zweite wertet das Pseudo-TTY aus.

Problem 2: Um per AT-Kommando einen Call auslösen zu können, muss offenbar ein entsprechender Fon-Port frei sein. Wenn aber gerade geklingelt wird, ist ja Fon2 belegt und kann für den Anruf auf Fon1 nicht benutzt werden. Zum Glück antwortet die Box auf die AT-Kommandos mit "ERROR", wenn's der Anruf nicht erfolgen konnte. Sollte es dazu kommen, probiere ich es einfach eine Sekunde später nochmal. Das führt dazu, dass der Anruf nicht sofort ausgelöst wird, wenn auch die Klingel betätigt wird, sondern erst, wenn die Klingel wieder losgelassen wurde (wenn Fon wieder frei ist).

Problem 3: Wenn dtrace keinen stdin mehr hat, hört es auf zu funktionieren bzw. beendet sich. Es dauerte eine Weile, bis ich das herausgefunden hatte. Daher versorge ich dtrace mit einem "leeren" stdin - einem weiteren Pseudo-TTY.

klingeldtrace.sh:

#!/bin/sh
TTY=4
TTY2=5
dtrace -c5 -s > /dev/ttyp${TTY} < /dev/ptyp${TTY2} 2>/var/tmp/klingeldtrace.out

klingel.sh:

#!/bin/sh
TTY=4

old=0
cat /dev/ptyp${TTY} | while read -r line
do
        case ${line} in
        # die imaginäre Internetnummer
        *"587125897"*)
        	new=$(date +%s)
        	let diff=$new-$old
                # mindestens 15 Sekunden Abstand zwischen Calls
        	[[ $diff -lt 15 ]] && continue
        	old=$new
                # warten, bis frei
        	while echo "ATP2 ATD**9" | nc 127.0.0.1 1011 | grep ERROR ; do sleep 1 ; done
        	sleep 5
        	while echo "ATP2 ATH0" | nc 127.0.0.1 1011 | grep ERROR ; do sleep 1 ; done
        ;;
        esac
done

 

[level20peon]

Das wirft bei mir wieder den input/output error aus. Welche ttyp$ und ptyp$ ports existieren denn in deiner Box ? Ich benutze eine 7390, weshalb die Aufstellung eventuell abweicht.

 

[pumbo]

Bei meiner Box existieren ttyp/ptyp 0-9.

Ich kenne mich mit Pseudo-TTYs nicht aus. Ich habe nur festgestellt: Wenn man ein ttyp/ptyp-Paar das erste Mal benutzt, scheint es so, als würde man damit die Richtung definieren. Ist aber nur eine Theorie, vielleicht kann das jemand genauer sagen. Auf jeden Fall habe ich es schon mehrmals geschafft, die TTYs zu "verkonfigurieren" - sodass sie dann gar nicht mehr funktionierten. Dann traten auch die IO-Error auf. Reboote die Box doch mal und gucke, ob dann folgende Startsequenz funktioniert (Auszug aus meiner debug.cfg):

cd /var/tmp
nohup sh ./klingel.sh > klingel.sh.out 2>&1 &
sleep 5
nohup sh ./klingeldtrace.sh > klingeldtrace.sh.out 2>&1 &

Also sprich, erst die lesende Seite starten (klingel.sh) und erst dann die schreibende (klingeldtrace.sh).

 

[level20peon]

Das funktioniert... wie soll man denn annehmen, dass zuerst die lesende Seite gestartet werden muss. Danke für den Hinweis !

Gibt es denn einen Grund, warum du ttyp4 und ptyp5 gewählt hast ?

Es wär natürlich super, wenn uns jemand über das Prinzip dahinter aufklären könnte !

 

[pumbo]

Gibt es denn einen Grund, warum du ttyp4 und ptyp5 gewählt hast ?

Nun, nein
Hab nur gedacht, vielleicht ist es nicht so klug, gleich ttyp0 zu nehmen, vielleicht benutzt ja noch irgendein anderer Teil der Box-Firmware oder ein Freetz-Programm auch ein Pseudo-TTY...