Callmonitor - Rückwärtssuche endet mit Fehler

gismotro · 26 Sep 2020

die .config ist zu 99% im Image enthalten. Einfach mit winrar entpacken und hier anhängen.

bahner · 26 Sep 2020

wenn ich die .config hochladen will,
kommt
Die hochgeladene Datei erlaubt keine Erweiterung.

prisrak1 · 27 Sep 2020

passend umbenennen/komprimieren, oder einfach um ".txt" erweitern und schon gehts.

gismotro · 27 Sep 2020

Hier mal die .config mit vom Minimal-Image. Auswertung und getestet werden muß es von @bahner
Link zum Image kommt per PN.

fda89 · 27 Sep 2020

Sieht verbastelt aus:

Code:

FREETZ_PACKAGE_CALLMONITOR=y
FREETZ_PACKAGE_CALLMONIOTR=y

Scheinbar nutzt du (nicht nur?) den Callmonitor aus freetz.

gismotro · 27 Sep 2020

Wir hatten mal das problem das der falsche wget aktiviert war, deshalb hatte ich mir damals mal folgenden Eintrag in meiner custom.in eingearbeitet:

Code:

config FREETZ_PACKAGE_CALLMONIOTR
         bool "Paketauswahl_Callmonitor (dazu muss wget Package deaktivieren sein)"
       depends on FREETZ_Wget_Auswahl  && !FREETZ_OHNE_SYSTEM
         select FREETZ_PACKAGE_CALLMONITOR
         select FREETZ_PACKAGE_CALLMONITOR_webif if FREETZ_PACKAGE_CALLMONITOR && (FREETZ_PACKAGE_CALLMONITOR_monitor || FREETZ_PACKAGE_CALLMONITOR_phonebook)
         select FREETZ_PACKAGE_CALLMONITOR_actions if FREETZ_PACKAGE_CALLMONITOR
         select FREETZ_PACKAGE_CALLMONITOR_monitor if FREETZ_PACKAGE_CALLMONITOR
         select FREETZ_PACKAGE_CALLMONITOR_phonebook    if FREETZ_PACKAGE_CALLMONITOR
       select FREETZ_BUSYBOX_WGET if FREETZ_REPLACE_BUSYBOX
       select FREETZ_BUSYBOX_FEATURE_WGET_HTTPS if FREETZ_REPLACE_BUSYBOX
       select FREETZ_BUSYBOX_FEATURE_WGET_OPENSSL if FREETZ_REPLACE_BUSYBOX
        default n

um wget mit ssl für CM und ohne ssl nutzen zu können. Warum der Callmonitor 2x ausgewählt wird, muss ich prüfen.

Edit:
Das selbe ist auch bei telnet=y zu finden.

Ich denke das kommt durch die Auswahl über die coustom.in. M.E. sollte es aber keinen Einfluss auf die Funktion haben.

gismotro · 27 Sep 2020

So, jetzt alles per Hand ausgewählt.

gismotro · 27 Sep 2020

So wie es für mich aussieht, werden nur Nummer im lokalen Telefonbuch gefunden:

Nummer wird aber über den "Fehler"-Button gefunden.

Sollten weitere Dateien zur Fehlersuche benötigt werden, dann bitte melden.
Getestet habe ich folgende Versionen:
1.) Minimalimage, nur Paket Callmanager aktiv.
2.) Minimalimage, nur Paket Callmanager und Wget aktiv.

bahner · 27 Sep 2020

ja, genauso siehts bei mir auch aus,
Nummern aus lokalen Telefonbuch werden mit Name angezeigt.
aber über "Das Örtliche" kommt nur "Fehler"

fda89 · 29 Sep 2020

Warum ist das eine wget gut und das andere nicht? Welches Problem gab es denn? Das gnu-wget ist besser, da es mehr Optionen hat, auch https mit ca-bunle support. Vielleicht hat sich auch nur die URL zur Rückwärtssuche geändert?

EDIT: Die Script für die Rückwärtssuche liegen auf der Fritzbox in /usr/lib/callmonitor/reverse/

bahner · 1 Okt 2020

fda89 schrieb:
Warum ist das eine wget gut und das andere nicht? Welches Problem gab es denn? Das gnu-wget ist besser, da es mehr Optionen hat, auch https mit ca-bunle support. Vielleicht hat sich auch nur die URL zur Rückwärtssuche geändert?

EDIT: Die Script für die Rückwärtssuche liegen auf der Fritzbox in /usr/lib/callmonitor/reverse/

hast du bei dir callmonitor am laufen?
funktioniert bei dir die Rückwärtssuche?
wenn ja, könntest du helfen, ein funktionierendes image zu erstellen?
danke

gismotro · 1 Okt 2020

fda89 schrieb:
EDIT: Die Script für die Rückwärtssuche liegen auf der Fritzbox in /usr/lib/callmonitor/reverse/

Da steht aber nix drin was geändert werden müsste...
Testbeispiel :

Code:

_reverse_dasoertliche_url() {
local number="0${1#+49}"
URL="http://www.dasoertliche.de/Controller?form_name=search_inv&ph=$(urlencode "$number")"
}
_reverse_dasoertliche_request() {
local URL=
_reverse_dasoertliche_url "$@"
wget_callmonitor "$URL" -q -O -
}
_reverse_dasoertliche_extract() {
sed -n -e '
\#Kein Teilnehmer gefunden:\|keine Treffer finden# {
'"$REVERSE_NA"'
}
\#<div[[:space:]]\+class="hit[^>]\+id="entry_1#,\#</address[[:space:]]*># {
\#<a[[:space:]]#,\#</a[[:space:]]*># {
H
\#</a># {
g
s#.*#<rev:name>&</rev:name>#
h
}
}
\#<address#,\#</address[[:space:]]*># {
H
\#</address[[:space:]]*># b found
}
}
b
:found
g
'"$REVERSE_SANITIZE"'
'"$REVERSE_OK"'
'
}

oder verstehe ich deinen Hinweis wieder einmal nicht ?

fda89 · 2 Okt 2020

Wieso, in deinem Beispiel steht die URL die abgerufen wird und das sed mit dem die Nummer herausgelesen wird.
Es soll ja vorkommen dass sich eine Webseite über die Jahre mal ändert, dann passt dieses sed nicht mehr.
Müsste jemand schauen ob es noch passt und wenn nicht korrigieren. Halt für jeden reverse-provider von dem Screenshot

gismotro · 2 Okt 2020

Du hattest recht. Bei das Örtliche ist zumindestens der Link veraltet
Im Addon :

URL="http://www.dasoertliche.de/Controller?form_name=search_inv&ph=$(urlencode "$number")"
}

aktuell:

URL="https://www.dasoertliche.de/Controller?form_name=search_inv&ph=$(urlencode "$number")"
}

@fda89 : das müsste m.E. aber im Addon direkt geändert werden, da das Filesystem auf der Box read-only ist, oder ?

chilango79 · 2 Okt 2020

Hmm das war eine Funktion die ich im Freetz der 7150 damals liebte. Dort konnte ich in den Telefonlisten im AVM UI bei unbekannten Nummern direkt mit einem Icon die Rückwärtssuche starten.
Das ging aber nur bei der 7150 damals

fda89 · 2 Okt 2020

Man kann das schon unter make/callmonitor/ ändern, als Patch unter patches/. Wie bei jedem anderen package
Funktioniert die Rückwärtssuche mit der neuen URL? Kann man mit "mount -o bind" auf der box testen: https://freetz-ng.github.io/freetz-ng/wiki/10_Beginner/basic_questions.en.html

EDIT: Durch einen Wechsel von http auf https muss wget entweder die Zertifikate ignorieren oder das ca-bundle nutzen. Das gnu-wget kann das, wenn das ca-bundle ausgewählt ist, beim busybox-wget bin ich nicht sicher
EDIT2: Callmonitor wählt selbst gar kein wget aus!

gismotro · 2 Okt 2020

fda89 schrieb:
EDIT2: Callmonitor wählt selbst gar kein wget aus!

Das stimmt, ich hab das über die coustom.in realiesiert Tip von hier)

Code:

config FREETZ_PACKAGE_CALLMONIOTR
         bool "Paketauswahl_Callmonitor (wget Boardimage dann deaktivieren)"    
       depends on FREETZ_Wget_Auswahl  && !FREETZ_OHNE_SYSTEM
         select FREETZ_PACKAGE_CALLMONITOR
         select FREETZ_PACKAGE_CALLMONITOR_webif if FREETZ_PACKAGE_CALLMONITOR && (FREETZ_PACKAGE_CALLMONITOR_monitor || FREETZ_PACKAGE_CALLMONITOR_phonebook)
         select FREETZ_PACKAGE_CALLMONITOR_actions if FREETZ_PACKAGE_CALLMONITOR
         select FREETZ_PACKAGE_CALLMONITOR_monitor if FREETZ_PACKAGE_CALLMONITOR
         select FREETZ_PACKAGE_CALLMONITOR_phonebook    if FREETZ_PACKAGE_CALLMONITOR
       select FREETZ_BUSYBOX_WGET if FREETZ_REPLACE_BUSYBOX
       select FREETZ_BUSYBOX_FEATURE_WGET_HTTPS if FREETZ_REPLACE_BUSYBOX
       select FREETZ_BUSYBOX_FEATURE_WGET_OPENSSL if FREETZ_REPLACE_BUSYBOX
        default n

Aber ich denke wir suchen in die falsche Richtung. https war damals das Problem laut Olistudent und das wurde ja gefixt mit der Auswahl in der coustom.in

fda89 · 2 Okt 2020

So Halb. FREETZ_BUSYBOX_FEATURE_WGET_OPENSSL ermöglicht https. Allerdings mit dem Hinweis

Code:

wget: note: TLS certificate validation not implemented

Wenn man dazu noch openssl mit ins image nimmt wird das Zertifikat auch geprüft. Dies durch das ca-bundle das für openssl schon in ng konfiguriert ist.
gnu-wget kann das auch, ist auch für ca-bundle konfiguriert. Damit sollte es mittlerweile egal sein welches wget man nimmt
Bleibt die Frage ob man die Zertifikate auch prüfen will

Das hilft aber alles nichts gegen das ursprüngliche Problrm

gismotro · 2 Okt 2020

fda89 schrieb:
Das hilft aber alles nichts gegen das ursprüngliche Problrm

Stimmt, ich habe beide wget´s getestet.

PeterPawn · 2 Okt 2020

fda89 schrieb:
FREETZ_BUSYBOX_FEATURE_WGET_OPENSSL ermöglicht https. Allerdings mit dem Hinweis

Da stimmt aber irgendetwas nicht ... dieser Hinweis kommt nur (https://git.busybox.net/busybox/tree/networking/wget.c?h=1_31_stable#n727), wenn man mit dem internen TLS-Code arbeitet.

Und wenn "FEATURE_WGET_OPENSSL" aktiviert ist, wird zuerst auch mit OpenSSL probiert und erst danach der interne Code (wenn er dank "FEATURE_WGET_HTTPS" zusätzlich eingebaut wurde) in Betracht gezogen (https://git.busybox.net/busybox/tree/networking/wget.c?h=1_31_stable#n115).

======================================================================

Im aktuellen BusyBox-Master sollte das dann auch mit der Zertifikatprüfung bei Benutzung von OpenSSL korrekt arbeiten (https://git.busybox.net/busybox/commit/?id=fc2ce04a38ebfb03f9aeff205979786839cd5a7c) - diese Korrektur kam aber erst (wenige Tage) nach dem Release der 1.32.0 dazu.

Die Dopplung mit "-verify <anything>" und "-verify_return_error" ist (iirc/afaik) für OpenSSL-Versionen vor 1.1.1 erforderlich (das wurde nur für 1.1.1 gefixt: https://github.com/openssl/openssl/commit/78021171dbcb05ddab1b5daffbfc62504ea709a4) und damit bin ich auch schon etwas überrascht, daß da bei BusyBox 1.31.1 (https://git.busybox.net/busybox/tree/networking/wget.c?h=1_31_stable#n693) und OpenSSL 1.0.2 (von 1.1.x ist in Freetz-NG ja nichts zu sehen) tatsächlich eine Prüfung des Server-Zertifikats funktionieren soll, so wie "openssl" von der BusyBox 1.31.1 aufgerufen wird.

Teste ich das mit dieser OpenSSL-Version "von Hand", gibt es jedenfalls nur bei der Angabe von "-verify X" (wobei "X" wohl mal als "verify depth" gedacht war, aber auch mit nicht-numerischen Werten akzeptiert wird) UND "-verify_return_error" einen Fehler, wenn das OpenSSL auf ein "self-signed certificate" trifft und auch der Server-Name im Zertifikat würde nur bei "-verify_hostname xxx.yyy" geprüft und nicht einfach mit der "-servername"-Option, die nur den SNI-Header bestimmt und im "openssl"-Aufruf der BusyBox enthalten wäre:

Code:

# ./openssl version
OpenSSL 1.0.2u  20 Dec 2019
# ./openssl s_client -connect 192.168.131.2:443 -quiet -no_ign_eof </dev/null; echo $?
depth=1 C = DE, ST = Berlin, L = Berlin, O = Peter XXX, OU = Person, CN = ca.xxx.de, emailAddress = [email protected]
verify error:num=19:self signed certificate in certificate chain
DONE
0
# ./openssl s_client -connect 192.168.131.2:443 -quiet -no_ign_eof -verify_return_error </dev/null; echo $?
depth=1 C = DE, ST = Berlin, L = Berlin, O = Peter XXX, OU = Person, CN = ca.xxx.de, emailAddress = [email protected]
verify error:num=19:self signed certificate in certificate chain
DONE
0
# ./openssl s_client -connect 192.168.131.2:443 -quiet -no_ign_eof -verify_return_error -verify dummy </dev/null; echo $?
depth=1 C = DE, ST = Berlin, L = Berlin, O = Peter XXX, OU = Person, CN = ca.xxx.de, emailAddress = [email protected]
verify error:num=19:self signed certificate in certificate chain
136780024:error:14090086:lib(20):func(144):reason(134):NA:0:
1
#

Damit wird es also auch extrem unwahrscheinlich, daß die Fehler hier von alten oder fehlenden Zertifikaten im "ca_bundle" oder überhaupt von der Zertifikatprüfung stammen - das ist in dieser Kombination von "openssl" und BusyBox 1.31.1 alles nur "fake" und stellt keinesfalls sicher, daß man tatsächlich mit dem gewünschten Server kommuniziert und da (in anderem Kontext als "callmonitor") ggf. auch ganz brav seine Credentials abliefert, obwohl es vielleicht jemand ganz anderes ist.

Da halte ich die Feststellung, daß vom BusyBox-Applet bei der Benutzung von "openssl" irgendwelche Zertifikate (erfolgreich(!), was hier natürlich heißt, daß das fehlschlagen muß, wenn etwas nicht stimmt) geprüft würden, für einen Irrtum oder eine falsche Beobachtung - vielleicht sollte man das noch einmal testen. Dafür kann man sogar ein "openssl s_server" mit einem selbstsignierten Zertifikat verwenden oder auch das (interne) FRITZ!OS-GUI (das steht auch auf Port 443 zur Verfügung), solange das Zertifikat dort auch "invalid" oder "self-signed" ist (ein LE-Zertifikat wäre also nicht so günstig).

Es mag sogar noch sein, daß da tatsächlich gegen die Zertifikate aus dem "ca_bundle" geprüft wird und daher die (hier angezeigte, aber beim "wget" ohnehin ignorierte) Fehlerausgabe (der "verify error") nicht auftaucht. Aber von einer "echten Prüfung", die auch beim Fehlschlag dann entsprechende Konsequenzen hat (nämlich den Abbruch der Verbindung), kann man dabei dann sicherlich nicht reden,

Callmonitor - Rückwärtssuche endet mit Fehler

Mitglied

Neuer User

Mitglied

Mitglied

Anhänge

Mitglied

Mitglied

Mitglied

Anhänge

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

Anhänge

Mitglied

Mitglied

Aktives Mitglied

Mitglied

Mitglied

Mitglied

Mitglied

IPPF-Urgestein

Statistik des Forums