Callmonitor:bei Rückwärtssuche wird immer Nummer 340134 vorrangestellt

BX-8017 · 18 Jul 2009

Hi.

Bei mir funktioniert die Rückwärtssuche nicht mehr. Dabei kann ich nicht sagen, ob es erst nach dem letzten Flashen oder schon vorher der Fall war. Ich glaube zweiteres.

Wenn ich im Freetzmenü die Rückwärtsuche test und gebe eine Nummer ein, zB 12345, steht da:

schlage 34013412345 nach ...

Das Ergebnis ist natürlich negativ. Hmm, was hat es damit auf sich ??

Grüße
BX-8017

buehmann · 18 Jul 2009

Hallo,

die Nummer "12345" ist eine Nummer im Ortsnetz und wird deswegen um Orts- und ggf. Landesvorwahl ergänzt, bevor die Rückwärtssuche durchgeführt wird. Was hast du denn bei den Standortangaben eingetragen?

Gruß

Andreas

BX-8017 · 18 Jul 2009

Hi.

Im Fritzbox Menü ist folgendes "richtig" eingetragen:

Landesvorwahl 00 49
Ortsvorwahl 0 681

Im Callmonitor Menü wird das allerdings so angezeigt:

Landesvorwahl <!DOC <html>
Ortsvorwahl <!--logi <head>

und zwar gedimmt

Da ist doch irgendwas "vermurkst" oder?? Ich würde sagen,d a stimmt was mit dem Callmonitor nicht. Warum wird das so komisch da angezeigt und warum ist es gedimmt. Wenn man dann auf ändern geht, kommt man in die erweiterten Einstellungen der Internettelefonie. Ich benutze gar keine Internettelefonie, habe zwar eine Nummer konfiguriert (Sipgate) aber nicht aktiv.

Ich habe jetzt im FB Menü die Ziffern nochmal neu eingetragen, aber die Anzeige im Callmonitor bleibt wie geschrieben.

Auch wenn ich im Test der Rückwärtssuche nach einer internationalen Rufnummer suche, wird in der Suche "340134" vorangestellt.
Selbst wenn ich keine Rufnummer angebe, wird nach 340134 gesucht.

Grüße
BX-8017

PS. hier noch die Screengrabs

olistudent · 18 Jul 2009

Ich denke, dass du nicht die neue Version (1.14) vom Callmonitor hast. Kann man das irgendwie auf der Box nachschauen?
Ich hab das Changeset (Update auf 1.14) aber schon in den stable branch gemerged.

MfG Oliver

BX-8017 · 18 Jul 2009

Hi.

Ich habe nachgeschaut. Ich habe die Version 1.13 drauf.

Hmm und was jetzt? Ich habe ja freetz stable 1.1 geflashed. Was muss ich jetzt tun um die 1.14 zu bekommen? Die stable nochmal neu auschecken?

Danke und Grüße
BX-8017

olistudent · 18 Jul 2009

Was genau hast du denn ausgecheckt? Was passiert bei einem "svn up"?

Nicht vergessen:

Code:

make callmonitor-dirclean

MfG Oliver

BX-8017 · 18 Jul 2009

Hi.

Was ich genau ausgecheckt hatte, kann ich nicht mehr sagen.

Ich habe jetzt nochmal neu ausgecheckt. Jetzt ist zumindest der Callmonitor 1.14 im Menu.

Wenn freetz drauf ist. melde ich mich nochmal.

Grüße
BX-8017

.
.
--> Rückwärtssuche funktioniert nochmal einwandfrei !! Vielen Dank

Switch42 · 31 Dez 2009

Selbes Problem

Huhu,

auch ich habe dieses Problem, dass die Anzeige vom Callmonitor mit den Einstellungen der Fritzbox abweicht.

Fritzbox zeigt an:

Landesvorwahl: [00] [49]
Ortsvorwahl: [0] [23..]

Der Callmonitor zeigt folgendes an:

Code:

<tr>
<td>Landesvorwahl</td>
<td><input disabled size=3 value='340134'>
<input disabled size=4 value='49'></td>
</tr>
<tr>
<td>Ortsvorwahl</td>
<td><input disabled size=3 value='0'>
<input disabled size=4 value=''></td>
<td>

Sieht dann so aus:

Landesvorwahl: [340134] [49]
Ortsvorwahl: [0] []

Ich verwende die Version 1.16

Wo könnte das Problem liegen?

joelxy · 1 Jan 2010

Hi, Gutes Neues erstmal.
Sieht bei mir mit 1.16 auch so aus:

Auf der Fritz-Seite(Internettelefonie) steht aber alles richtig drin.

Gruß

Joel!

cuma · 1 Jan 2010

Da muss der Callmonitor wohl an die neue Firmware .80 angepasst werden, habe auch die "340134"

buehmann · 1 Jan 2010

Ja, sieht so aus, als würde der Login in die Weboberfläche (wieder mal) nicht klappen. Falls irgendjemand Anhaltspunkte dafür hat, was sich geändert hat, wäre ich dankbar.

Andreas

PS: Eine andere Möglichkeit wäre, dass sich an der Firmware nichts geändert hat, sondern dies eine weitere Nebenwirkungen der kürzlichen Umstellungen im Bereich Busybox in Freetz ist. Vielleicht könnte jemand mit der 80er-Firmware diese einmal mit den Busybox-Einstellungen vor http://trac.freetz.org/changeset/4099 ausprobieren.

Switch42 · 1 Jan 2010

Hi,

ich hatte vieles ausprobiert. Zu Beginn war meine FBF mit einem Passwort geschützt. Das hatte ich durch Zufall irgendwann in den "Ereignissen" stehen und hatte es darauf hin rausgenommen, allerdings auch keine Besserung.

Ich habe in den Quelltexten gesehen, dass die Daten in der "tel.sh" offensichtlich per UPNP (weiß nicht ob's stimmt), ausgelesen wird und dann die Datei "/var/cache/phonebook/telcfg" erstellt.

Ich werde gleich mal schauen, ob ich die Daten, die dort bei der Abfrage zurückkommen, einmal abgreifen kann. Vielleicht kommt man damit weiter.

Andere Alternative wäre, dass man die Felder im Callmonitor selber setzen kann.

Nächstes Problem wäre dann noch mit dem Auslesen des Telefonbuchs. Da hakt es auch irgendwo.

buehmann · 1 Jan 2010

UPNP stimmt nicht; die Abfrage geht in beiden Fällen (Standorteinstellungen und Telefonbuch) über das Webinterface. Relevant ist modules/webui.sh im Callmonitor. Dort ist auf der Seite der Firmware, der Seite des Callmonitors oder der Seite der Laufzeitumgebung (vor allem Busybox) der Fehler zu suchen.

PS: Auch noch über webui.sh abgewickelt werden solche Dinge wie "callaction config wlan". Das dürfte bei euch auch nicht mehr funktionieren. (Dass "realpath" fehlt, habe ich schon gesehen.)

princenewton007 · 1 Jan 2010

buehmann schrieb:
Vielleicht könnte jemand mit der 80er-Firmware diese einmal mit den Busybox-Einstellungen vor http://trac.freetz.org/changeset/4099 ausprobieren.

Hallo Andreas,

die 80er FW im Changeset 4098 mit dem Callmonitor 1.16 zeigt bei mir keine der hier genannten Auffälligkeiten. Alles sieht so aus und funktioniert "wie immer".

Switch42 · 1 Jan 2010

Hmm ...

ich habe gerade den Teil nachgebaut, der in "tel.sh" aufgerufen wird. Dazu habe ich mir die Codeschnippsel aus "webui.sh" und "url.sh" geholt.

Wenn ich das nun starte, wird mir Anmeldungsseite präsentiert, warum auch immer:

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!--loginPage-->
<head>
<title>FRITZ!Box Anmeldung</title>

Ein Passwort habe ich aber nicht gesetzt. Der Browser fragt nach keinem und cfg2sh schreibt auch nichts:

Code:

/var/media/ftp/uStor01 # cfg2sh ar7 webui
webui_username="";
webui_password="";
webui_expertmode=yes;
webui_wizard_completed=no;
webui_event_filter=0;
webui_read_access_without_login=no;
webui_cookie="1";
/var/media/ftp/uStor01 #

Wenn ich nun den von "tel.sh" generierte URL im Browser einfüge, bekomme ich genau das, was erwartet wird:

Code:

Irgendwie suspekt. Warum landet er mit dem Skript auf der Anmeldungsseite?

buehmann · 2 Jan 2010

@princenewton007: Danke! Das ist eine gute Nachricht. Da sich der Callmonitor seit r4098 nicht geändert hat, bleiben nur die Änderungen in Freetz, falls wir nichts übersehen haben.

@Switch42: Interessant (ja, und suspekt). Enthält die generierte URL eine Session-ID (sid=...)?

Aus webui.sh heraus rufe ich die URL aus Performance-Gründen nicht per HTTP ab (also z.B. per wget), sondern umgehe Netz und Webserver durch den direkten Aufruf des entsprechenden Programms "webcm" in einer simulierten CGI-Umgebung. Vielleicht ist diese Umgebung nicht mehr das, was webcm erwartet (z.B. könnte AVM den Zugriff von 127.0.0.1 aus unterdrücken oder weitere Umgebungsvariablen auswerten).

Switch42 · 2 Jan 2010

buehmann schrieb:
Enthält die generierte URL eine Session-ID (sid=...)?

In der generierten URL von tel.sh natürlich nicht. Da sich "webui.sh" um den Rest kümmert, gibt es an der Stelle noch keine SID.

Wenn man in der FBF ein Kennwort hat, meckert er über ein falsches Passwort. Obwohl es richtig mit cfg2sh ausgelesen wurde:

Code:

[URL="javascript:Eventhelp('501')"]01.01.10 17:30:25 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 127.0.0.1 gescheitert (falsches Kennwort).[/URL]

Nehme ich das Passwort raus, so steht keine Fehlermeldung, sondern nur der Eintrag mit der Anmeldung von 127.0.0.1.

Man müsste schauen, warum die Anmeldung nicht klappt und wie weit die Busybox Auswirkung hat. Ich befürchte schon fast, als wenn das Script irgendetwas mit der SID nicht auslesen kann, da nur ein Versuch in den "Ereignissen" steht.

olistudent · 2 Jan 2010

Hi.
Lag das jetzt an dem realpath-Applet oder liegts vielleicht hier dran?

MfG Oliver

buehmann · 2 Jan 2010

Switch42 schrieb:
In der generierten URL von tel.sh natürlich nicht.

Ah, sorry, hatte ich überlesen.

Man müsste schauen, warum die Anmeldung nicht klappt und wie weit die Busybox Auswirkung hat.

Ja. Ich würde als nächstes webui_login Schritt für Schritt unter die Lupe nehmen (wenn ich eine Box hätte, auf der ich das testen könnte) ...

Oho! Ich habe gerade mal "nach Gefühl" nach kritischen Stellen in webui_login gesucht, die von Änderungen in Busybox betroffen sein könnten. Wie es aussieht, war der erste Schuss ein Treffer: Das Verhalten des folgenden "read"s, das in ähnlicher Situation in webui_login_sid auftaucht, hat sich geändert:

Code:

$ echo "<SID>1</SID>" | (IFS="<>" read -r _ k v _; echo "$k=$v")

# busybox ash 1.13.3 (sowie dash 0.5.5.1 und bash 4.0.33) in Ubuntu
SID=1

# busybox ash 1.15.3 in Freetz
1=/SID

Dadurch schlägt das Parsen der Session-Informationen fehl und dadurch das Login.

Jetzt heißt es die Ursache finden ... (Unabhängig davon kann ich hier das Parsen robuster machen; aber da "read" auch sonst häufig im Callmonitor und in Freetz eingesetzt wird, sollten wir der Sache auf den Grund gehen.)

Viele Grüße

Andreas

PS: Nach einem Durchsuchen der Busybox-Ankündigungen vermute ich, dass hierbei der neue Fehler eingebaut wurde:

Code:

15 April 2009 -- BusyBox 1.14.0 (unstable), BusyBox 1.13.4 (stable)
- ash: fix $IFS handling in read. Closes bug 235

https://bugs.busybox.net/show_bug.cgi?id=235

Ich habe gerade keine Zeit, das weiterzuverfolgen; vielleicht einer von euch ...

Switch42 · 2 Jan 2010

buehmann schrieb:
Ich habe gerade keine Zeit, das weiterzuverfolgen; vielleicht einer von euch ...

Hab gerade getestet und folgende Kombination geht nun:

Code:

/var/tmp # echo "<SID>1</SID>" | (IFS="<>" read k v _ ; echo "$k=$v")
SID=1
/var/tmp #

Das geht aber nur mit der neuen Busybox. Wenn man das bei der alten eingibt, kommt das bei raus:

Code:

root@server3:~|126# echo "<SID>1</SID>" | (IFS="<>" read k v _ ; echo "$k=$v")
=SID
root@server3:~|0#

Oder soll man das Parsen ganz anders umschreiben? Frage nur, wie ...

cya

Callmonitor:bei Rückwärtssuche wird immer Nummer 340134 vorrangestellt

Mitglied

Aktives Mitglied

Mitglied

Anhänge

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

Neuer User

Neuer User

Anhänge

Aktives Mitglied

Aktives Mitglied

Neuer User

Aktives Mitglied

Mitglied

Neuer User

Aktives Mitglied

Neuer User

IPPF-Urgestein

Aktives Mitglied

Neuer User

Statistik des Forums