Callmonitor 1.*

buehmann · 4 Mai 2007

@ao: Einen Abgleich der Telefonbücher gibt es nicht. Probleme bereitet vor allem das Anlegen neuer Einträge im AVM-Telefonbuch. Bis jetzt kenne ich nur den Weg über das Webinterface, und darüber die nötigen Schritte/Seitenaufrufe zu simulieren, ist aufwendig und fehlerträchtig (und langsam).

Zu deinem Vorschlag, wie man an die Daten herankommen könnte: An die Dateien, die dort gesichert werden, heranzukommen, ist kein Problem. Das Problem ist, dass das Telefonbuch in einem Binärformat gespeichert ist, zu dem es weder eine Dokumentation noch eine öffentliche Zugriffsschnittstelle gibt.

@hermann72pb: Was meinst du mit "als üblich"? Ist schon bekannt, wie das generelle Format der Telefon-Konfigurationsdateien aussieht?

Bisher gab es keine Klagen über zu langsames Lesen. Ansonsten wäre die Infrastruktur für eine RAM-Kopie schon da: /tmp/callers macht ja im Prinzip genau das.

Andreas

hermann72pb · 4 Mai 2007

buehmann schrieb:
Probleme bereitet vor allem das Anlegen neuer Einträge im AVM-Telefonbuch.

Meiner Meinung nach müsste das auch nicht von callmonitor gemacht werden.
Einträge kann man per AVM-Interface anlegen.

buehmann schrieb:
Das Problem ist, dass das Telefonbuch in einem Binärformat gespeichert ist, zu dem es weder eine Dokumentation noch eine öffentliche Zugriffsschnittstelle gibt.

So komplett binär ist es nicht. Die Telefonnr. und der Name liegen als ASCII-Zeichenfolgen dar (hab ich ja gemeldet). Die Frage ist nur, ob die Position, wo die liegen irgendwie bekannt ist.

buehmann schrieb:
Was meinst du mit "als üblich"? Ist schon bekannt, wie das generelle Format der Telefon-Konfigurationsdateien aussieht?

Ich hatte angenommen, dass es bekannt ist. Ich glaube hier im Forum vor 1-1,5 Jahren eine Diskussion über die config-Dateien gesehen zu haben.
Ich vermute, dass die Daten in der config-Datei positionsorientiert sind. Ich schaue es bei einigen Boxen nach, ob sich die Vermutung reproduzieren lässt. Kann man es bei AVM-cgis nicht "abgucken", wie die Daten erzeugt/ausgelesen werden? Oder ist diese Geschichte in binaries versteckt?

MfG

buehmann · 4 Mai 2007

Ja, das steckt alles in Binaries (bzw. in Bibliotheken).

Einträge kann man per AVM-Interface anlegen.

Ja, über das Webinterface. Ich hab das vor einiger Zeit spaßeshalber mal ausprobiert, aber spaßig war das nicht (und sehr langsam).

Andreas

hermann72pb · 4 Mai 2007

Nein, du hast mich falsch verstanden, ich meinte, das macht der Benutzer innerhalb des AVM-Webinterfaces, nicht automatisch. Callmonitor greift ausschließlich lesend auf AVM-Telefonbuch. Ziel ist, dass man auf "Callers" unter ds-mod langfristig verzichten kann.
Ich hatte die besagte /var/flash/fx_conf bei mindestens 5-6 Boxen (7050,7170) mit unterschiedlichen Firmware-Varianten (ab etwa xx.100 bis xx.31) mit unterschiedlichen ds-mods (spielt hier eigentlich keine Rolle) untersucht. Meine Vermutung hat sich bestätigt. Es gibt zwei Fixbereiche in der Datei, wo nach einem bestimmten Raster zuerst die Telefonnummern und dann die Namen gespeichert werden. Ich poste hier (oder im Extra-Thread) noch genauere Daten dazu. Bei einer Box hatte ich noch die alte fx_conf vorfinden können. Danach hat AVM anscheinend das Telefonbuch geplant und die Datei etwas größer gemacht. Wobei die Telefonnummern sich noch im "alten" Bereich befinden und die Namen im erweiterten. Ich bin zwar kein richtiger Programmierer hier, aber es ist bestimmt möglich die Datei mit cat, grep oder/und awk Sequenzen sogar online zu verarbeiten. Es ist auf jeden Fall einfacher, als die Webinterface auszutriksen und die Sonderzeichen zu filtern.
Gefahr, dass AVM etwas ändert gibt es in beiden Fällen. Daher Suche im Telefonbuch auf jeden Fall abschaltbar machen.

MfG

buehmann · 4 Mai 2007

Ah, ja, ich habe dich falsch verstanden. Ich sehe es genauso, dass man momentan mit einem Lesen des Telefonbuchs auskommt. (Komplett auf die Callers zu verzichten, würde allerdings auch Schreibzugriff bedeuten, solange man das aktuelle Verhalten beibehalten will, dass Ergebnisse der Rückwärtssuche bei neuen Nummern dort abgelegt werden).

Zum Lesen aus dem Webinterface: Ich habe einen Weg gefunden, ohne das Austricksen von Sonderzeichen auszukommen (<? multiquerytext ?> und <? querytext ?> statt den Versionen ohne "text"; AVM verwendet das selbst z.B. beim Download der Anrufliste als CSV-Datei.)

Ich werde mal einen Blick in die fx_conf werfen, werde aber nicht allzu viel Zeit darin investieren. Falls du noch mehr über das Innenleben herausfindest, freue ich mich natürlich.

Andreas

buehmann · 5 Mai 2007

callmonitor-1.9.4

Wie angekündigt:

phonebook: Fehler bei Nutzung des FRITZ!Box-Telefonbuch behoben: Umlaute als Latin1; Wichtig-Flag (!) entfernt; letzte Zeile behalten

Andreas

hermann72pb · 5 Mai 2007

Zum Innenleben von fx_conf

Wie angekündigt poste ich hier die Ergebnisse meiner kleinen Untersuchung zum Thema "Wie speichert AVM das Telefonbuch in fx_conf". Obwohl Andreas das Problem schon anders gelöst hat, wird dieser etwas OT-Bericht hier vielleicht einen oder anderen interessieren.
[size=-2]
Untersuchte Boxen: 7050 und 7170, zusammen in etwa 5-7 Stück Firmwares: von 29.03.101 bis 14.04.31 Mods: von m4.28 bis ds26-14.4 (unerheblich)
[/size]
Die Datei fx_conf wird von AVM zum Speichern der Daten benutzt, die in einer oder anderer Form mit Telefon zu tun haben. Wenn man die Datei durchforscht, findet man dort z.B. Daten für VOIP-Accounts und andere Informationen, die uns hier nicht interessieren. Die Datei an sich ist binär und kann z.B. mit integriertem HEX-Viewer von mc direkt an der Box betrachtet werden. Die Datei enthält ASCII-Sequenzen, die an bestimmten Stellen (die fix zu sein scheinen, vielleicht kommt daher "fx" im Namen?) in der Datei im Klartext stehen.
Seit einer gewissen Zeit hat AVM entschieden, die Datei als Speicherort für das eigene Telefonbuch zu nutzen. Ab diesem Zeitpunkt wurde die Größe der Datei von etwa 11692 (2DACH) bis etwa auf 16812 (41ACH) Bytes erweitert.
Betreffend Telefonbuch gibt es in der Datei zwei Bereiche. Der erste Bereich beginnt bei der Adresse 1199H und endet in etwa bei 2ABBH (mit dem Ende bin ich nicht ganz sicher). Der zweite Bereich beginnt bei 2DC0H und endet bei 35DEH.
Im ersten Bereich werden die Telefonnummern samt Vorwahl gespeichert. AVM spendiert pro Telefonnummer satte 65 (41H) Bytes. Vermutungen: entweder ist es geplant später mehrere Telefonnummern pro Eintrag zu hinterlegen, oder es ist für VOIP-Einträge für Direktrufe angedacht. Die Telefonnummer steht als ASCII-Sequenz da. Leerstellen (nach der Nummer) sind mit 00H belegt.
Im zweiten Bereich sind dann die Namen gespeichert. Hier war AVM recht sparsam und spendierte nur 21 (15H) Bytes pro Name. Der leere Bereich ist ebenfalls mit 00H belegt.

Code:

[b]Telefonnummern[/b]               [b]Namen[/b]
...                          ...
1199H: Erste Tel. Nr.        2DC0H: Erster Name
11DAH: Zweite Tel. Nr.       2DD5H: Zweiter Name
121BH: Dritte Tel. Nr.       2DEAH: Dritter Name
...                          ...
2ABBH: Letzte Stelle der     35DEH: Letzte Stelle des
       letzten Tel. Nr.             letzten Namens

Ich hatte versucht die Datei mit cat, grep und cut zu verarbeiten, könnte allerdings nur wenig erreichen. Meiner Meinung nach ist solche Datenstruktur mehr für c-geschriebene Programme (mit fopen usw.) geeignet, als für Skriptsprache. Von daher ist dein Weg, Andreas, die AVM-eigene Binaries zu benutzen ist schon richtig.
MfG

kriegaex · 6 Mai 2007

OT, aber als Idee: Falls doch mal jemand C-nahe Sachen skripten will, wäre Lua evtl. einen Blick wert. Es ist als Mod-Paket verfügbar, aber ich habe wenig damit gemacht bisher. Es steht im Ruf, sehr gut mit C zu harmonieren.

buehmann · 17 Mai 2007

callmonitor-1.9.5

Hallo, viele Grüße an alle Väter!

Ein paar klitzekleine Änderungen in Version 1.9.5:

inverse.sh: Rückwärtssuche über inverssuche.de entfernt
phonebook.sh: Ortsvorwahl automatisch aus AVM-Konfiguration übernehmen (einzustellen unter Telefonie/Internettelefonie/Erweiterte Einstellungen)

Andreas

MaxMuster · 9 Jun 2007

Problem beim Start ohne Netzzugang?

Hallo,

ich bin gerade am Testen mit der neuen .33-er Version und bin dabei auf folgendes gestoßen: Beim "Hochfahren" war die Box über mehrere Minuten quasi nicht ansprechbar (vom WebIF bekam man höchstens eine Teil zu sehen, die DS-Mod Oberfläche gar nicht)
Nachdem ich schon dachte, die Box wegen Unerreichbarkeit recovern zu müssen, kam ich dann doch noch mal per Telnet drauf. Meist wurde ich ja gleich wieder rausekickt, aber manchmal konnte man auch ein ps absetzen. Dabei sah ich sehr viele Prozesse, die mit dem callmonitor verbunden zu scheinen:

Code:

/ $ ps
  PID  Uid     VmSize Stat Command
    1 root        236 S   init
    2 root            SWN [ksoftirqd/0]
    3 root            SW< [events/0]
    4 root            SW< [khelper]
    5 root            SW< [kthread]
    6 root            SW< [kblockd/0]
   23 root            SW< [pdflush]
   24 root            SW< [pdflush]
   26 root            SW< [aio/0]
   25 root            SW  [kswapd0]
   62 root            SW  [pm_info]
   69 root            SW  [mtdblockd]
   89 root            SW  [tffsd_mtd_0]
   91 root        236 S   init
   92 root        244 S   /bin/sh /etc/init.d/rc.S
  511 root            SW< [capi_oslib]
  512 root            SW< [capi_oslib]
  513 root            SW  [capitransp]
  547 root            Z N [ctlmgr]
  548 root       1032 R N ctlmgr
  554 root            Z   [websrv]
  555 root        716 S N websrv
  559 root            Z   [igdd]
  560 root        924 S   igdd
  562 root        716 S N websrv
  563 root        716 S N websrv
  564 root        716 S N websrv
  568 root            Z   [multid]
  569 root        888 S   multid
  576 root            Z   [dsld]
  577 root        960 S   dsld -i -n
  590 root        620 S   telefon a127.0.0.1
  594 root            Z   [voipd]
  595 root        980 S < voipd
  602 root        488 S   capiotcp_server -p5031 -m1
  605 root        144 S   /bin/run_clock -c /dev/tffs -d
  611 root        244 S   /bin/sh /etc/init.d/rc.S
  612 root        208 S   tee /var/log/mod.log
  615 root        924 S   igdd
  616 root        924 S   igdd
  617 root        924 S   igdd
  655 root            Z   [telnetd]
  656 root        224 S   telnetd -l /sbin/ar7login
  671 root        240 S   httpd -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r DS-MOD (user:admin)
  678 root        264 S   -sh
  869 root        216 S   ash /mod/pkg/callmonitor/usr/lib/callmonitor/sipnames
  875 root        216 S   ash /mod/pkg/callmonitor/usr/lib/callmonitor/sipnames
  876 root        364 S   /bin/ash /usr/bin/phonebook --local exists @
  870 root        272 S   /bin/ash /usr/bin/phonebook --local exists [email protected]
  947 root        272 S   /bin/ash /usr/bin/phonebook --local exists [email protected]
  948 root        356 S   /bin/ash /usr/bin/phonebook --local exists [email protected]
  949 root             /bin/ash /usr/bin/phonebook --local exists [email protected]
  950 root        272 S   /bin/ash /usr/bin/phonebook --local exists [email protected]
  954 root        228 S   dropbear -p 22
  958 root        296 S   /bin/sh /etc/init.d/rc.openvpn-lzo
  964 root             /bin/sh /etc/init.d/rc.openvpn-lzo
  967 root             /bin/sh /etc/init.d/rc.openvpn-lzo
  971 root        360 R   ps
  973 root        364 S   /bin/ash /usr/bin/phonebook --local exists @
  974 root        396 S   /bin/ash /usr/bin/phonebook --local exists @
  975 root        400 S   /bin/ash /usr/bin/phonebook --local exists @
  976 root        400 S   /bin/ash /usr/bin/phonebook --local exists @
  977 root        400 S   /bin/ash /usr/bin/phonebook --local exists @
  978 root             /bin/ash /usr/bin/phonebook --local exists @
  979 root             /bin/ash /usr/bin/phonebook --local exists @
  980 root        404 R   /bin/ash /usr/bin/phonebook --local exists @
  983 root             /bin/ash /usr/bin/phonebook --local exists @
/ $

Nach ca. 5 Minuten habe ich mal einen top hinbekommen:

Code:

Mem: 13252K used, 872K free, 0K shrd, 120K buff, 1544K cached
Load average: 2.83 0.69 0.23
  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
  920 root     R        112   919 28.3  0.7 allcfgconv
  911 root     R        124   910 18.5  0.8 allcfgconv
  939 root     R        360   670 15.9  2.5 top
  548 root     R N      812     1 13.2  5.7 ctlmgr
   69 root     SW         0     1  4.4  0.0 mtdblockd
  577 root     S        760     1  3.5  5.3 dsld
  590 root     S        636     1  0.8  4.5 telefon
  881 root     S        396   611  0.8  2.8 rc.dropbear-ssh
  595 root     S <      812     1  0.0  5.7 voipd
  560 root     S        708     1  0.0  5.0 igdd
  621 root     S        708   619  0.0  5.0 igdd
  619 root     S        708   560  0.0  5.0 igdd
  620 root     S        708   619  0.0  5.0 igdd
  569 root     S        664     1  0.0  4.7 multid
  555 root     S N      544     1  0.0  3.8 websrv
  564 root     S N      544   562  0.0  3.8 websrv
  562 root     S N      544   555  0.0  3.8 websrv
  563 root     S N      544   562  0.0  3.8 websrv
  670 root     S        460   656  0.0  3.2 sh
  869 root     S        444   868  0.0  3.1 phonebook
  875 root     S        444   874  0.0  3.1 phonebook
  899 root     S        444   894  0.0  3.1 phonebook
  904 root     S        444   903  0.0  3.1 phonebook
  889 root     S        444   869  0.0  3.1 phonebook
  903 root     S        444   889  0.0  3.1 phonebook
  894 root     S        444   875  0.0  3.1 phonebook
  900 root     S        444   899  0.0  3.1 phonebook
  602 root     S        432   548  0.0  3.0 capiotcp_server
  943 root     R        424   881  0.0  3.0 rc.dropbear-ssh
   92 root     S        416    91  0.0  2.9 rc.S
  611 root     S        416    92  0.0  2.9 rc.S
  868 root     S        384     1  0.0  2.7 ash
  874 root     S        384     1  0.0  2.7 ash
  914 root     S        380   901  0.0  2.6 cfg2sh
  923 root     S        380   905  0.0  2.6 cfg2sh
  905 root     S        376   904  0.0  2.6 cfg2sh
  901 root     S        376   900  0.0  2.6 cfg2sh
  912 root     S        376   901  0.0  2.6 cfg2sh
  921 root     S        376   905  0.0  2.6 cfg2sh
  910 root     S        376   901  0.0  2.6 cfg2sh
  919 root     S        376   905  0.0  2.6 cfg2sh
  924 root     S        320   923  0.0  2.2 sed
  931 root     S        320   914  0.0  2.2 sed
  679 root     S        320     1  0.0  2.2 httpd
  913 root     S        316   912  0.0  2.2 sed
  922 root     S        316   921  0.0  2.2 sed
  656 root     S        300     1  0.0  2.1 telnetd
/ $ Connection closed by foreign host.

Das ganze ist übrigens unabhängig davon, ob der callmonitor auf "automatisch" oder "manuell" beim Starten steht. Meine Vermutung: Es wird versucht, eine Rückwärtssuche zu initieren, die fehlschlägt, da die Box momentan keine Internetverbindung hat?

Falls es das wäre: könnte man das durch ein vorheriges Ping vielleicht unterdrücken?

Oder ist die "Kommunikation" mit dem AVM-Telefonbuch in der neuen Version inkompatibel, und alle andern haben das Problem auch?

Erst mit einem killall phonebook wird die Box normal erreichbar...

Wie gesagt, nur Vermutungen, aber da die Box so über viele Minuten fast "unbrauchbar" ist, wäre es vielleicht eine Überlegung wert...

Infos dazu:
ds26-14.4 auf Eumex300IP mit Firmware 6.04.33 (gerade am Testen),
callmonitor 1.9.5
dropbear 0.49
openvpn 2.1_rc2

Danke für ein paar Hinweise!

Jörg

buehmann · 9 Jun 2007

Hi,

danke für den Hinweis. Ist das ganze Verhalten bei dir reproduzierbar, tritt es also bei jedem Start auf?

Mit einer Rückwärtssuche kann es übrigens nichts zu tun haben; der Schalter "--local" bei phonebook verhindert diese gerade. Der Callmonitor (genauer das Skript "sipnames") versucht gerade, für jeden SIP-Account einen Standardeintrag im Telefonbuch (Callers) vorzunehmen, sofern noch keiner existiert. Was dabei seltsam ist, sind die vielen Auftreten der offensichtlich fehlerhaft ermittelten Adresse "@" ... Ich schaue morgen mal, ob mir in dieser Hinsicht etwas auffällt.

Andreas

MaxMuster · 9 Jun 2007

Hi,

ja, tritt bei jedem Starten auf, ich konnte nur durch geduldiges Probieren dazu kommen, die Tasks zu killen, damit die Box lief. Habe jetzt im Moment eine Version ohne Callmonitor laufen.

Klar ist, bei mir ist eine klassische "Testumgebung", die .33-er Firmware und dann auch noch auf einer dafür nicht ursprünglich vorgesehenen Hardware. Ich will da nicht ausschließen, dass da noch was anderes im Argen liegt, aber da auch an anderer Stelle im Telefon-Bereich kräftig geändert wurde (allein die Einstellung der Nebenstellen), könnte es natürlich auch eine grundsätzliche "Unpässlichkeit" der Version zur neuen FW sein...

Wenn ich was testen/nachschauen.... soll, immer gerne!

Danke!

Jörg

EDIT 20070610:
Heute noch ein wenig "gespielt": mit dem "Standard" im 14.4-er mod (callmonitor 1.9.2) habe ich die Probleme nicht. Der funktioniert auch, aber auch da habe ich ein "spannendes" Phänomen:
Ich habe nur zum Testen die Box an eine internen S0 meiner Telefonanlage und folgendes eingetragen:

Code:

in:request ^ ^103 dial 100 3

rufe ich nun die 103 an, und beende den Anruf, wird auch nach einiger Zeit die 100 gewählt. Das Phänomen: solange es "klingelt" ist alles gut, wenn ich aber den Ruf annehme oder abweise, stürzt die Box komplett ab und macht einen reboot. Das passiert aber nur wenn gleichzeitig openvpn läuft... Kannst du dir denken, in welcher Richtung man da suchen kann? Speicher? Versucht der Callmonitor was bestimmtes zu diesem Zeitpunkt, was vom "Netzwerkzustand" abhängig ist? Sehr mysteriös...

buehmann · 14 Jun 2007

MaxMuster schrieb:
Das Phänomen: solange es "klingelt" ist alles gut, wenn ich aber den Ruf annehme oder abweise, stürzt die Box komplett ab und macht einen reboot.

Hmm, wenn es schon klingelt, ist der Callmonitor aus dem Spiel (der ruft nur die Wählhilfe im Webinterface auf und ist dann fertig). Was dann schiefläuft, kann ich mir nicht erklären. Du könntest ja mal probieren, ob du den Absturz auch über manuelles Benutzen der Wählhilfe hinbekommst.

Andreas

MaxMuster · 14 Jun 2007

Hallo,

Mit dem WebIF geht das Wählen.

Zum Callmonitor 1.9.2:
Da muss ich mich leider korrigieren: Auch wenn ich nicht drangehe/ablehne passiert auch das gleiche: Nach einiger Zeit ein "Absturz".
Wenn ich annehme höre ich manchmal noch eine "gequälte" Stimme (verzerrt und einfach "schlechte Qualität"), mit "Ihre Verbindung wird gehalten" und dann ist "Schicht". Ohne Opnenvpn ist z.B. die Stimme "normal" und das ganze geht auch.
Wenn ich es richtig gesehen habe, war der allcfgconv auch wieder der Prozess mit maximaler CPU-Zeit. Tja, vielleicht ist die Box einfach Speichermäßig oder Prozessormäßig dann so am Ende, dass es nicht geht...

Ich schaue mal weiter, oder fällt dir noch was ein, wonach ich besonders schauen sollte?!?

Danke bis hierher!

Jörg

buehmann · 14 Jun 2007

Hi Jörg,

hmm, also immer wieder ein verklemmter "allcfgconv". Dieses Programm wird auch bei dial vom Callmonitor aufgerufen (um das Webpasswort rauszubekommen). Probier doch einfach mal, ob sich das mit OpenVPN zusammen prinzipiell aufhängt, wenn du es von Hand aufrufst (z.B. "allcfgconv -C ar7 -o - -c", um die ar7.cfg mit dekodierten Passwörtern zu erhalten).

Andreas

MaxMuster · 14 Jun 2007

Hallo,

Die PW-Abfrage läuft problemlos durch, in allen Varianten, auch die direkt vom Skript aufgerufene "sed-Variante"
allcfgconv -C ar7 -c -o - | sed -ne '/^webui[[:space:]]*{/,/^}/{/=/{s/[[:space:]]*=[[:space:]]*/=/;s/^[[:space:]]*//;p}}'
macht keine Probleme...

Das sieht mir immer mehr nach einem Last- oder Speicherproblem aus:
Wenn openvpn zwar läuft, aber keine Clients Verbunden ist, geht es scheinbar problemlos. Entweder liegt es dann an den Ressourcen, oder die zusätzlichen IP EInstellungen kommen dazwischen. Ich werde in der Richtung weiterforschen, kann jetzt aber eben nur ohne vpn-Verbindungen testen, und dann geht der callmonitor.

Im Moment kannst du dich also "zurücklehnen" ;-)

Jörg

EDIT: Zwischenstand 17.06.
Ich habe ein ds26-14.4 Image nur mit Callmonitor 1.9.5 und der .33-er Firmware gebaut, auch das läuft ohne Probleme. Die kleine Box hat ja nur 16MB, das ist das einzige Problem, das ich mir vorstellen kann. Eventuell (ich werde es mal testen) ist ja nur der "erste Durchlauf" mit den Einträgen ins Telefonbuch so aufwendig, dass es zu den Problemen beim Start kam und jetzt, nachdem das mal durch ist, geht es auch in der anderen Konstellation...
Fazit: Der Callmonitor funktioniert, die Probleme im Zusammenspiel mit anderer Software sind vielleicht noch "untersuchenswert".
Sorry für den "Fehlalarm".

Tobstar · 22 Jun 2007

ID übertragung

Hallo,

ich schreibe gerade meine Anrufliste im Internet um. Dabei möchte ich auch die Variable ID an meine Webseite übergeben. Mit allen anderen Variablen geht es wunderbar. Ich habe mich jetzt schon fast um den Verstand geprüft.
Bei mir kommt keine ID an. Kann die Ursache in der Box liegen?
Listener:

Code:

in:request ^ ^ getmsg www.meinserver.de '/in.php?id=%s&caller=%s&callerl=%s&name=%s&line=%s&key=%s&status=%s&id=%s&dauer=%s' "$ID" "$SOURCE_DISP" "$SOURCE" "$SOURCE_NAME" "$PROVIDER" "12" "in-request" "$ID" "$DURATION"

Und hier die php Seite, die das Ganze in SQL Schreibt:

PHP:

$db = mysql_connect($server, $benutzer, $kennwort);
$sqlab = "insert anrufe";
$sqlab .= "(  caller,  callerl,  name,   uhr, datum, timestamp, status, line, dauer, id, request ) values ";
$sqlab .= "('$caller', '$caller', '$name', '$uhr', '$datum', '$timestamp', '$status','$line', '$dauer', '$id', '$timestamp' )";
mysql_db_query("$database", $sqlab);
mysql_close($db);

Aber generell sollte die ID überagen werden,oder gibt es das seit irgendeiner Version nicht mehr?

kriegaex · 22 Jun 2007

Nicht, daß ich Dir helfen könnte, aber ein Code-Schnipsel wäre schon hilfreich für die anderen Leute hier.

MaxMuster · 22 Jun 2007

@buehmann
Mein "Problem" mit dem Callmonitor 1.9.5 auf der Eumex 300IP mit 04.33-er Firmware und openvpn kann nun wohl komplett als "erledigt" betrachtet werden. Die massive Last, die die phonebook-Aufrufe erzeugt hatten waren durch meine "Platzsparwut" hervorgerufen:
Ich Blödmann hatte in der Busybox hexdump abgewählt, das scheinen die Aufrufe etwas krumm zu nehmen, wie man sieht, wenn man die Aufrufe von Hand macht...
~~Mit korrigierter Busybox ist der "erste Anlauf", bei dem der Callmonitor die ganzen Aufrufe tätigt deutlich kürzer, und die Box reagiert dann wieder "normal".~~

EDIT 2: 22.6.07 - 19:40 Leider ist der Erfolg nur selten, häufig wird die Box sogar vom Watchdog neu gestartet. Wenn man per Telnet draufkommt, sind im top immer allcfgconf und sed die "Spitzenreiter" und es gibt sehr viele identische phonebook Prozesse. Ich muss mir vielleicht doch die Abfrage mal genauer ansehen, irgendwo scheint die noch ins Nirwana zu gehen.
Kann ich vielleicht irgendetwas noch vergessen haben, muss etwas bestimmtes zwingend konfiguriert/eingetragen (Vorwahl, ...) sein, damit der erste Start des callmonitors funktioniert?...

EDIT: Aber vielleicht kannst du mir ja noch sagen, warum überhaupt diese ganzen phonebook-Aufrufe stattfinden, auch wenn der callmonitor nicht gestartet wird? Kann man das noch unterbinden?

Die Tests mit laufenden Openvpn-Verbindungen stehen noch aus, mal sehen ob ich dieses Wochenende endlich dazu komme...

Jörg

buehmann · 23 Jun 2007

@Tobstar: ID existiert als Variable. Aber warum baust du die zweimal als "id=$ID" in die URL ein. Ich weiß nicht, was PHP daraus macht, aber ich kenne andere Sprachen, die dann die mehrfachen Werte in ein Array packen. Liegt es vielleicht daran?

@MaxMuster: Hallo Jörg, die ganzen phonebook-Aufrufe stammen aus dem Skript 'sipnames' (ermittelt Namen für SIP-Account und trägt die ins Telefonbuch ein), das wiederum in "phonebook init" aufgerufen wird; das wird wiederum beim Initialisieren des Callmonitor-Pakets durch "rc.callmonitor" (ohne Argument oder mit "load") aufgerufen.

Andreas

Callmonitor 1.*

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Neuer User

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

Statistik des Forums