[Problem] JFritz deaktiviert Anrufliste

[fda89]

Ich hab mit der 7590 seit Update auf 7.20 das Problem dass nach dem Abholen von Anrufen durch JFritz die Anrufliste der Fritzbox deaktiviert wird. Dies kann verhindert werden durch deaktivieren der Option "Nach Laden auf Box löschen".
Mir ist vorher noch nicht aufgefallen dass man die Anrufliste überhaupt deaktivieren kann, diese Option ist vermutlich neu und wird von JFritz noch nicht beachtet:

 

[fda89]

Hat ausser mir niemand dieses Problem? Oder benutze nur ich das "Nach Laden auf Box löschen"?

 

[HD]

Bei meiner 6591 mit 7.21 ebenso.

 

[wolle52]

Ich kann das Problem bei 2 unterschiedlichen Fritzen bestätigen. Bei meiner Freundin seit Mitte September keine Liste mehr in der FB-Cable und auch Ende der Liste in jfritz. Ich fand am Wochenende heraus, dass die Liste in der FB deaktiviert ist. Das Listenende, also letzter Anruf, war unmittelbar vor einem FB-Update im September. Danach hat Fritz die Liste beim nächsten Abruf deaktiviert. Das Verhalten ist nachvollziehbar. Beendet man jfritz, dann bleibt die Liste in der Fritz aktiv. Startet man jfritz wieder, wird die Listenfunktion nach dem nächsten Listenabruf wieder abgeschaltet. Das Gleiche passiert an meiner FB-DSL seit ca. 2 Wochen und einem manuell ausgelöstem Update auch. Ist mir aber bisher nicht aufgefallen, weil ich selten die Anrufliste anschaue. Ein Abschalten der automatischen Löschfunktion beendet den Fehler. Man sollte sich dann den Kalender stellen, um das 1-mal im Monat manuell in der FB zu löschen.

Ich habe das Problem bereits ausführlich an AVM gemeldet. Die Weiterleitung an die Entwicklung wurde mir gestern bestätigt. So wie es aussieht, wird das Abschalten der Liste durch den externen Löschbefehl von jfritz ausgelöst. Der löscht nicht nur, sondern schaltet ab. Da hat AVM wohl beim Update einen BUG mit eingebaut. Ist ja leider nicht das erste Mal. Und beim letzten Update waren es gleich mehrere.:-(

Lösung also vorerst wie schon gesagt wurde: Abschalten der Listenlöschung nach Abruf in jfritz.

 

[PeterPawn]

Da hat AVM wohl beim Update einen BUG mit eingebaut. Ist ja leider nicht das erste Mal.

Na ja, das kann man aber auch anders sehen.

Ja, JFritz ist ein tolles und umfangreiches Programm ... aber es greift eben auch auf Wegen auf die Box zu, die so von AVM nicht vorgesehen sind und daher sogar ausdrücklich als "nicht stabil" anzusehen sind. Daß sich AVM bei Änderungen an dokumentierten Funktionen mittlerweile zusammen- und fast ein Bein ausreißt und die entsprechenden Infos an die Entwickler herausgibt (auch rechtzeitig), kann man hier nachlesen (zum ersten Mal für mich "vorbildlich", weil es eben nicht erst von anderen Entwicklern durch Analyse ermittelt werden mußte):

Schnittstellen für Entwickler

Schnittstellendokumentation für Entwicklungen im FRITZ!Box-Umfeld

avm.de

Ich stecke jetzt nicht allzu tief in der Materie der JFritz-Quellen - aber die Ursache des Problems dürfte dort zu suchen sein und zwar vermutlich in dieser Zeile:

jfritz/src/main/java/de/moonflower/jfritz/box/fritzbox/callerlist/FritzBoxCallList_Actual.java at develop · jfritz-org/jfritz

Java program to manage calls and other stuff from your FRITZ!Box on a PC or MAC. It supports Windows, OS X and Linux systems. - jfritz-org/jfritz

github.com

Denn bisher wertete AVM lediglich die Existenz eines Input-Controls (bzw. eines Name/Value-Paars) mit dem Namen "usejournal" aus, um dann die Verwendung der Anrufliste zu aktvieren:

317 if box.post.apply then
318 if box.post.usejournal then
319 foncalls.SetActive(1)
320 else
321 foncalls.ClearList()
322 foncalls.SetActive(0)
323 end
324 elseif box.post.clear then
325 foncalls.ClearList()
326 end

- mit der letzten Version hat sich das aber geändert:

349 if box.post.usejournal then
350 if box.post.usejournal == "1" then
351 foncalls.SetActive(1)
352 else
353 foncalls.ClearList()
354 foncalls.SetActive(0)
355 end
356 elseif box.post.clear then
357 foncalls.ClearList()
358 end

Das heißt dann aber, daß nunmehr für "usejournal" der Wert "1" (und nicht "on", wie in JFritz) übergeben werden muß, damit das Journal nicht gelöscht und ausgeschaltet wird (Zeile 353 im letzten Code-Kasten).

Das würde ich jetzt nicht wirklich als Bug von AVM werten - in deren Code wird nämlich dieser Wert durchaus richtig gesetzt im Request an die Box.

Der Workaround funktioniert eben deshalb, weil ohne den Löschwunsch für die alten Einträge die Funktion " clearCallerList()" gar nicht erst aufgerufen wird. Allerdings wäre das auch in JFritz schnell und leicht zu korrigieren ... dem alten Code ist es Wumpe, ob da ein "on" oder eine "1" übergeben wird - damit muß man da nicht mal differenzieren, um welche Version es sich bei der Firmware handelt. Allerdings braucht man zum Erzeugen der neuen Pakete für die Installation auch die passende (und lauffähige) Umgebung - die haben sicherlich die wenigsten bei sich installiert. Vielleicht bringt es ja etwas, in der bereits existierenden Issue im GitHub-Repo von JFritz noch einen Link auf diesen Thread zu hinterlegen ... ich weiß allerdings nicht, wie weit der Autor bei sich die notwendige Umgebung auch ständig einsatzbereit hält. Aber ich werde mal einen entsprechenden Kommentar in https://github.com/jfritz-org/jfritz/issues/28 hinterlassen, wie man das schnell und unbürokratisch lösen können sollte - dazu muß dieser Beitrag hier aber erst mal gespeichert sein, damit ich ihn verlinken kann.

Das ist aber nun mal generell das Risiko, wenn man nicht über entsprechende Schnittstellen zugreift (allerdings bietet AVM in "X_AVM-DE_TAM1" auch keine Funktion an, mit der man die gesamte Liste auf einen Schlag löschen könnte und man müßte das über TR-064 tatsächlich für jede Message einzeln mit "DeleteMessage()" machen) ... dann muß man auch damit rechnen (und damit leben), wenn sich mal etwas so ändert, daß bestehende Software (gerade dann, wenn sie mit "scraping" arbeitet oder auch nur mit direkten HTTP-Requests für das GUI) danach geändert werden muß. Ich glaube auch nicht wirklich, daß @robotniko (bzw. @robot_rap) selbst hier AVM "die Schuld" geben würde - dann sollten das die Nutzer des Programms auch nicht tun.

EDIT: Da habe ich jetzt selbst einen der Fehler gemacht, die mich bei anderen immer stören ... ich hätte vielleicht besser noch eine Nacht darüber schlafen sollen, bevor ich das speichere. Denn die Änderung von "on" auf "1" führt ja nur dazu, daß die Liste nicht mehr deaktiviert wird - damit wird die Liste aber auch nicht (mehr) gelöscht. Insofern muß man doch unterscheiden zwischen den Versionen - bei der neuen Version muß das "usejournal" komplett weggelassen werden ... nur dann würde das "clear" im "elseif"-Zweig geprüft. Da dürfte es dann wieder fast einfacher sein, wenn man (ohne zwischen den Versionen zu unterscheiden) nach dem Löschen mit "Deaktivieren" noch einmal dieselbe Seite (foncalls_list.lua) aufruft und dabei dann die jetzt notwendige "1" für "usejournal" setzt (im ersten Aufruf dann mit irgendetwas anderem als "1", was wäre egal).

 

[wolle52]

Hallo, danke für deine sehr umfangreiche Erklärung. Ein bisschen verstehe ich auch was von Programmierung und verstehe, was du geschrieben hast.

Trotzdem bleibe ich dabei, dass hier AVM einen oder mehrere Fehler gemacht hat. Ein Fehler in einem externen Programm wie z.B. Jfritz, und sei es nur eine falsche bzw. nicht vorgesehene Nutzung einer Schnittstelle darf auf keinen Fall dazu führen, dass eine vom User aktivierte Anruflistenfunktion einfach so dir nichts mir nichts abgeschaltet wird.

Dass ein falscher Auftrag oder ein falscher Zustand von was auch immer dazu führt, dass die Liste nicht ausgelesen bzw. danach nicht gelöscht werden kann ist ja ok. Aber dabei muss es bleiben. Das externe Programm bekommt eben nichts. Und der Löschbefehl wird meinetwegen ignoriert, wenn er nicht passt. Sowas verursacht keinen Schaden. Hier hat das Auslesen und Löschen sogar jeweils 1-mal funktioniert. Und danach war die Protokollierung einfach so abgeschaltet.

Aber ein Abschalten der Protokollfunktion ist eine mutwillige Zerstörung von Kundendaten. Nämlich mein Anrufprotokoll ist teilweise weg bzw. wurde nicht weiter geschrieben. Das hätte ich für Abrechnungszwecke noch gebraucht. Ich mache u.a. Telefonhotline und rechne nach Zeit ab.

Nun denn - ich muss mich da wohl mit abfinden und hoffen, dass der Jfritz-Programmierer den Bug behebt. Ich habe den "Löschen nach Abruf-Befehl" nun abgeschaltet. Dann kann Jfritz abrufen und es wird nichts in der FB abgeschaltet.

Wie gesagt, dass der Löschbefehl für die Liste die Protokollierung einfach abschaltet ist ein Unding. Das werde ich mit AVM auch noch mal bereden. Die haben wieder ein paar böse Bugs in die letzten Updates eingebaut. Z.B. Die SMB-Unterstützung einfach so abgeschaltet. Und ich suche mich dumm und dusslig, warum mein Messrechner plötzlich nicht mehr auf dem NAS speichern kann. Bei 2 Kunden ist da auch passiert. Da war wegen dieses Bugs u.a. die halbe Klein-Fertigung lahmgelegt. Und wer rechnet schon damit, dass wegen eines unbemerkten "Overnight-Update" der Fritzbox deshalb Teile vom Netz nicht mehr gehen.

 

[PeterPawn]

Das werde ich mit AVM auch noch mal bereden.

Dann mach das mal ... aber die Aussage:

Und danach war die Protokollierung einfach so abgeschaltet.

ist (für mich zumindest) Unfug, denn "einfach so" war das eben genau nicht.

Das wurde/wird durch einen entsprechenden HTTP-Request (obendrein noch mit den entsprechenden Werten, denn ohne "usejournal" würde tatsächlich nur gelöscht) ausgelöst. Hier jetzt zu fordern, daß AVM die Firmware gegen solche (falschen) Requests absichern müßte, verlangt gleichzeitig von AVM fast hellseherische Kräfte - denn an dem Request selbst steht eben nicht dran, daß der "nur die Anrufliste löschen" soll und die Protokollierung ansonsten bitte schön nicht deaktivieren möchte.

Das wäre dann halt ein anderer Request (der auch vorgesehen ist) - nur woher soll denn die Firmware (bei einem syntaktisch erst mal richtigen Requests) jetzt "wissen", was da gerade tatsächlich die "Absicht" war? Löst man den entsprechenden Request über einen Browser aus, funktioniert das Ganze (m.W.) auch vollkommen klaglos - die Funktion zwischen der Firmware und dem Browser (für den das GUI gedacht ist) sollte also passend abgestimmt sein. Wenn da jetzt jemand "von der Seite" reingrätscht und dabei Schaden anrichtet (wenn man das Deaktivieren als solchen sehen will), können weder die AVM-Firmware noch ein Browser etwas dafür und wenn sich AVM entschlossen hat, den Request vor dem tatsächlichen Senden erst noch per JS (und damit nur auf einem passenden JS-Host, also üblicherweise einem Web-Browser) passend zu modifizieren, dann ist das nur ihr ("die GmbH") "gutes Recht".

Jede andere Forderung wäre hier ja auch absonderlich - ja, eine Forderung, solche Requests müßten dauerhaft "stabil" bleiben (noch einmal: wir reden hier von undokumentierten Teilen, die also auch definitiv kein "interface" sind, weil es schon am entsprechenden "contract" fehlt), würde praktisch jede Weiterentwicklung bzw. Veränderung der Firmware behindern. Wer solche Forderungen aufstellen will und sie für legitim hält, dem bleibt es ja unbenommen, weiterhin die Version zu verwenden, bei der das "so wie bisher" auch noch funktioniert - dann muß er eben auf Änderungen (das gilt für Fehlerkorrekturen und Funktionserweiterungen) auch verzichten. Niemand zwingt ihn ja, die neuen Versionen zu verwenden - den Security-Aspekt lasse ich hier mal aus, denn gerade auch für den wäre so eine Forderung nach "Stabilität" ja absurd, wenn damit bekannte Sicherheitslücken auch "stabil" bleiben sollten, nur weil irgendein Dritter die bisher "benutzt" hatte (hier fällt mir spontan "webcm" ein).

Ich denke mal, es ist sehr offensichtlich, daß ein

Wie gesagt, dass der Löschbefehl für die Liste die Protokollierung einfach abschaltet ist ein Unding.

ziemlich weit daneben liegt ... denn so einen "Löschbefehl" gibt es offiziell gar nicht (zumindest keinen dokumentierten - also erst recht nichts, was man als "DER Löschbefehl" ansehen könnte) und damit sind sämtliche "Erwartungen", was bei einem solchen Aufruf geschehen sollte, genauso für die Tonne.

 

[wolle52]

Du schreibst gerne viel - ist aber schon ok und interessant. Ich sehe das als User aber einfacher. Die FB hat ein interne Funktionen Protokollierung "Abschalten" und "Anschalten". So wie man es über die Webseite auch ausführen kann. Das ist ein Paar Schuhe. Und dann gibt es die Funktionen oder Wege die Liste auszulesen und was auch alles immer. Dazu muss die Firmware die externen Kommandos, wie auch und was auch immer, ja in irgend einer Form interpretieren und ausführen oder verweigern. Und egal was da kommt oder schiefgeht, darf nicht die Funktion "Protokollierung Ausschalten" aufgerufen werden, wenn es dazu keinen expliziten Befehl für gibt und aufgerufen wird. Wenn die Box Sachen macht, die durch fehlerhafte Ansteuerung ausgelöst werden, dann ist zu vermuten dass da auch andere eventuell sicherheitsrelevante Sache "einfach" bei entsprechendem Wissen ausgetrickst werden können. Für mich ist das eindeutig ein Fehler in der Firmware, wenn so was bei nicht korrekter Ansteuerung passiert. In so einem Fall muss die Box den/die Befehl/e eben verweigern und nicht irgend was draus machen. Hier eben das ungewollte Abschalten der Protokollierung. Soweit eben meine Meinung. Warten wir mal ab was AVM sagt.

 

[PeterPawn]

Oh Mann ... ich stehe heute irgendwie meilenweit neben mir. Weiter oben schreibe ich noch irgendetwas von "X_AVM-DE_TAM1" als TR-064-Interface - das gibt es zwar auch, aber das ist eben für den Anrufbeantworter und die Anrufliste versteckt sich im Interface "X_AVM-DE_OnTel1", zusammen mit den Telefonbüchern. Da gibt es aber dann auch kein "DeleteMessage()" (wenn ich nicht so verpeilt (bzw. abgelenkt) wäre, hätte mir das schon am Namen auffallen müssen) und es bleibt einem "Drittprogramm" tatsächlich nichts anderes übrig, als auf den direkten Request zurück zu greifen (wenn es die Lliste löschen will und sie nicht nur inkrementell auslesen möchte, was aber dann auch wieder funktioniert). Zumindest der Rest (nach der Korrektur) mit einer möglichen Lösung stimmt aber noch.

EDIT: Bei der Suche nach einer Erklärung, warum ich beim falschen Interface gelandet bin, ist mir dann das aufgefallen:


@wolle52:
Du übersiehst halt, daß exakt das geschehen ist, was Du bei all Deinen postulierten Erwartungen ausklammern willst - es GAB einen entsprechenden Request seitens JFritz und damit hat sich die Firmware nicht einfach "spontan" einfallen lassen, daß sie einfach mal die Liste löschen und die Protokollierung deaktivieren wollte. Das ist exakt das, was bei einem entsprechenden Request auch geschehen sollte - wenn sich hier das "Format" für einen solchen Request geändert hat, ist das eine rein "interne Angelegenheit" und entzieht sich jeder (diplomatischen) Bewertung durch Dritt(staat)e(n).

 

[wolle52]

Na gut - lassen wir es einfach mal so stehen. Ich kenne mich mit dem Protoll der Box und Jfritz nicht aus. Und kann da nur meine Seite dazu sagen.