[Gelöst] Calllog und Wake-on-Call ab AVM 6.20

[Bonvie]

Hallo an alle,
dank neuer Box mit aktueller Firmware habe ich das Problem, das die debug.cfg von früher nicht mehr funktioniert. :-(
Die beiden Scripte die ich ausführen möchte sind nach wie vor:
1.) Wake-on-Call
2.) Automatischer Neustart am Sonntag

Dank PeterPawn und sein Script habe ich debug.cfg (jetzt rc.user) wieder aktiviert und der automatische Neustart am Sonntag funktioniert schon mal wieder. Aber leider hat AVM auch am calllog etwas geändert und ruft diesen nicht mehr auf. In diesem Post "Bei Anruf script auslösen" erwähnt PeterPawn eine zweite Möglichkeit ein eigenes Script mit 'nc' auf localhost:1012 lauschen lassen.

Wer hat dazu weitere Informationen oder hat sogar schon mal ein ähnliches Script mit Wake-on-Call angepasst?
Das Callmonitor-Package auf Freetz möchte ich erstmal nicht benutzen.

Danke und Gruß
Bonvie

Edit: Lösung findet ihr unten im Post #18

 

[PeterPawn]

[EDIT]
Ab Version 06.23 für 7490 hat AVM das nc-Applet nicht mehr in der Busybox, vermutlich auch in anderen Modellen bei künftigen Versionen nicht mehr. Man benötigt also noch irgendein Programm, was auf einem TCP-Port Daten entgegennehmen und auf STDOUT ausgeben kann. Das kann eine andere Busybox mit nc-Applet sein, ein einzelnes Kommando wie GNU netcat mit der passenden Architektur für den Prozessor der Box oder auch socat. Je nachdem, was man nimmt, muß man den Aufruf in Zeile 44 etwas anpassen. Beim socat ist es z.B. möglich, das Programm auch ohne STDIN zu starten, damit ist dort die Redirection von /dev/console unnötig und sollte unterbleiben.
[/EDIT]

Ich habe mal auf die Schnelle aus ein paar Versatzstücken etwas gebastelt, was definitiv noch nicht optimal ist, aber erst einmal seinen Zweck erfüllen sollte.

Einmal als CODE (für ein paar Bemerkungen) und einmal als Anhang:Anhang anzeigen 79651

01 #! /bin/sh
02 runcmd="/bin/sh /var/media/ftp/callmonitor_action"
03 host=localhost
04 port=1012
05 #
06 # some helpers
07 #
08 unique_id()
09 {
10 	local len=${1:-8}
11 	[ $len -gt 32 ] && return 1
12 	dd if=/dev/urandom of=/proc/self/fd/1 count=1 bs=16 2>/dev/null | md5sum | sed -n -e "s/\([0-9a-f]\{$len\}\).*/\1/p"
13 	return 0
14 }
15 #
16 # convert callmonitor date value to linux time for easier handling
17 #
18 datevalue()
19 {
20 	local dd mm yy hh mi ss
21 	dd=${1:0:2}
22 	mm=${1:3:2}
23 	yy=${1:6:2}
24 	hh=${1:9:2}
25 	mi=${1:12:2}
26 	ss=${1:15:2}
27 	echo $(date +%s "20$yy-$mm-$dd $hh:$mi:$ss")
28 }
29 #
30 myname=${0##*/}
31 myname=${myname%%.*}
32 pidfile=/var/run/${myname}.pid
33 mypid=$$
34 echo -n $mypid >$pidfile
35 #
36 # let's begin
37 #
38 rc=0
39 OIFS="${IFS}"
40 #
41 # - our main loop will be terminated at EOF from 'nc' (after switching AVM's callmonitor to 'off' - #96*4* - which may be one reason, if the script terminates immediately) or killed from outside
42 # - killing the telefon daemon while restarting the system should terminate 'nc' too, simply due to the closed socket afterwards
43 #
44 nc $host $port </dev/console | 
45 while read line; do
46 	echo $line
47 	unset time action connection internal outgoing called caller duration
48 	IFS=";"
49 	set -- $line
50 	IFS="${OIFS}"
51 	time=$(datevalue "$1")
52 	action=$2
53 	connection=$3
54 	case $action in
55 		CALL)
56 			internal=$4
57 			outgoing=$5
58 			called=$6
59 			;;
60 		RING)
61 			caller=$4
62 			called=$5
63 			;;
64 		CONNECT)
65 			internal=$4
66 			called=$5
67 			;;
68 		DISCONNECT)
69 			duration=$4
70 			;;
71 		*)
72 			echo "unknown callmonitor action : $action in '$line'" 1>&2
73 			continue
74 			;;
75 	esac
76 	delay -d 0 $(unique_id) $runcmd TIME=$time ACTION=$action CONNECTION=$connection INTERNAL=$internal OUTGOING=$outgoing CALLED=$called CALLER=$caller DURATION=$duration
77 done
78 rm $pidfile 2>/dev/null
79 exit $rc

Ein Problem, was etwas Zeit zum Testen benötigte, war das Abbrechen von 'nc', wenn STDIN ein EOF liefert (was bei einem "detached"-Aufruf immer der Fall ist), daher in Zeile 44 die Redirection von /dev/console, die ansonsten keinen weiteren Zweck erfüllt.

Um das Skript bei aufeinanderfolgenden Ausgaben des AVM-Callmonitors nicht zu lange zu beschäftigen, wird nur die Zeile geparsed und anschließend mit den aus der Zeile gewonnenen Daten das in Zeile 2 konfigurierte Kommando aufgerufen. Die Parameter für diesen Aufruf stehen in Zeile 76.

Die Wandlung der Uhrzeit in einen Linux-Zeitstempel ist nur der Tatsache geschuldet, daß ich lieber damit hantiere, weil dann der Unterschied zwischen den Ländereinstellungen (deutsches vs. amerikanisches Format) keine Rolle mehr spielt.

Normalerweise müßte das Script beim Beenden des telefon-Daemons im Rahmen des Herunterfahrens/Neustarts der Box automatisch beendet werden, da das 'nc' auf das Schließen des Callmonitor-Sockets mit einem Fehler reagieren sollte. Wenn man es irgendwie selbst abschießen will, findet man die PID des ersten Aufrufs in der Datei "/var/run/<scriptname>.pid".

Das ist alles noch lange nicht optimal, insbesondere das Beenden des Scripts "von außen" könnte noch etwas sinnvoller gestaltet werden.

Das "Auseinanderpflücken" der verschiedenen Nachrichten des CallMonitors und den Aufruf passsender Kommandos bei bestimmten Ereignissen kann man genauso gut in dem in Zeile 2 konfigurierten Kommando ausführen; das in den "Listener" mit einzubauen, fand ich persönlich jetzt übertrieben.

Außerdem stört es in dieser Form auch nicht, wenn ein Aufruf mal etwas länger benötigt ... es geht keine Nachricht wirklich verloren, allerdings sollte das Kommando auch damit umgehen können, wenn da keine serielle Verarbeitung stattfindet (es kann z.B. ein DISCONNECT-Aufruf eher "beendet" sein, als der zugehörige "RING"- oder "CALL"-Aufruf - je nachdem, wie aufwendig man da arbeitet und wie schnell der Anruf beendet war bzw. wie schnell ein eingehender Call abgebrochen wurde). Wem das nicht paßt, der muß sich selbst um die Serialisierung mit einer Semaphore o.ä. kümmern.

Ich habe mich bemüht, mich auf die "out of the box" verfügbaren Busybox-Applets zu beschränken, aber nur auf 7490 getestet. Die Applets variieren bei AVM manchmal von Modell zu Modell und von Version zu Version ... wenn es daher Probleme geben sollte, muß man nach einem Workaround für ein fehlendes Applet suchen.

Der Start des Ganzen kann aus der debug.cfg z.B. mit einer Zeile "delay -d 5 CMONITOR /bin/sh <scriptname>" erfolgen. Beim Start über "nohup" oder über "&" in einer Shell-Zeile riskiert man immer den Abbruch des Scripts, wenn der Parent-Prozess beendet wird ... deshalb empfehle ich den Start auf diese Art und Weise; es geht aber sicherlich auch noch auf vielen anderen Wegen. Es ist eben alles nur ein Beispiel, wie man es machen kann ...

 

[koyaanisqatsi]

Dankeschön.

Zu erwähnen wäre noch, dass das Skript...
/var/media/ftp/callmonitor_action
...erstellt werden, und die Ausgabe von...
callmonitor.sh
...auswerten muss.

Minimal dieses hier...
/var/media/ftp/callmonitor_action

#!/bin/sh
echo $@
#EOF

Ausgabe:

29.12.14 19:02:50;RING;0;017XXXXXXX27;68XXXXX3;SIP9;
29.12.14 19:02:58;DISCONNECT;0;0;

Ich werde es längere Zeit testen, in einer tmux Konsole.

 

[PeterPawn]

Ausgabe:

Ok, die Ausgabe ist mehr ein "Unfall" ... das "echo" in Zeile 46 ist eigentlich blödsinnig und nur vom Debuggen übrig geblieben.

Der Aufruf des in Zeile 2 festgelegten Kommandos erfolgt ja mit key/value-Paaren für die Parameter, das ist imho (nach einem passenden "eval $*" im Script) ziemlich einfach auszuwerten und man muß keine Rücksicht mehr auf die Unterschiede zwischen den Callmonitor-Nachrichten nehmen, da die ja schon nivelliert wurden im case-Statement in der Schleife.

 

[koyaanisqatsi]

OK, Zeile 46 ist kommentiert.
Aber du hast mich erwischt, denn ich hab keine Ahnung wie ich mit eval irgendetwas machen kann.
...bitte um ein "working example".

 

[PeterPawn]

#! /bin/sh
# shebang oben ist eigentlich umsonst, wenn man mit /bin/sh aufruft (wie in meinem Beispiel-"callmonitor.sh") und bringt auch nur dann etwas, wenn das Script selbst "exceutable" ist
#
# we have key/value pairs in our parameter list and it's a good idea to let the shell interpret the assignments
eval "$*"
#
# output the values to a file, because we're running detached and there's no possibility to show something on a terminal (as far as we don't want to write to /dev/console)
#
echo "time=$(date @$TIME)" >>/var/tmp/callmonitor.log
echo "action=$ACTION" >>/var/tmp/callmonitor.log
echo "connID=$CONNECTION" >>/var/tmp/callmonitor.log
echo "internal number=$INTERNAL" >>/var/tmp/callmonitor.log
echo "outgoing number=$OUTGOING" >>/var/tmp/callmonitor.log
echo "called number=$CALLED" >>/var/tmp/callmonitor.log
echo "calling number=$CALLER" >>/var/tmp/callmonitor.log
echo "call duration=$DURATION" >>/var/tmp/callmonitor.log
#
# try to find an incoming call to a reserved number to implement a "wake on call" function
#
# calling number
wakefrom=015112345678
# called number
waketo=03012345678
# device to wake up on call
wakemac=11:22:33:44:55:66
#
# check values
if [ x"$ACTION" == x"RING" -a x"$CALLER" == x"$wakefrom" -a x"$CALLED" == x"$waketo" ]; then
#       we have three matches, that should be enough to start the specified device
        ether-wake -b -i lan $wakemac
        echo "waking up device $wakemac due to call from $CALLER to $CALLED" >>/var/tmp/callmonitor.log
        logger -t CallMon "Waking up device $wakemac due to call from $CALLER to $CALLED"
fi

Nicht mehr auf existierende Applets beschränkt, ether-wake und logger sind i.d.R. bei AVM nicht dabei. Erster Teil (Schreiben ins Logfile) ist getestet, zweiter Teil ist Theorie, aber außer Schreibfehlern kann man nicht so viel falsch machen.

BTW:
Bei der Anzeige der letzten Anrufe für SaS würde ich an Eurer Stelle aber auf die AVM-Anrufliste gesamt zurückgreifen und nicht auf eine gesondert geführte Liste ... jedenfalls dann, wenn da nicht alle 10 Sekunden die Liste abgefragt wird.
Ich schreibe in Kürze mal etwas im "Modifikationen"-Unterforum zur Verwendung der Kommandozeile zum Abfragen von Firmware-Variablen (über das Lua-Variableninterface), die nicht unbedingt alle über ctlmgr_ctl zugänglich sind (das sind die, die mit "non-emu" zurückkommen) und über eine ziemlich simple Möglichkeit über Listen solcher Variablen zu iterieren. Imho wäre das der bessere Weg, um an die Infos über die letzten Anrufe zu gelangen, dafür würde ich nicht den Callmonitor einspannen.

 

[Bonvie]

Erstmal vielen Dank für deine Mühen PeterPawn und das berücksichtigen des Hilferufes.
Das sieht auf jeden Fall nicht danach aus, als hätte ich das jemals hinbekommen und ich muss mir das ganze erst nochmal genau anschauen.

Leider, scheint das Wake-On-Lan per Anruf nicht mehr so leicht zu sein, wie noch mit der Version 06.05.
Danke und Gruß
Bonvie

 

[koyaanisqatsi]

Gediegen, vielen Dank.

...und juten Rutsch

 

[steviehs]

Hmm... kann es sein, dass nc - zumindest bei der 6.23 nicht mehr dabei ist? Und nu?

 

[koyaanisqatsi]

Moin

Zum Glück sind wir im "Modifikationen" Thread.

Das würde der Aufruf von busybox ohne Parameter zeigen.
Kannst aber eine vollwertige busybox auf die Box bringen (interner Speicher oder USB).
MIPS und MIPSEL Versionen gibt es nach wie vor hier: busybox.net

 

[PeterPawn]

Hmm... kann es sein, dass nc - zumindest bei der 6.23 nicht mehr dabei ist? Und nu?

Tatsächlich ... da der Austausch der Busybox immer die erste Aktion ist bei neuer Firmware, ist mir das noch gar nicht aufgefallen.

Wer jetzt aber der Meinung ist, AVM wäre hingegangen und hätte die Liste der eingebundenen Busybox-Applets einer kritischen Bewertung nach dem Aschenputtel-Prinzip unterzogen, der findet in dieser Liste (AVM-Busybox in 113.06.23):

        [, [[, arp, arping, ash, basename, brctl, bunzip2, bzcat, bzip2, cat, chgrp, chmod, chown, chroot, cmp, cp, cut, date, dd, df, dirname, dmesg, dnsdomainname, du, echo, egrep, env, ether-wake, expr,
        false, fgconsole, fgrep, find, flock, free, ftpget, ftpput, getopt, grep, groups, gunzip, gzip, halt, hostname, id, ifconfig, ifdown, ifup, inetd, init, insmod, iostat, ip, ipaddr, iplink, iproute,
        iprule, iptunnel, kill, killall, killall5, ln, login, logname, ls, lsmod, lsof, md5sum, mkdir, mkfifo, mknod, mkswap, modprobe, more, mount, mpstat, mv, nbd-client, netstat, nice, nohup, nslookup,
        passwd, pidof, ping, ping6, pivot_root, pmap, poweroff, printenv, printf, ps, pstree, pwd, pwdx, readlink, realpath, reboot, renice, reset, rm, rmdir, rmmod, route, sed, seq, setconsole, setserial, sh,
        sleep, smemcap, sort, stat, stty, swapoff, swapon, switch_root, sync, sysctl, tail, tar, tee, telnetd, test, tftp, time, top, touch, tr, traceroute, true, tty, ubimkvol, ubirmvol, ubirsvol,
        ubiupdatevol, umount, uname, uniq, unxz, unzip, uptime, vconfig, vi, wc, wget, whois, xargs, xz, xzcat, zcat

sicherlich auch noch genug Applets, die ebenfalls vollkommen überflüssig sind.

So hoffnungsvoll man z.B. auf die ubifs-Tools blicken mag, es fehlt schon der Kernel-Support (einkompiliert oder als Module) für dieses Filesystem. Auch andere Applets werden in der AVM-Firmware einfach nicht benutzt, wie ein simples grep leicht offenbart.

Also hat man wohl bei AVM das Vorhandensein von "nc" als weitere Sicherheitslücke entlarvt ... prinzipiell nicht einmal vollkommen falsch, aber wenn man einfach per weiterhin vorhandenem wget (auch wegen des fehlenden Rechtekonzepts) eine eigene Busybox nachladen kann, hat das nur zweifelhaften Wert in meinen Augen.

Natürlich ist jede geschlossene Lücke für sich auch ein Fortschritt, dann darf man aber auch nicht ständig an anderen Stellen Konzessionen machen, die solche Aktionen einfach nur peinlich aussehen lassen. Theoretisch wird nicht einmal 'vi' im Image benötigt (zumindest kenne ich keine Stelle in der Firmware, wo damit gescripted wird, wäre bei vorhandenem sed ja auch weniger sinnvoll), von diversen Beigaben außerhalb der Busybox ganz zu schweigen.

Als "Lösung" muß man dann - neben dem Shell-Script selbst - eben auch noch eine weitere Busybox auf die eigene Box bringen und die entweder gleich richtig integrieren (z.B. mit modfs, wenn die Box unterstützt wird) oder entsprechende Aufrufe im Script-Code anpassen. Bei der Busybox muß nicht zwingend der Aufruf über einen passenden Symlink erfolgen, ein Aufruf der Form "/var/media/ftp/busybox nc ..." funktioniert auch, wenn man die eigene Busybox auf /var/media/ftp abgelegt und ausführbar gemacht hat.

 

[steviehs]

ok, vielen Dank für den Support, jetzt läuft es rund:

Zutaten um es noch mal zusammenzufassen:

* script(e) von oben
* busybox (siehe oben)
* call zur busybox im script anpassen
* Nicht vergessen: mit #96*5* den log freischalten
* Auf dieser Basis (auch hier nochmal Dank, Peter) http://www.ip-phone-forum.de/showthread.php?t=273304&page=2 das script persistent starten

Wohlfühlen

Vielen Dank an das Forum und den Peter im speziellen!

 

[Bonvie]

So nun habe ich endlich Zeit gefunden um mich mal etwas "tiefer" damit zu befassen und stelle fest, dass mein Knowhow nicht wirklich reicht. Sorry

- Ich habe die Scripte von oben angepasst
- Mit Peters modfs Script die debug.cfg „aktiviert“
- In der debug.cfg mit edit_rcuser und „delay -d 5 CMONITOR /bin/sh /var/media/ftp/callmonitor“ verankert

Leider erhalte ich beim Aufruf folgenden Fehler:

 /var/media/ftp/callmonitor: line 80: nc: not found

Deswegen meine Fragen:
1.) Wie bindet man die busybox ein bzw lädt man das Kommando "nc" auf die Box?
2.) Müssen die Scripte dann nochmal angepasst werden?
3.) Warum muss mit #96*5* der CallMonitor eingeschaltet werden, ich dachte den gibt es nicht mehr?

Danke und Gruß
Bonvie

 

[steviehs]

Also, die Busybox holst du dir wie oben von koyaanisqatsi beschrieben und legst sie entweder als "busybox" in /var/media/ftp oder benennst sie in nc um und legst sie so nach /var/media/ftp. Danach musst du eben den Pfad wie Peter Pawn beschrieben hat anpassen also statt nur nc eben /var/media/ftp/nc (wenn du busybox umbenannt hast).
Naja und ohne das #96*5* kommt eben aus dem port nix raus... kannste ja mit nc probieren...

 

[Bonvie]

Danke steviehs,
es hat geklappt ich habe soeben das erstmal wieder den Rechner geweckt.

Eine Frage habe ich aber noch
Wie sieht das "if" aus, wenn ich mehrere Nummern den WakeOnCall ermöglichen will.

if [ x"$ACTION" == x"RING" -a x"$CALLER" == x"$wakefrom01" -a x"$CALLED" == x"$waketo" ]; then

Ich möchte gerne noch ein wakefrom02 oder verknüpft einbauen.

 

[steviehs]

einfach die caller_action ein wenig aufbohren (hier z.B. mit drei Nummern):

#! /bin/sh
#
# we have key/value pairs in our parameter list and it's a good idea to let the shell interpret the assignments
eval "$*"
#
# try to find an incoming call to a reserved number to implement a "wake on call" function
#
# calling numbers
wakefrom1=01234567890
wakefrom2=01234567890
wakefrom3=01234567890
# called number
waketo=12345678
# device to wake up on call
wakemac=00:00:00:00:00:00
#
# check values
if [ x"$ACTION" == x"RING" -a x"$CALLED" == x"$waketo" ]; then
        echo -n "$(date @$TIME): $ACTION on $CALLED:" >>/var/tmp/callmonitor.log
        if [ x"$CALLER" == x"$wakefrom1" -o x"$CALLER" == x"$wakefrom2" -o x"$CALLER" == x"$wakefrom3" ]; then
#       we have three matches, that should be enough to start the specified device
                ether-wake -b -i lan $wakemac
                echo " waking up device $wakemac due to call from $CALLER" >>/var/tmp/callmonitor.log
        else
                echo " unknown caller: $CALLER" >>/var/tmp/callmonitor.log
        fi
fi

ah, als action hab ich übrigens "RING" genommen, muss ja keiner abnehmen

Gruss
Steve

 

[PeterPawn]

ah, als action hab ich übrigens "RING" genommen, muss ja keiner abnehmen

Stimmt auffallend ... war eben nur eine "Trockenübung" mit dem Kommando-Script.

Die "CALL"-Action wird nur bei ausgehenden Anrufen erzeugt (beim Annehmen kommt "CONNECT"), das ist bestimmt nicht das, was man machen will bei WakeOnCall.

Ich ändere das aber oben auch mal, sonst wundert sich vielleicht ein anderer Nachnutzer.

 

[Bonvie]

Funktionierende und erfolgreich getestete Lösung

Es läuft und ich möchte hier als Dankeschön für die Helfer meine Konfiguration als Anleitung aufzeigen.

Voraussetzung ist eine 7490 mit dem AVM Version ab 06.20, bei mir aktuell 6.23.
1.) Reaktivierung der debug.cfg mit dem Script von Peter.
2.) Per Telefon mit #96*5* den CallMonitor einschalten.
3.) Die aktuelle busybox herunterladen und hier ablegen: /var/media/ftp/busybox-mips
4.) Die Scripte von Peter aus diesem Thread leicht personalisiert ebenfalls hier ablegen.

/var/media/ftp/callmonitor

#! /bin/sh
runcmd="/bin/sh /var/media/ftp/callmonitor_action"
host=localhost
port=1012
#
# some helpers
#
unique_id()
{
  local len=${1:-8}
  [ $len -gt 32 ] && return 1
  dd if=/dev/urandom of=/proc/self/fd/1 count=1 bs=16 2>/dev/null | md5sum | sed -n -e "s/\([0-9a-f]\{$len\}\).*/\1/p"
  return 0
}
#
# convert callmonitor date value to linux time for easier handling
#
datevalue()
{
  local dd mm yy hh mi ss
  dd=${1:0:2}
  mm=${1:3:2}
  yy=${1:6:2}
  hh=${1:9:2}
  mi=${1:12:2}
  ss=${1:15:2}
  echo $(date +%s "20$yy-$mm-$dd $hh:$mi:$ss")
}
#
myname=${0##*/}
myname=${myname%%.*}
pidfile=/var/run/${myname}.pid
mypid=$$
echo -n $mypid >$pidfile
#
# let's begin
#
rc=0
OIFS="${IFS}"
#
# - our main loop will be terminated at EOF from 'nc' (after switching AVM's callmonitor to 'off' - #96*4* - which may be one reason, if the script terminates immediately) or killed from outside
# - killing the telefon daemon while restarting the system should terminate 'nc' too, simply due to the closed socket afterwards
#
##infinite loop
while :; do
  echo $mypid >>/var/tmp/callmonitor.log
  /var/media/ftp/busybox-mips nc $host $port </dev/console |
  while read line; do
  # echo $line >>/var/tmp/callmonitor.log
    unset time action connection internal outgoing called caller duration
    IFS=";"
    set -- $line
    IFS="${OIFS}"
    time=$(datevalue "$1")
    action=$2
    connection=$3
    case $action in
      CALL)
        internal=$4
        outgoing=$5
        called=$6
        ;;
      RING)
        caller=$4
        called=$5
        ;;
      CONNECT)
        internal=$4
        called=$5
        ;;
      DISCONNECT)
        duration=$4
        ;;
      *)
        echo "unknown callmonitor action : $action in '$line'" 1>&2
        continue
        ;;
    esac
    delay -d 0 $(unique_id) $runcmd TIME=$time ACTION=$action CONNECTION=$connection INTERNAL=$internal OUTGOING=$outgoing CALLED=$called CALLER=$caller DURATION=$duration
  done
  echo "$(date +"%d.%m.%Y %T")  infinite loops, start nc again" >>/var/tmp/callmonitor.log
  sleep 300
done
rm $pidfile 2>/dev/null
exit $rc

/var/media/ftp/callmonitor_action

#! /bin/sh
# shebang oben ist eigentlich umsonst, wenn man mit /bin/sh aufruft (wie in meinem Beispiel-"callmonitor.sh") und bringt auch nur dann etwas, wenn das Script selbst "exceutable" ist
#
# we have key/value pairs in our parameter list and it's a good idea to let the shell interpret the assignments
eval "$*"
#
# output the values to a file, because we're running detached and there's no possibility to show something on a terminal (as far as we don't want to write to /dev/console)
#
#echo "time=$(date @$TIME)" >>/var/tmp/callmonitor.log
#echo "action=$ACTION" >>/var/tmp/callmonitor.log
#echo "connID=$CONNECTION" >>/var/tmp/callmonitor.log
#echo "internal number=$INTERNAL" >>/var/tmp/callmonitor.log
#echo "outgoing number=$OUTGOING" >>/var/tmp/callmonitor.log
#echo "called number=$CALLED" >>/var/tmp/callmonitor.log
#echo "calling number=$CALLER" >>/var/tmp/callmonitor.log
#echo "call duration=$DURATION" >>/var/tmp/callmonitor.log
#
# try to find an incoming call to a reserved number to implement a "wake on call" function
#
# calling number MIT Vorwahl
wakefrom01=01512345678
wakefrom02=03012345678
wakefrom03=01522345678

# called number OHNE Vorwahl
waketo=1234457

# device to wake up on call
wakemac=00:01:02:03:04:05

# check values
if [ x"$ACTION" == x"RING" -a x"$CALLED" == x"$waketo" ]; then
  echo -n "$(date +'%d.%m.%Y  %T' @$TIME)  $ACTION on $CALLED:" >>/var/tmp/callmonitor.log
  if [ x"$CALLER" == x"$wakefrom01" -o x"$CALLER" == x"$wakefrom02" -o x"$CALLER" == x"$wakefrom03" ]; then
#   we have three matches, that should be enough to start the specified device
    /var/media/ftp/busybox-mips ether-wake -b -i lan $wakemac
    echo " send WOL to $wakemac due call from $CALLER" >>/var/tmp/callmonitor.log
# else
#   echo " unknown caller: $CALLER" >>/var/tmp/callmonitor.log
  fi
fi

5.) In der aktivierten debug.cfg mit edit_rcuser den "delay -d 5 CMONITOR /bin/sh /var/media/ftp/callmonitor" verankern.

######################
# wake-on-call START #
######################
# /var/media/ftp/callmonitor_action
# /var/tmp/callmonitor.log

delay -d 5 CMONITOR /bin/sh /var/media/ftp/callmonitor

#####################
# wake-on-call ENDE #
#####################

6.) Zur Kontrolle einfach mal das Kommando "delay -d 5 CMONITOR /bin/sh /var/media/ftp/callmonitor" ausführen und prüfen ob Fehler angezeigt werden.

7.) Wenn alles fehlerfrei gelaufen ist mit dem Kommando "reboot" die Box einmal durchstarten. Fertig

Nochmal ein großes Danke an alle Helfer, alleine hätte ich das definitiv nicht geschafft.

Edit2:

Da die Firmware 6.50 kein binary mehr für ether-wake mitbringt, verwende ich jetzt das der busybox-mips.
Auch hier wieder Danke Peter für den helfenden Hinweis.​

Edit1:

Habe das Script angepasst um die Stabilität oder Lebensdauer zu verbessern.
Nun wird es in einer Endlosschleife geführt und startet so mit einer Verzögerung von 5 Minuten neu wenn der 'telefon'-Daemon z.B. kurz neu gestartet wird.
Auch hier wieder Danke Peter für die Hilfe.​

 

[Semenchkare]

Hallo,

ich habs genauso wie in Beitrag #18 gemacht, nur klappt irgend was nicht. Ich finde keine callmonitor.log und kann nur erkennen, dass die busybox wohl läuft, denn manuell kann ich mit ether-wake den Rechner starten. Kann mir noch jemand Hinweise geben, wie ich sehe ob mit der callmonitor (in der ich letztlich nur die Telefonnummern änderte) oder der callmonitor_action was nicht stimmt??
@Bonvie: ich gehe davon aus, dass Deine anzurufende (called) number eine VOIP von 1und1 ist??
in meinem früheren script musste ich immer angeben damit der WOC funktionierte: called=SIP2#01512345678

Kann ich sehen, ob die Callmonitor-Dateien laufen bzw. ein Fehler vorliegt? in der Debug.cfg habe ich die Start-Zeile schon drin. Ein erneuter Aufruf brachte gestern die Box zum Reboot...

LG

Seme

 

[PeterPawn]

Kann ich sehen, ob die Callmonitor-Dateien laufen bzw. ein Fehler vorliegt?

Wenn das Listener-Script arbeitet, findet sich die nc-Instanz (nc localhost 1012) in der Ausgabe von "ps w" auf der Telnet-Shell wieder.

Ansonsten ist der Aufruf von Hand mit "sh -x scriptfilename" auch ganz hilfreich, um bis zum Aufruf von "callmonitor_action" zu kommen. Wenn da noch kein Fehler zu sehen ist, einfach den Aufruf von callmonitor_action um ein "sh -x" und eine Umleitung von stderr in eine Datei in /var ergänzen, dann hat man auch die Debug-Ausgabe von callmonitor_action.