Callmonitor -> DBox (Enigma) problem

[geiercasi]

es liegt also am call monitor. gut zu wissen.
danke für dein testen.

gruß

 

[buehmann]

Hallo zusammen,

ich lese jetzt hier mit. Mir ist allerdings noch nicht ganz klar, was genau wer von euch mit welcher Revision von Freetz getestet hat.

Die letzte Aussage von wengi bezüglich der Anführungszeichen verwirrt mich total. Das würde bedeuten, dass mit der Shell in der Busybox etwas nicht mehr stimmt.

Also: Mit welcher Revision vom Trunk zeigt sich der Fehler, mit welcher (noch) nicht? Welche (vollständigen) Kommandozeilen/Listener-Einträge/etc. sind nötig, um den Fehler zu reproduzieren?

Viele Grüße,

Andreas

 

[geiercasi]

von mir getestet unter freetz-devel-2645
seit wann das problem auftritt ist mir unbekannt, der cm ist erst seit gestern hier eingerichtet worden...
sorry für die aussage, der callmonitor sei schuld. er scheint ja nur der auslöser zu sein

zum reproduzieren:

funktioniert nicht
i:re ^ ^ DREAM_TIMEOUT=3 dreammessage root:[email protected] "${SOURCE_DISP} ruft an.${LF}${SOURCE_NAME}"
funktioniert
i:re ^ ^ DREAM_TIMEOUT=4 dreammessage root:[email protected] ${DEST}${SOURCE_NAME}
i:re ^ ^ DREAM_TIMEOUT=4 dreammessage root:[email protected] "Test"

 

[buehmann]

Was genau heißt "funktioniert nicht"?

 

[wengi]

hi buehmann,

Mit trunk 2604 hat alles noch funktioniert wie es soll.
Mit trunk 2647 tritt das Problem auf.

Es sieht tatsächlich so aus, als würde die busybox den Teil in den Anführungszeichen falsch interpretieren.

"${SOURCE_DISP}${SOURCE_NAME}" funktioniert NICHT
Anscheinend werden die Variablen falsch interpretiert...
Nicht funktionieren bedeutet in diesem Fall, dass eine leere Messagebox ohne Text auf dem Fernseher auftaucht.
Reproduzierbar, indem man den aktuellen Trunk flashed und dreammessage wie gewohnt einsetzt. Ich konnte bis jetzt noch keine wirklich funktionierende Variante finden.

${SOURCE_DISP}${SOURCE_NAME} funktioniert
Ohne Anführungszeichen funktioniert es mit einer oder mehreren Variablen, wobei die Variablen am Stück sein müssen, da sonst ja nur die erste angezeigt wird.

"Dies ist ein Test." funktioniert
Das verwirrt dann ganz. Es scheint also nur die Variablen zu betreffen.

wengi

 

[buehmann]

Danke, gilt das nur innerhalb der Listeners oder auch auf der Kommandozeile mit callaction? (Habe nämlich gerade r2647 geflasht und kann mit "callaction dreammessage ..." keine Auffälligkeiten feststellen.)

Andreas

PS: Was ist bei Mischung von Variablen und festem Text? Auch leere Anzeige oder nur der Text? Also soetwas: "bla ${SOURCE} blupp ${DEST} bla"

 

[geiercasi]

in:request ^ ^ dreammessage <ip>
funktioniert übrigens auch nicht.
i:re ^ ^ DREAM_TIMEOUT=4 dreammessage root:[email protected] "bla ${SOURCE} blupp ${DEST} bla"
auch nicht

comandozeile funktioniert

${DEST}${SOURCE_NAME} funktioniert.
${SOURCE_NAME}${DEST} nicht. auchnicht im freetztest

 

[buehmann]

Könnt ihr bitte folgendes machen: Auf der Konsole das hier starten (einen kleinen Pseudo-Webserver):

while true; do nc -l -p 8080; done

Die dreammessages dann bitte nach 127.0.0.1:8080 schicken. Mich würde die Ausgabe in den verschiedenen Fällen interessieren.

Andreas

PS: OK, ich konnte es reproduzieren; aus den Listeners aufgerufen ist die Nachricht, die nach draußen geschickt wird, leer:

GET /cgi-bin/xmessage?timeout=4&caption=Telefonanruf&charset=latin1&icon=1&body= HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3
Authorization: Basic cm9vdDpkYm94

 

[geiercasi]

in:request ^ (801780|Casi) dboxmessage root:[email protected]:8085
testanruf:
GET /control/message?nmsg=Anruf%20an%20801780%0avon%2017652167066%0aCasi%20%5bmobile%5d HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3
Authorization: Basic cm9vdDpkYm94Mg==
realer anruf:
GET /control/message?nmsg= HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3
Authorization: Basic cm9vdDpkYm94Mg==

in:request ^ (801780|Casi) dboxmessage root:[email protected]:8085
i:re ^ ^ DREAM_TIMEOUT=3 dreammessage root:[email protected]:8085 "${SOURCE_DISP} ruft an.${LF}${SOURCE_NAME}"
testanruf:
GET /cgi-bin/xmessage?timeout=3&caption=Telefonanruf&charset=latin1&icon=1&body=17652167066%20ruft%20an.%0aCasi%20%5bmobile%5d HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3
Authorization: Basic cm9vdDpkYm94
realanruf
GET /cgi-bin/xmessage?timeout=3&caption=Telefonanruf&charset=latin1&icon=1&body= HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3
Authorization: Basic cm9vdDpkYm94

i:re ^ ^ DREAM_TIMEOUT=3 dreammessage root:[email protected]:8085 "${SOURCE_DISP}"
testanruf:
GET /cgi-bin/xmessage?timeout=3&caption=Telefonanruf&charset=latin1&icon=1&body=17652167066 HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3
Authorization: Basic cm9vdDpkYm94
realanruf:
GET /cgi-bin/xmessage?timeout=3&caption=Telefonanruf&charset=latin1&icon=1&body=17652167066 HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3
Authorization: Basic cm9vdDpkYm94


gruß

 

[buehmann]

Echt mysteriös ... Vor allem, dass im dritten Fall beim echten Anruf wieder eine Anzeige kam.

Andreas

 

[wengi]

ich habs auf port 8081 gemacht:

/var/mod/root # while true; do nc -l -p 8081; done
GET /cgi-bin/xmessage?timeout=3&caption=Telefonanruf&charset=latin1&icon=1&body= HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3

[00698200]DSP: XDU=1( S1 ) OVR=0 MIPS_OVR=0
[00699200]DSP: XDU=2( S1 ) OVR=0 MIPS_OVR=0

/var/mod/root #

Der Eintrag in der Listerners war:

DREAM_TIMEOUT=3 dreammessage 127.0.0.1:8081 "${SOURCE_DISP} ruft an.${LF}${SOURCE_NAME}"

Listener geändert auf

DREAM_TIMEOUT=3 dreammessage 127.0.0.1:8081 ${SOURCE_DISP}${SOURCE_NAME}

und es kommt:

/var/mod/root # while true; do nc -l -p 8081; done
GET /cgi-bin/xmessage?timeout=3&caption=Telefonanruf&charset=latin1&icon=1&body=0163XXXXXXXWengi HTTP/1.0
Host: 127.0.0.1
User-Agent: callmonitor/1.12.3

[00717309]DSP: XDU=1( S1 ) OVR=0 MIPS_OVR=0

/var/mod/root #

 

[buehmann]

Ich habe das Problem eingegrenzt. Könntet ihr bitte einmal schauen, ob das bei euch reproduzierbar ist:

echo -n "AAAAAAAAAA" | hexdump -v -e '/1 "!%02x"' | nc localhost 8080

Aus den Listeners aufgerufen liefert es "!41*", auf der Kommandozeile aufgerufen "!41!41!41!41!41!41!41!41!41!41".

Andreas

 

[wengi]

/var/mod/root # while true; do nc -l -p 8081; done
!41!41!41!41!41!41!41!41!41!41
/var/mod/root # while true; do nc -l -p 8081; done
[00826224]DSP: XDU=1( S1 ) OVR=0 MIPS_OVR=0
[00832447]DSP: XDU=1( DTE ) OVR=0 MIPS_OVR=0
[00833447]DSP: XDU=1( S1 ) OVR=0 MIPS_OVR=0
[00834447]DSP: XDU=1( S1 ) OVR=0 MIPS_OVR=0
/var/mod/root #

Das erste war über Kommandozeile. Ist also bestätigt.
Allerdings kam über die Listener gar nichts. War ein Realanruf.
Müssten da noch Klammern drum?

i:re ^ ^ echo -n "AAAAAAAAAA" | hexdump -v -e '/1 "!%02x"' | nc localhost 8081

wengi

 

[buehmann]

Gar nichts? Jetzt wird's immer interessanter. Alles deutet für mich auf einen höchst seltsamen Bug in der Busybox hin.

Ich habe jetzt keine Zeit mehr, mir das genauer anzusehen; das mache ich später.

Gruß,
Andreas

PS: Hattest du beim Aufruf über die Listener auch den "nc -l -p 8081" laufen?

 

[geiercasi]

auf der box:
!41!41!41!41!41!41!41!41!41!41

in listeners
testanruf:
!41!41!41!41!41!41!41!41!41!41
realanruf:
nichts

 

[Tomekk1985m]

Hallo Leute,

wollte nur mal sagen dass es sich bei mir um die svn revision 2638 handelt.

MfG

 

[buehmann]

realanruf:
nichts

Guten Morgen, wirklich nichts? (Ich will es kaum glauben.) Also weiter eingrenzen: Was ist, wenn du den Teil

| hexdump -v -e '/1 "!%02x"'

in der Mitte entfernst?

Andreas

 

[wengi]

Folgende Listener-Zeile:

i:re ^ ^ echo -n "AAAAAAAAAA" | nc localhost 8081

Das Ergebnis:

/var/mod/root # while true; do nc -l -p 8081; done
AAAAAAAAAA
/var/mod/root #

Vorher kam bei einem realanruf nichts. (siehe weiter oben).

wengi

 

[geiercasi]

while true; do nc -l -p 8085; done

listeners
i:re ^ ^ echo -n "AAAAAAAAAA" | nc localhost 8085
testanruf:
AAAAAAAAAA
realanruf (vorher kam hier nichts, also leer):
AAAAAAAAAA

gruß

 

[buehmann]

Super, danke. Dann hat tatsächlich hexdump (auch aus der Busybox) irgendeinen Bug. Bei mir verhält es sich sich in verschiedenen Kontexten unterschiedlich (noch weiß ich nicht genau, was der Auslöser ist), bei euch wiederum auf eine dritte Weise (nämlich anscheinend in den Listeners gar nicht).

Ich muss noch mal darüber nachdenken, ob mir ein besseres Vorgehen für die Fehlersuche einfällt, als die gesamten Callmonitor-Skripte solange zusammenzuschrumpfen, bis der Fehler verschwindet. So könnte ich auf jeden Fall ein kleines Beispiel konstruieren, das man den Busybox-Entwicklern melden könnte.

Andreas