FBEditor braucht man den denn Überhaupt noch?!

kARMU · 3 Apr 2018

Ja, richtig.
Der DVB-C Reiter ist mit dabei, und auch funktionstüchtig.
Bei der letzten Version gab es ihn übrigens noch nicht.

PeterPawn · 3 Apr 2018

Dann wird es wohl an der Datei "dvb.cfg" in einer Export-Datei liegen (die wird auch dann erzeugt, wenn kein Suchlauf erfolgte) ... diese verwendet den Typ "CRYPTEDBINFILE". Da die Perl-Library den vermutlich nicht kennt, wird sie (absehbar) daran scheitern und auch der FBEditor kennt diesen Typ wohl nur in einigen ausgewählten Versionen.

Das Thema ist auch nicht ganz neu: https://www.ip-phone-forum.de/threa...ritzboxen-mit-dvb-c-richtig-berechnen.278904/ und ich würde natürlich meinerseits (schon aus dem Bestreben heraus, die eigenen "Erzeugnisse" zu pushen) am ehesten mit den Funktionen von "decoder" arbeiten, wenn ich etwas mit den Export-Files machen müßte.

kARMU · 3 Apr 2018

Ja,
**** CRYPTEDBINFILE:dvb.cfg
ist in der Export-Datei mit drin.

Also, vorerst ist da nichts zu machen?

PeterPawn · 3 Apr 2018

kARMU schrieb:
Also, vorerst ist da nichts zu machen?

Wo steht das denn nach Deiner Ansicht?

Hast Du mal ~~die~~ den von mir verlinkten ~~Threads~~ Thread gelesen und bist ggf. sogar dort noch vorhandenen Links gefolgt?

Vermutlich nicht ... denn die Lösung ist so alt wie der verlinkte Thread und das steht da auch so deutlich drin - vom zusätzlichen Verweis auf mein "decoder"-Projekt ganz zu schweigen, in dessen "README.md"-Datei (die wird ja nun sehr prominent im Browser angezeigt, wenn man ein GitHub-Repo mit HTTP "besucht") auch noch der entsprechende Thread mit der Erklärung hier im IPPF verlinkt ist.

Das war also eher nichts ... sorry.

Pikachu · 4 Apr 2018

Steht wohl hier schon nr14

PS: Hier: FBEditor 0.6.9.7 eine Testversion, und keine Garantie ob es mit der Checksumme zum Type "CRYPTEDBINFILE" geht.

PeterPawn · 4 Apr 2018

Pikachu schrieb:
keine Garantie ob es mit der Checksumme zum Type "CRYPTEDBINFILE" geht.

Schaue ich mir die Quellen des verlinkten Pakets an (unter dem Tag wird https://github.com/mypikachu/FBEditor/archive/v0.6.9.6.zip verlinkt), sieht die CalcChecksum-Klasse immer noch so aus:

Code:

package de.FBEditor.utils;

import java.io.UnsupportedEncodingException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.zip.CRC32;

public class CalcChecksum {
  
   private static int type = 0;
   private static boolean file = false;
   private static CRC32 crc;
   private static String expected = "";
   private static String last;
  
   public CalcChecksum() {
       /* Initialize crc32 */
       crc = new CRC32();
   }

   private void calchk(String line) {
       /* start of new section? */
       if (type == 0) {
           // Debug.debug(Long.toHexString(crc.getValue()));
          
           String filename;
           if ((filename = Utils.pMatch("\\*\\*\\*\\* CFGFILE:(.*?)$", line, 1)) != null) {
               Debug.debug(line);
               file = true;
               type = 1;
           } else if ((filename = Utils.pMatch("\\*\\*\\*\\* BINFILE:(.*?)$", line, 1)) != null) {
               file = true;
               Debug.debug(line);
               type = 2;
           } else {
               if (Utils.pMatch("\\*\\*\\*\\* (.+) CONFIGURATION EXPORT", line, 0) != null) {
                   file = false;
                   Debug.debug(line);
                   type = 3;
                   return;
               }
               if (Utils.pMatch("\\*\\*\\*\\* END OF EXPORT (.*?)", line, 0) != null) {
                   expected = line.substring(19, 27);
                   Debug.debug(line);
               }
           }
           // parse filename
           if (file) {
               line = filename + '\0';
               updateCRC(line);
               file = false;
               return;
           }
       } else {
           if (type == 1) { // cfg file (stripcslashes, add '\n' at the end)
               if (line.indexOf("**** END OF FILE") == 0) {
                   type = 0;
                   if (last != null) {
                       updateCRC(last);
                   }
                   last = null;
                   return;
               }
               if (last != null) {
                   last = last.replace("\\\\", "\\");
                   last = last + '\n';
                   updateCRC(last);
               }
               last = line;
               return;
           }
           if (type == 2) {  // bin file
               if (line.indexOf("**** END OF FILE") == 0) {
                   type = 0;
                   return;
               }
               String hex = line.trim().toLowerCase().replace("\n", "");
               String bin_line = "";
               for (int i = 0; i < hex.length(); i += 2) {
                   //int b = Integer.parseInt(hex.substring(i, i + 2), 16);
                  
                   // FIXME: This is very slow!
                   //updateCRC(b);
                   bin_line += (char) Integer.parseInt(hex.substring(i, i + 2), 16);
               }
               updateCRC(bin_line);

               return;
           }
           if (type == 3) { // variable (remove "=", add '\0' to the end
               if (line.indexOf("****") != -1) {
                   type = 0;
                   calchk(line);
               }
               if (Utils.pMatch("(\\S*?)=(\\S*?)", line, 0) != null) {
                   line = line.replaceFirst("=", "");
                   line = line + '\0';
                   updateCRC(line);
                   return;
               } else {
                   return;
               }
           }
       }
   }

   public long getChecksum(String text) {
       text = text.replace("\r", ""); // Remove all CRs for calculation
       Pattern p = Pattern.compile("(.*?)\\n", 2);
       for (Matcher matcher = p.matcher(text); matcher.find(); calchk(matcher.group(0).replace("\n", ""))) {
           @SuppressWarnings("unused")
           String temp = matcher.group(0);
       }

       return crc.getValue();
   }

   public static boolean getchecksum() {
       String checksum = Long.toHexString(crc.getValue()).toUpperCase();
       if (checksum.length() < 8)
           checksum = '0' + checksum;
       if (!checksum.equals(expected)) {
           Debug.debug("CHECKSUM FIXED: " + checksum + "(old: " + expected + ")");
           return false;
       } else {
           Debug.debug("CHECKSUM OK: " + checksum);
           return true;
       }
   }

   private void updateCRC(String line) {
       try {
           crc.update(line.getBytes("ISO-8859-1"));
       } catch (UnsupportedEncodingException e) {
           // TODO Auto-generated catch block
           e.printStackTrace();
       }
   }
/*
   private void updateCRC(int b) {
       crc.update(b);
   }
*/
  
   /*
    * Calculate new checksum and replace if different
      */
   public static String replaceChecksum(String text) {
       String newText = "";
       String checksum;
       if ((checksum = Utils.pMatch("\\*\\*\\*\\* END OF EXPORT (.*?) \\*\\*\\*\\*", text, 1)) != null) {
           CalcChecksum exportsumme = new CalcChecksum();
           String newChecksum = Long.toHexString(exportsumme.getChecksum(text));
           newChecksum = newChecksum.toUpperCase();
           if (!CalcChecksum.getchecksum())
               newText = text.replace(checksum, newChecksum);
           else
               newText = text;
       } else {
           newText = text;
       }
       return newText;
   }
}

Da kann also niemand erkennen, welche Änderungen Du - von der 0.6.9.6 kommend - tatsächlich vorgenommen hast ... mithin wird auch ein "review" durch Dritte unmöglich. Ich finde da jedenfalls keine Änderung im Code, die auf die Unterstützung von "CRYPTEDBINFILE" hinweisen würde.

Solltest Du das aber analog zur Berechnung für ein "BINFILE" implementiert haben (hier wäre die Implementierung in C zum Vergleich: https://github.com/PeterPawn/decoder/blob/master/src/exportfile.c#L155), dann wird es mit einiger Wahrscheinlichkeit auch funktionieren, wenn keine anderen Fehler dabei eingebaut wurden. Mangels Quelltext ist das halt für jemand anderen als Dich nicht zu sehen ... bliebe nur der Test mit dem fertigen Editor (und den mache ich nun mal nicht - ist eine Frage des Prinzips).

kARMU · 4 Apr 2018

Pikachu schrieb:
PS: Hier: FBEditor 0.6.9.7 eine Testversion, und keine Garantie ob es mit der Checksumme zum Type "CRYPTEDBINFILE" geht.

Den habe ich mal kurz getestet. Er funktioniert leider auch nicht.

Auch das verlinkte "exportsum.pl" Script aus https://www.ip-phone-forum.de/threa...ritzboxen-mit-dvb-c-richtig-berechnen.278904/ berechnet die Summe falsch.

PeterPawn · 4 Apr 2018

Die anderen Programme habe ich nicht selbst getestet, aber mein eigenes durchaus ... das berechnet auch für eine Export-Datei mit CRYPTEDBINFILE-Einträgen (von einer 6490 eben) die richtige Prüfsumme.

Ansonsten hat das Perl-File von hier: https://raw.githubusercontent.com/muhviehstah/FritzTools/master/exportsum/exportsum.pl auch bloß einen einzigen Fehler ... durch die zusätzliche Capture-Group in Zeile 38 (nach einem Vorschlag von mir, der zwar umgesetzt, aber nicht hinreichend getestet wurde, weil er noch eine weitere Änderung erfordert, auf die ich dort gar nicht eingegangen bin) steht der Dateiname (und der ist Bestandteil der Berechnung) jetzt halt in $2 ... wenn man Zeile 39 in "$file = $2;" ändert, funktioniert auch dieses Perl-Skript absolut korrekt.

Joe_57 · 4 Apr 2018

Vielen Dank @PeterPawn,
möglicherweise findest sich ja jetzt ein Pokemon (@Pikachu?), das eine neue Testversion des FB-Editors zusammenstellt...

Pikachu · 5 Apr 2018

Sorry, da das **** CRYPTEDBINFILE:dvb.cfg schon im April 2015 im
FBEditor 0.6.9.7 angepasst wurde, und auch bestätigt wurde dass es Funktioniert,
sowohl mit der Kabelbox und dem DVB-C-Repeater von dem mir Dankensweise
eine Original unveränderte Export Datei zum Testen zur verfügung gestellt wurde,
denn damit konnte man Testen ob der FBEditor die richtige Checksumme in die Datei schreibt,
und das ist doch ganz einfach man Exportiert die Datei aus der Fritzbox, macht eine
Kopie der Datei diese Öffnet man im FBEditor 0.6.9.7 und Speichert diese wieder
unverändert im FBEditor 0.6.9.7 ab, danach vergleicht man die Checksumme
beider Dateien, wenn sich diese nicht unterscheiden dann Berechnet der
FBEditor 0.6.9.7 die Checksumme korrekt, wenn nicht dann hat wohl AVM wieder was geändert,
und das kann man nur anpassen wenn man mir eine
Original unveränderte Export Datei zum Testen zur verfügung stellt.

PS: Der Quellcode auf Github wird von mir zur Zeit nicht mehr gepflegt darum
findet man dort auch keine Infos zu letzten änderungen, Sorrry.

PeterPawn · 5 Apr 2018

Jetzt habe ich die Binär-Version (bzw. nur das jar-File) dann doch mal selbst getestet (ein Heidenaufwand, dafür erst eine VM zu klonen und darin dann noch eine Java-Runtime zu installieren - ich weiß schon, warum ich das sonst nicht teste bzw. Java-Programmen aus dem Weg gehe) ... die angegebene Version 0.6.9.7 berechnet die Prüfsumme beim Speichern tatsächlich ebenfalls korrekt.

Was halt extrem verwirrend ist: Die neue Prüfsumme wird zwar in die Datei geschrieben (auch wenn das direkt auf die Box geladen wird, ist die Prüfsumme korrigiert), aber nicht im Editor-Fenster aktualisiert.

Wer sich die Quellen nicht irgendwann mal angesehen hat und daher die Mechanismen "im Inneren" auch kennt, der steht dann schon einigermaßen ratlos da ... und die Tatsache, daß bei neuer Firmware nicht auf aktivierte 2FA getestet wird (das Interface dazu ist recht simpel: https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_auth.pdf) und man keinerlei Information erhält, wenn die Box gerade auf die Bestätigung wartet (weil das GUI-Interface benutzt wird anstelle der "X_AVM-DE_GetConfigFile()"-Funktion auf der TR-064-Schnittstelle (https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceconfigSCPD.pdf), die dann einfach einen Fehler zurückgibt, wenn man bei aktivierter 2FA nicht autorisiert ist), ist schon reichlich verwirrend.

Wer den Download der Datei mehrfach mit dem Programm versucht, weil er keine Idee hat, wo das Problem liegen könnte, handelt sich auch schnell die drei Fehlversuche ein, nach denen man mit einer Stunde Nachdenk-Zeit belohnt wird. Ich weiß im Moment nicht mal, ob AVM das persistent speichert oder ob man dem auch mit "Steckerziehen" entgegenwirken kann.

Das Problem mit den automatischen Anmeldeversuchen, wenn die Daten dafür noch gar nicht vollständig vorliegen und den daraus jeweils resultierenden Fehlversuchen im Protokoll samt "Hochzählen" der Wartezeit, hatte ich an anderer Stelle schon mal angesprochen ... hier fiel es mir dann erneut auf, da eben keine XML-Datei mit den Angaben von zuvor genutzten Einstellungen vorlag.

Pikachu · 10 Apr 2018

T'ja nur mal zur Info wenn das noch keiner getestet hat aber es Funktioniert,
denn man kann auch noch die FBEditor Versionen 0.7.2/0.7.2.1/0.6.9.5/0.6.9.6/0.7.0.5/0.7.0.6
mit der Funktion **** CRYPTEDBINFILE:dvb.cfg Patchen ohne dass man es neu Compilieren muss.

Und das geht ganz einfach man nimmt 7Zip und Entpackt aus dem FBEditor 0.6.9.7
die Datei CalcChecksum.class, und Überschreibt dann mit dieser Datei mit 7Zip
im FBEditor 0.7.2.1 die darin enthaltene Datei CalcChecksum.class, danach kann dann auch der
FBEditor 0.7.2.1 die Checksumme zur Funktion **** CRYPTEDBINFILE:dvb.cfg Berechnen.

PS: Bitte beachten mit den alten FBEditor 0.7 / 0.6.9 geht es nicht da der Quellcode bei den Aktuellen Versionen Überarbeitet wurde.

Pikachu · 9 Mai 2018

PeterPawn schrieb:
Wer sich die Quellen nicht irgendwann mal angesehen hat und daher die Mechanismen "im Inneren" auch kennt, der steht dann schon einigermaßen ratlos da ... und die Tatsache, daß bei neuer Firmware nicht auf aktivierte 2FA getestet wird (das Interface dazu ist recht simpel: https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_auth.pdf) und man keinerlei Information erhält, wenn die Box gerade auf die Bestätigung wartet (weil das GUI-Interface benutzt wird anstelle der "X_AVM-DE_GetConfigFile()"-Funktion auf der TR-064-Schnittstelle (https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceconfigSCPD.pdf), die dann einfach einen Fehler zurückgibt, wenn man bei aktivierter 2FA nicht autorisiert ist), ist schon reichlich verwirrend.

Sorry, das liegt daran dass AVM keinen Fehlercode liefert, woran man es dann erkennen könnte,
stattessen kommt die OK Statusmeldung 200, was aber kein Fehler ist,
somit kommt eben mal nur die Meldung bei einen leeren String hier:
Beim Einlesen der Daten ist ein Fehler aufgetreten!

Eine Query.lua abfrage zur 2FA wird noch folgen für alle die UPNP nicht Aktiviert
haben, woran dann auch die Abfrage per UPNP ins leere geht, das kannst du ja schon mal Testen hier: FBEditor 0.6.9.7c

Ist UPNP aus bekommt man auch kein 2FA Status ob es Aktiv ist oder nicht.

Gruß Erwin

PeterPawn · 9 Mai 2018

@Pikachu:
Ich hatte ja Oliver mal angesprochen und um Klarstellung der Lizenz gebeten ... inzwischen hat er sich auf GPLv2 festgelegt und damit steht m.E. der kompletten Umstellung auf TR-064 nichts mehr im Weg. Die kleine "Kröte", daß man den Editor dann nur noch verwenden kann, wenn TR-064 eingeschaltet ist, kann man m.E. durchaus dem potentiellen Nutzer "servieren" ... ohne diese Funktionen geht bei anderen Apps (z.B. allen originalen von AVM) eben auch nichts. Das ist nun mal das "offizielle" API einer FRITZ!Box und wenn man mit einem (Dritt-)Programm auf die Box zugreifen will, braucht man eben diese Schnittstellen.

Wobei man die aktivierte 2FA ja auch über das GUI herausbekommt ... die "post.lua" für "userSet" aufrufen und die Checkbox für "twofactor_auth_enabled" lokalisieren - ist die "checked", ist 2FA aktiv. In dem Falle würde ich (ohne TR-064) dann gleich auf den Zugriff auf die Konfiguration verzichten und eine passende Fehlermeldung ausgeben.

Über TR-064 kann/könnte man die Session dann selbst per 2FA authentifizieren und dem Benutzer die zu wählende Folge anzeigen bzw. ihn zum "Knöppsche drügge" auffordern.

Ich bin nur im Moment an einer anderen Baustelle ... vielleicht kann man damit am Ende sogar eine "FBEditor - reloaded" basteln - ich mache halt gerade mit verschiedenen notwendigen "Basisklassen" in C# rum, damit man das alles mit der Box entweder über PS Core 6 (auch unter Linux oder MacOS und natürlich in Windows) oder mit PS 5.1 (dann nur in Windows) machen kann und zwar auch "plattformübergreifend" mit demselben Code.

Das kann zwar Java per se auch leisten, das ist aber auf jeder Plattform am Ende ein "Fremdkörper" und braucht überall denselben "Wartungsaufwand" durch den Benutzer (und das für ein Programm, was er vielleicht ein- oder zweimal im Jahr braucht) - ein "Vorwurf", den man PowerShell (zumindest auf Windows-Systemen und das dürfte immer noch die Mehrzahl aller PCs da draußen sein) nicht machen kann.

Wenn ich das richtig gesehen habe, fragst Du in der neuen Version jetzt über "GetInfo" das "NewEnabled" für 2FA ab ... das ist doch als erster Versuch genau das Richtige. Wenn man wirklich mal auf eine Box ohne TR-064 trifft, kann man über das GUI (s.o.) immer noch testen oder man legt sich eben fest, daß ohne TR-064 gar nichts gehen soll(!) - halte ich nicht für unangemessen.

Wobei der von Dir jetzt eingeschlagene Weg, das über unverschlüsselte HTTP-Abfragen auf Port 49000 zu machen, schon mit der nächsten FRITZ!OS-Version wohl wieder nicht funktionieren würde: https://www.ip-phone-forum.de/threads/tr-064-problem-e-mit-6-98-inhouse-labor.299082/ - da würde ich an Deiner Stelle schon den "NewSecurityPort" abfragen (auch wenn der bisher immer 49443 ist) und dann dort mittels HTTPS weitermachen.

Ich weiß auch nicht, wie Java da die "digest auth" genau macht (es gibt ja mehrere Möglichkeiten, was man alles in den Hash-Wert einberechnen kann (RFC 2617) - ob die FRITZ!Box da eine "client-side nonce" und "uri" tatsächlich "verträgt" bei "digest auth", weiß ich nicht) ... gut möglich, daß man da der Java-Klasse noch ein paar Hinweise mit auf den Weg geben muß.

Solange man ohnehin Benutzernamen und Kennwort hat, kann man hier ja auch ganz simpel mit "basic auth" arbeiten, weil die Daten beim Zugriff über Port 49443 ja ohnehin per TLS geschützt sind. Zu den Vor- und Nachteilen von "digest auth" und "basic auth" bei TLS (und der Frage, ob ich den ersten Hash speichere oder Benutzernamen und Kennwort) habe ich mit @fipsy im oben verlinkten Thread schon diskutiert.

Gerade für die Frage, warum der FBEditor nun mit der eigenen Box nicht funktionieren will, wäre vielleicht auch noch eine "Check-Liste" der abgefragten Daten der Box sinnvoll, so in der Art:

Code:

- Gerät unter der Adresse antwortet generell   <== ping oder HTTP-Request
- Gerät ist eine FRITZ!Box                     <== über jason_boxinfo.xml bzw. juis_boxinfo.xml ermitteln, "cgi-bin/system_status" könnte geschützt sein, "webcm" gibt's seit 06.2x nicht mehr (in normalen Versionen)
- Gerät braucht Login-Daten                    <== ja/nein/nur Kennwort, entsprechende Daten abfragen beim Benutzer
- TR-064 ist aktiviert
- 2FA ist aktiviert                                   
- Login über TR-064 versuchen
- ansonsten über's GUI (wenn TR-064 aus ist oder die Version zu alt)
[...]

Wenn der Benutzer "sehen" kann, bei welchem Test seine Box "durchfällt", ist es für ihn auch viel einfacher, das Problem selbst abzustellen - ggf. auch ohne Nachfrage bei anderen.

NDiIPP · 9 Mai 2018

PeterPawn schrieb:
Die kleine "Kröte", daß man den Editor dann nur noch verwenden kann, wenn TR-064 eingeschaltet ist, kann man m.E. durchaus dem potentiellen Nutzer "servieren" ...

Und wer TR-064 nicht nutzen möchte der kann ja immer noch die Exportdatei manuell herunterladen und im FBEditor öffnen, editieren, speichern und anschließend wieder auf manuellem Wege hochladen. Von daher dürfte der Nutzung von TR-064 imo nichts im Wege stehen.

betaman2 · 9 Mai 2018

@Picachu.

von mir soll auch ein Dank kommen, ich verwende noch die Version 0.6.9.7.exe !
Momentan mit Fritzbox 7490, FirmwareVersion=113.06.98.
Bisher habe ich den Editor zur Kontrolle und Sicherung der Einstellungen verwendet.
Werkzeug vermißt man erst dann, wenn etwas zu reparieren ist, bis dahin liegt es im "wo auch immer"!

Pikachu · 10 Mai 2018

Mal zur Info hier:

Code:

Properties Set using default values
position_top: 60
position_left: 60
position_height: 480
position_width: 680
(10.05.18 11:26:54): OS Language: de
(10.05.18 11:26:54): OS Country: DE
(10.05.18 11:26:54): Selected language: de_DE
(10.05.18 11:26:54): INFO: Loading locale: de_DE
(10.05.18 11:26:54): Java version: 1.8.0_152
Font: : Consolas
(10.05.18 11:27:00): DEBUG: HttpURLConnection: sun.net.www.protocol.http.HttpURLConnection:http://192.168.2.9/cgi-bin/webcm
(10.05.18 11:27:00): DEBUG: HttpURLConnection postdata: sid=0000000000000000&getpage=../html/login_sid.xml
(10.05.18 11:27:01): DEBUG: HttpURLConnection getResponseCode: 404
(10.05.18 11:27:01): DEBUG: HttpURLConnection getContentType: text/html; charset=utf-8
(10.05.18 11:27:01): DEBUG: HttpURLConnection encoding: utf-8 -> utf-8
(10.05.18 11:27:01): DEBUG: HttpURLConnection: sun.net.www.protocol.http.HttpURLConnection:http://192.168.2.9/login_sid.lua
(10.05.18 11:27:01): DEBUG: HttpURLConnection postdata: sid=0000000000000000
(10.05.18 11:27:02): DEBUG: HttpURLConnection getResponseCode: 200
(10.05.18 11:27:02): DEBUG: HttpURLConnection getContentType: text/xml
(10.05.18 11:27:02): DEBUG: HttpURLConnection: sun.net.www.protocol.http.HttpURLConnection:http://192.168.2.9/login_sid.lua
(10.05.18 11:27:02): DEBUG: HttpURLConnection postdata: page=/login_sid.lua&response=1ba9c83e-f1f6a17fb583194ca12532a9266d15e9&username=pikachu
(10.05.18 11:27:02): DEBUG: HttpURLConnection getResponseCode: 200
(10.05.18 11:27:02): DEBUG: HttpURLConnection getContentType: text/xml
(10.05.18 11:27:02): DEBUG: HttpURLConnection: sun.net.www.protocol.http.HttpURLConnection:http://192.168.2.9/cgi-bin/system_status
(10.05.18 11:27:02): DEBUG: HttpURLConnection postdata:
(10.05.18 11:27:02): DEBUG: HttpURLConnection getResponseCode: 200
(10.05.18 11:27:02): DEBUG: HttpURLConnection getContentType: text/html; charset=iso-8859-1
(10.05.18 11:27:02): DEBUG: HttpURLConnection encoding: iso-8859-1 -> iso-8859-1
Debug boxtype: 154
Authenticator.getRequestingPrompt(): HTTPS Access
Authenticator.getRequestingHost(): 192.168.2.9
Authenticator.getRequestingSite(): /192.168.2.9
Authenticator.getRequestingPort(): 49000
Authenticator.getRequestingScheme(): digest
Authenticator.getRequestingURL(): http://192.168.2.9:49000/upnp/control/x_auth
Authenticator.getRequestorType(): SERVER
Authenticator.getRequestingProtocol(): http

das bekomme ich beim Login zurück bei der 7590 06.92
und wie man sieht Erfolgt der UPNP Login bei der Abfrage zur 2FA per digest,
wenn das was hier: https://docs.oracle.com/javase/6/docs/technotes/guides/net/http-auth.html
dazu steht stimmt.

PeterPawn · 11 Mai 2018

Pikachu schrieb:
und wie man sieht Erfolgt der UPNP Login bei der Abfrage zur 2FA per digest,

Hier verstehe ich nicht, worauf Du hinauswillst.

Das oben Gezeigte hat ja mit UPnP nichts zu tun ... selbst wenn man (wie AVM es früher auch mal getan hat) die internen TR-064-Schnittstellen in diesen Kontext einordnen will.

Was ich in dem Protokoll sehe, ist (a) ein vergeblicher Zugriff auf "webcm", der mit "404" endet, weil die Datei nur noch in den Inhouse-Versionen überhaupt existiert.

Danach kommt (b) ein Aufruf der "login_sid.lua" ohne gültige SID - die Box antwortet korrekt mit "200" und passender XML-Struktur, wie es bei AVM beschrieben ist für das GUI-Login (auch wenn das lange "deprecated" ist, hat sich AVM noch nicht zum Entfernen dieser "login_sid.lua" entschlossen, die m.W. aber vom AVM-Code selbst gar nicht (mehr) verwendet wird): https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/Session-ID_deutsch_06Feb18.pdf - ja, AVM hat diese Beschreibung sogar noch einmal verbessert vor einem Vierteljahr. Man kann also wohl davon ausgehen, daß man sie als alternativen Weg des Zugangs verwenden kann - allerdings gibt es über das GUI eben keinen Zugriff auf 2FA-geschützte Funktionen, wenn 2FA auch aktiv ist ... dann muß man halt über TR-064 gehen.

In der XML-Struktur ist dann die Challenge der Box enthalten und deshalb kann der dritte Versuch (c) erfolgreich abgewickelt werden - am HTTP-Fehlercode kann man aber (b) und (c) ohnehin nicht unterscheiden, nur am Inhalt der XML-Daten ... besteht die dort enthaltene SID nur aus Nullen, ist sie nicht gültig (und man kann über diese "login_sid.lua" auch prüfen, ob eine bereits vorhandene SID noch gültig oder ob sie bereits abgelaufen ist).

Die letzte Abfrage (d) ist dann genauso "Standardkost", wie jede andere Seite in der Box - im Gegensatz zu den anderen Aufrufen unterhalb von "cgi-bin", bei denen praktisch immer HTTP-POST-Requests erwartet werden, reagiert "system_status" auch auf GET-Requests (das Shell-Skript dahinter kann sich ja jeder in der Firmware ansehen, im Gegensatz zu den anderen Dateien, die "echte" Binaries sind).

Hier hat also nach meiner Ansicht die Java-Klasse "Authenticator" gar nichts zu tun ... zumindest nicht im HTTP-Kontext.

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

Ich hatte nur bei einem Mitschnitt im LAN gesehen, daß Du jetzt nach diesen von Dir oben gezeigten Requests noch POST-Requests an den Control-Point "<fritzbox>:49000/upnp/control/x_auth" sendest.

Das ist eben aus zwei Gründen (zumindest potentiell) falsch in meinen Augen ... erstens beschreibt AVM selbst dort nur TLS-gesicherte Zugriffe (https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/AVM_TR-064_first_steps.pdf - u.a. Beispiel in Punkt 10.5) für alles, was über das "GetSecurityPort" hinausgeht und zweitens kann man das damit (zumindest theoretisch) auch von AVM aus jederzeit auf dieses "nur mit TLS erlaubt" umstellen.

Zeitweise wiesen die Ergebnisse im weiter vorne von mir verlinkten Thread schon darauf hin, auch wenn die am Ende wohl doch einfach falsch waren, weil die eigentliche Ursache mit dem fehlenden "Host"-Header erst später genauer untersucht wurde und die gilt sowohl für TLS (da auch noch als SNI) als auch ohne.

Auf diesen ersten Request (ohne Authorization im Header) kommt von der Box auch nur die Antwort:

Code:

HTTP/1.1 401 Unauthorized
Connection: keep-alive
Content-Length: 170
Content-Type: text/html
Pragma: no-cache
Server: Webserver
WWW-Authenticate: Digest realm="HTTPS Access",nonce="BC82150EAE885222",algorithm=MD5,qop="auth"

<HTML><HEAD><TITLE>401 Unauthorized (ERR_NONE)</TITLE></HEAD><BODY><H1>401 Unauthorized</H1><BR>ERR_NONE<HR><B>Webserver</B> Thu, 10 May 2018 10:28:35 GMT</BODY></HTML>

Hier "tarnt" sich also die Box noch einigermaßen ("Webserver" als eigene Identität) und fordert zur Authentifizierung auf.

Das erfolgt aber dann (sicherlich automatisch seitens der "Authenticator"-Klasse in Java) mit ganz schwerem Geschütz (siehe "Authorization"-Header):

Code:

POST /upnp/control/x_auth HTTP/1.1
USER-AGENT: AVM UPnP/1.0 Client 1.0
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: urn:dslforum-org:service:X_AVM-DE_Auth:1#GetInfo
Connection: close
Cache-Control: no-cache
Pragma: no-cache
Host: 192.168.XXX.1:49000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 271
Authorization: Digest username="", realm="HTTPS Access", nonce="BC82150EAE885222", nc=00000001, uri="/upnp/control/x_auth", response="86683b49f9ea06afb0b5df8612xxxxxx", algorithm=MD5, cnonce="GCBEACMFJIEIIMPLABCEPCOPGNKJCPHPGPBLKBLL", qop=auth

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body><u:GetInfo xmlns:u="urn:dslforum-org:service:X_AVM-DE_Auth:1">
</u:GetInfo>
</s:Body>
</s:Envelope>
---------------------------------------------------------------
HTTP/1.1 401 Unauthorized
Connection: keep-alive
Content-Length: 170
Content-Type: text/html
Pragma: no-cache
Server: Webserver
WWW-Authenticate: Digest realm="HTTPS Access",nonce="5818BB6825E0B4A8",algorithm=MD5,qop="auth"

<HTML><HEAD><TITLE>401 Unauthorized (ERR_NONE)</TITLE></HEAD><BODY><H1>401 Unauthorized</H1><BR>ERR_NONE<HR><B>Webserver</B> Thu, 10 May 2018 10:28:35 GMT</BODY></HTML>

Das hier gleich mit "nc" (nonce-count), "uri" (domain) und einer "cnonce" (client nonce) zu machen, ist zwar RFC-konform (zur neuen Version in RFC 2617), aber es gibt auch dort (siehe Punkt 3.2.2 im RFC) eigentlich noch Möglichkeiten zur Rückwärtskompatibilität mit der alten Version in RFC 2069. Ich hatte halt aufgrund nachfolgender Beobachtungen die Befürchtung (die sich als falsch erwiesen hat), daß die FRITZ!Box hier nur die einfachere Form versteht.

Fakt ist nämlich erst einmal, daß sich der AVM-Server auch hier relativ unbeeindruckt zeigt vom Versuch der Authentifizierung ... da hätte es genauso gut sein können, daß er die Authentifizierung gar nicht versteht (je nach verwendeten Parametern aus diesem Header ergibt sich ja ein anderer Ausgangswert beim Zusammensetzen der Zeichenketten für das Hashen mit MD5) und daher nichts damit anfangen kann - das war zumindest eine halbwegs plausible Vermutung, warum da bei mir auf Port 49000 nur Fehlversuche zu sehen waren.

Denn die Java-Klasse versuchte es dann gleich noch einmal, diesmal mit einem zusätzlichen "username" im Header, der aber hier noch leer ist, weil er gar nicht abgefragt wurde (ich starte den Editor ohne Voreinstellungen und er fragt (Offenbar von Dir inzwischen geändert? Oder war das schon immer so?) erst einmal nur die Adresse und das Kennwort - sequentiell - ab) und damit kann die Box dann auch noch nichts anfangen (obwohl das Login ins GUI per "login_sid.lua" aufgrund einer Besonderheit ("remote_access_user = xx;" in der "ar7.cfg", noch aus den "ganz alten Zeiten") zuvor auch ohne Benutzernamen geklappt hatte):

Code:

[...]
Authorization: Digest username="", realm="HTTPS Access", nonce="5818BB6825E0B4A8", nc=00000001, uri="/upnp/control/x_auth", response="6752bc0445edcf92c31ad7dbba29c855", algorithm=MD5, cnonce="JJGJLLNAIOCNMFLAKABEDECNNJIPAJPGAOAGJFLI", qop=auth
[...]
HTTP/1.1 401 Unauthorized
[...]
WWW-Authenticate: Digest realm="HTTPS Access",nonce="0B47A532B2FB906A",algorithm=MD5,qop="auth"

Der Server ändert also lediglich stoisch seine "nonce" ... mehr erreicht dieser Zugriff nicht. Der FBEditor versucht(e) das aber nun in aller Gelassenheit noch ein paar Mal, solange bis der AVM-Server die Geduld verliert und anstelle von "401" mit "500" antwortet:

Code:

POST /upnp/control/x_auth HTTP/1.1
USER-AGENT: AVM UPnP/1.0 Client 1.0
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: urn:dslforum-org:service:X_AVM-DE_Auth:1#GetInfo
Connection: close
Cache-Control: no-cache
Pragma: no-cache
Host: 192.168.XXX.1:49000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 271
Authorization: Digest username="", realm="HTTPS Access", nonce="AC724FE964895B0F", nc=00000001, uri="/upnp/control/x_auth", response="8dea3f6859a1ae2294b83c0110xxxxxx", algorithm=MD5, cnonce="FJKHEDOGDKFLCIOKPGLPNNCEEEOJBCIHGAGECGFL", qop=auth

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body><u:GetInfo xmlns:u="urn:dslforum-org:service:X_AVM-DE_Auth:1">
</u:GetInfo>
</s:Body>
</s:Envelope>
-------------------------------------------------------
HTTP/1.1 500 Internal Server Error
DATE: Thu, 10 May 2018 10:28:35 GMT
SERVER: FB7490 UPnP/1.0 AVM FRITZ!Box 7490 113.06.92
CONNECTION: close
CONTENT-LENGTH: 429
CONTENT-TYPE: text/xml; charset="utf-8"

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:dslforum-org:control-1-0">
<errorCode>401</errorCode>
<errorDescription>invalid action</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

Putzig ist hier einerseits, daß der AVM-Server dermaßen die Nerven verliert, daß er auf seine "Tarnung" als "Webserver" verzichtet, die Maske fallen läßt und voller Ärger kundtut, daß man so mit "FB7490 UPnP/1.0 AVM FRITZ!Box 7490 113.06.92" nicht umspringen darf.

Andererseits ist das Ergebnis dann (nur rein durch den Start des Editors ohne Voreinstellungen und die Eingabe von Adresse und Kennwort - ohne Benutzer, weil der nicht abgefragt wurde) auch das folgende Bild im Event-Log der Box:

(Ich habe hier mal ausnahmsweise das Vollbild eingefügt, weil die Vorschau doch sehr winzig und z.B. bei Touch-Bedienung kaum gezielt zu erreichen ist.)

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

Ein wenig liegt das Problem am FBEditor (der den Benutzernamen nicht abfragt) und ein wenig auch am FRITZ!OS in der von mir verwendeten Version und Konfiguration. Denn wenn der Benutzername korrekt ist, funktioniert es (unter 06.92) auch tatsächlich, den Status der 2FA über eine unverschlüsselte Verbindung per TR-064 abzufragen:

Code:

POST /upnp/control/x_auth HTTP/1.1
USER-AGENT: AVM UPnP/1.0 Client 1.0
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: urn:dslforum-org:service:X_AVM-DE_Auth:1#GetInfo
Connection: close
Cache-Control: no-cache
Pragma: no-cache
Host: 192.168.XXX.1:49000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 271
Authorization: Digest username="xxx", realm="HTTPS Access", nonce="DA2304CF8101652A", nc=00000001, uri="/upnp/control/x_auth", response="e171162211b593f540c207c07fxxxxxx", algorithm=MD5, cnonce="BKPNKHDPODHHBHMPJPJFDNJOGFAFNDKGKJFEGNKC", qop=auth

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body><u:GetInfo xmlns:u="urn:dslforum-org:service:X_AVM-DE_Auth:1">
</u:GetInfo>
</s:Body>
</s:Envelope>
------------------------------------------------------
HTTP/1.1 200 OK
DATE: Thu, 10 May 2018 11:24:46 GMT
SERVER: FB7490 UPnP/1.0 AVM FRITZ!Box 7490 113.06.92
CONNECTION: close
CONTENT-LENGTH: 298
CONTENT-TYPE: text/xml; charset="utf-8"
EXT:

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetInfoResponse xmlns:u="urn:dslforum-org:service:X_AVM-DE_Auth:1">
<NewEnabled>0</NewEnabled>
</u:GetInfoResponse>
</s:Body>
</s:Envelope>

Die "volle" Digest-Authentifizierung stört die Box also offenbar nicht, das versteht der AVM-Server dann doch.

Aber trotzdem sollte man diese Zugriffe nur über TLS abwickeln, wenn es denn möglich ist - schon damit die übertragenen Daten geschützt sind. Das sind sie nämlich ansonsten nicht wirklich (über "firmwarecfg"), weil im Request das Export-Kennwort im Klartext nachzulesen ist und in der Response dann die damit verschlüsselte Einstellungsdatei. Das läßt sich dann ganz simpel von jedem "Lauscher" wieder entschlüsseln:

https://www.ip-phone-forum.de/threa...verschlüsselung-für-die-einstellungen.295101/

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

Jedenfalls wird bei der 7490 (wenn ich alles zuvor von Hand schon eingestellt hatte, auch den Benutzernamen) dann beim erneuten Aufruf auch ordentlich erkannt, daß die 2FA aktiv ist und das Einlesen daran scheitert. Bei der 6490 (Retail, 06.83) gibt das hingegen nach der TR-064-Abfrage neue Späne ... der FBEditor (die vorne verlinkte Version) verzieht sich in eine Warteschleife (keine CPU-Belastung) und wartet da auf irgendetwas Unbekanntes - das GUI reagiert jedenfalls gar nicht und auch der Versuch, den Editor zu schließen, endet dann nur mit dem Abbruch der zu diesem Zeitpunkt noch offenen TCP-Verbindung zum Port 80 der Box (die wird ja mehrfach genutzt, ist HTTP/1.1). Ansonsten wartet der Editor munter weiter und ich muß den Prozess abschießen. Das aber wieder nur dann, wenn die Zugangsdaten bereits zuvor hinterlegt wurden ... trage ich die erst "frisch" ein, erkennt er sogar bei der 6490 die aktivierte 2FA richtig.

Hingegen kommt - wenn man zwar die IP-Adresse einer existierenden FRITZ!Box angibt, aber kein Kennwort und keinen Benutzernamen - auch schon mal die Fehlernachricht, daß die Box nicht gefunden würde ... obwohl deutlich im LAN-Mitschnitt zu sehen ist, daß da Kommunikation stattfindet.

Das meinte ich weiter oben mit einer "Check-Liste", anhand derer der Benutzer wirklich sehen kann, welcher Schritt fehlschlägt ... denn diese Fehlernachricht bei fehlendem Kennwort und fehlendem Benutzernamen verwirrt natürlich einigermaßen, denn die Box wurde ja in Wahrheit doch gefunden.

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

Ich würde also folgende Änderungen empfehlen (ohne in den Quelltext zu schauen, was davon schon vorgesehen ist und vielleicht nur nicht richtig funktioniert):

(A) Prüfen der SID, die von "login_sid.lua" zurückkommt - die sollte eben nicht nur aus Nullen bestehen (ansonsten stimmen die Login-Daten nicht) und auch den tatsächlichen Rechten des Nutzers (unter "Admin" in der XML-Struktur) sollte man noch einen Blick gönnen ... selbst wenn der (korrekt angemeldete) Benutzer da keine Rechte hat:

Code:

<?xml version="1.0" encoding="utf-8"?><SessionInfo><SID>4e5c8266a1e54b84</SID><Challenge>8272a06a</Challenge><BlockTime>0</BlockTime><Rights><Name>NAS</Name><Access>2</Access></Rights></SessionInfo>

, versucht der Editor es trotzdem erst mal. Auch das Berücksichtigen von "BlockTime" wäre nicht sooo verkehrt ... selbst wenn Benutzername und Kennwort korrekt sind, wird es eben keine gültige Anmeldung geben, solange der Wert bei "BlockTime" größer als 0 ist. Der kann ja durchaus auch von irgendjemand anderem in die Höhe getrieben worden sein bzw. werden - wenn man hier trotzdem den eingegebenen Benutzernamen und das Kennwort in Zweifel zieht dank falscher Fehlermeldungen, verwirrt das nur noch zusätzlich.

(B) Am besten wäre es sogar, wenn man erst einmal nur über TR-064 versucht, die Box zu erreichen ... dann erkennt man auch an der ersten Antwort bereits, ob TR-064 nun ein- oder ausgeschaltet ist (hier ist es generell ausgeschaltet als Beispiel):

Code:

POST /upnp/control/deviceinfo HTTP/1.1
SOAPACTION: urn:dslforum-org:service:DeviceInfo:1#GetSecurityPort
Content-Type: text/xml; charset="utf-8"
Host: 192.168.XXX.1:49000
Content-Length: 262
Expect: 100-continue
Connection: Keep-Alive
-----------------------------------------------------------------
HTTP/1.1 100 continue
-----------------------------------------------------------------
<?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:GetSecurityPort xmlns:u="urn:dslforum-org:service:DeviceInfo:1"></u:GetSecurityPort></s:Body></s:Envelope>
-----------------------------------------------------------------
HTTP/1.1 500 Internal Server Error
DATE: Thu, 10 May 2018 16:33:55 GMT
SERVER: FB7490 UPnP/1.0 AVM FRITZ!Box 7490 113.06.92
CONNECTION: keep-alive
CONTENT-LENGTH: 433
CONTENT-TYPE: text/xml; charset="utf-8"

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>401</errorCode>
<errorDescription>Invalid Action</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

(C) Begrenzen der Anzahl der Fehlversuche bei irgendeiner Anmeldung - leider stellt AVM keine klare Information bereit (zumindest kenne ich kein derartiges Interface, was man auch ohne vorherige Anmeldung abfragen könnte und "LANConfigSecurity" hilft hier auch nicht richtig weiter), ob der eingestellte Anmelde-Modus nun einen Benutzernamen und ein Kennwort braucht oder nur ein Kennwort. Aber man kann sich hier mit einem Kniff helfen und aus dem HTML-Inhalt der ersten Seite beim direkten Aufruf des GUI die notwendigen Daten extrahieren (mal mit einer Linux-Shell als Beispiel):

Code:

vidar:~ # wget -qO- http://192.168.XXX.1 | sed -n -e "s|^var data = \(.*\);\$|\1|p" | jq -C "{ WAN: .fromInternet },{ Users: .activeUsers }"
{
  "WAN": false
}
{
  "Users": [
    [],
    [],
    [],
    []
  ]
}

Aus diesen JSON-Variablen interessieren eigentlich nur die Werte für "activeUsers" und "fromInternet" (oben von mir "umbenannt" in "Users" und "WAN") ... beim Aufruf aus dem LAN (fromInternet: false) und leerem Array bei "activeUsers" (wobei "leer" nicht ganz stimmt, weil AVM da zumindest auch die Anzahl der vorhandenen Benutzerkonten verrät durch die Anzahl der leeren Einträge) steht die Box auf "Anmeldung nur mit dem Kennwort", beim Zugriff aus dem Internet ist immer ein Benutzername erforderlich (der betreffende Benutzer braucht dann auch noch die passenden Rechte für einen solchen Zugriff) und da bei der Umschaltung auf "Anmeldung mit Benutzername und Kennwort" mindestens ein Benutzer angelegt sein muß, ist das Array aus dem LAN heraus dann nicht leer (eigentlich ein Security-Problem, weil das "Erraten" eines gültigen Benutzernamens wegfällt - aber das macht es (komme ich gleich drauf) unter bestimmten Umständen ohnehin).

Bei "Keine Anmeldung erforderlich" (der dritten möglichen Einstellung) liefert die "login_sid.lua" auch dann eine gültige SID, wenn man keine Zugangsdaten angegeben hat ... das kriegt man aber auch über TR-064 mit "LANConfigSecurity::X_AVM-DE_GetAnonymousLogin()" heraus - gleichzeitig wüßte man mit einer solchen TR-064-Abfrage auch sofort, ob das TR-064 nun ein- oder ausgeschaltet ist, wenn man nicht zuvor (wie oben angeführt) mit "GetSecurityPort()" schon Schiffbruch erlitten hat.

Zumindest die Fehlversuche, die sich aus fehlendem Benutzernamen i.V.m. einem Kennwort ergeben, kann man damit verhindern ... auch ein Beitrag zur "Hygiene" im Event-Log der Box, wo die (erfolgreiche) Anmeldung ja ohnehin vermerkt wird. Daher sollte man sich auch eine einmal erhaltene SID solange merken, wie man sie verwenden kann/will ... ständig wiederholte Logins mit entsprechenden Log-Einträgen sind auch nicht das Gelbe vom Ei.

(D) Einfach wirklich konsequent TLS für den Zugriff auf die Box mittels TR-064 verwenden, wann immer das möglich ist ... das schützt auch die übertragenen Daten im LAN vor neugierigen Blicken.

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

Der Widerspruch, der den FBEditor ganz oben in diesem Beitrag bei mir so "verwirrte", existiert allerdings (m.W.) tatsächlich nur bis Firmware 06.92 - bis zu dieser Version (inkl.) ignoriert nämlich der "ctlmgr" beim Login noch die Forderung nach dem Vorhandensein von Benutzername und Kennwort, wenn in der "ar7.cfg" im "boxusers"-Abschnitt ein Eintrag "remote_access_id = 98;" existiert (ob die Nummer wirklich unbedingt 98 sein muß, habe ich nie bis zum Ende getestet - dieser Eintrag stammt bei mir noch aus den Anfangszeiten der Benutzerverwaltung) und es einen Benutzer mit dieser ID gibt, der auch noch volle Rechte auf der Box hat (und zwar inkl. Admin-Rechten aus dem Internet, wenn ich mich richtig erinnere), dann akzeptiert die Box auch Anmeldungen mit dessen Kennwort, ohne daß man den entsprechenden Benutzernamen kennen muß.

Das fällt halt beim "normalen" Login übers GUI per Browser nicht weiter auf, weil da ja gleich die Felder passend vorhanden sind in Abhängigkeit vom Anmeldemodus und man ohne die Angabe des Namens meist gar kein Login senden kann ... aber es ist bei mir ein absolut reproduzierbares Phänoment bis zur 113.06.92 und ab der 06.93 dann auch verschwunden. Mal sehen, wann/ob AVM hier "Farbe bekennt" bzw. ob man das dort überhaupt bewußt gefixt hat oder es mehr eine glückliche Fügung war, daß dieses Problem beseitigt wurde.

Jedenfalls ist das auch keine ganz normale Situation für den Editor ... trotzdem sollte er die auch meistern und das heißt eben, daß er den Anmeldemodus korrekt erkennen sollte und auch bei funktionierendem Login über "login_sid.lua" ohne Benutzernamen nicht automatisch davon ausgehen sollte, daß das bei TR-064 auch so klappt. Ich bin vermutlich nicht wirklich der Einzige, der eine solche Konfiguration hat und sie (schon zu Test- bzw. Vergleichszwecken zwischen AVM-Versionen) gerne mal wiederherstellt:

Code:

POST /login_sid.lua HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_161
Host: 192.168.XXX.1
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 20

sid=0000000000000000
--------------------------------------------------------------------------
HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/xml
Keep-Alive: timeout=60, max=300

<?xml version="1.0" encoding="utf-8"?><SessionInfo><SID>0000000000000000</SID><Challenge>e8837a18</Challenge><BlockTime>0</BlockTime><Rights></Rights></SessionInfo>
--------------------------------------------------------------------------
POST /login_sid.lua HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_161
Host: 192.168.XXX.1
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 80

page=/login_sid.lua&response=e8837a18-64862f5958bb6654b2b2882243357cc1&username=
--------------------------------------------------------------------------
HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/xml
Keep-Alive: timeout=60, max=300

<?xml version="1.0" encoding="utf-8"?><SessionInfo><SID>0253ea26b101c994</SID><Challenge>0f937981</Challenge><BlockTime>0</BlockTime><Rights><Name>Dial</Name><Access>2</Access><Name>App</Name><Access>2</Access><Name>HomeAuto</Name><Access>2</Access><Name>BoxAdmin</Name><Access>2</Access><Name>Phone</Name><Access>2</Access><Name>NAS</Name><Access>2</Access></Rights></SessionInfo>
--------------------------------------------------------------------------
GET /cgi-bin/system_status HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.8.0_161
Host: 192.168.XXX.1
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
--------------------------------------------------------------------------
HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-type: text/html; charset=iso-8859-1
Keep-Alive: timeout=60, max=300

<html><body>FRITZ!Box 7490-B-152209-030809-642547-367130-197902-1130693-48385-avm</body></html>

Die Box oben hat jedenfalls den Modus "Benutzername und Kennwort benötigt" aktiviert und trotzdem kann man im zweiten Request sehen, daß die Anmeldung erfolgreich ist, obwohl gar kein Benutzername angegeben wurde (und ja, die hat in den 3,75 Jahren ihres Lebens erst 809 Restarts hingelegt) - glücklicherweise klappt(e) dieses Login ohne Benutzernamen aber auch von der WAN-Seite dann nicht, wenn ich mich richtig erinnere.

Daher auch mein Vorschlag, zuerst den tatsächlich verwendeten Anmeldemodus zu ermitteln und dann das erste Login überhaupt erst zu versuchen, wenn alle benötigten Daten beisammen sind.

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

Sorry, ist länger geworden als gedacht (und bei den Merkwürdigkeiten beim Login mehr Erfahrungsbericht als FBEditor-Problem, selbst wenn der das berücksichtigen sollte) ... ich habe das (mit größeren Unterbrechungen) den halben Tag lang geschrieben und gar nicht bemerkt, wie es immer mehr wurde.

Aber man könnte eben noch so einiges tun, um den FBEditor etwas mehr an die Gegenwart bei den FRITZ!Boxen anzupassen ... das dürfte auch nach wie vor sein Hauptanwendungsgebiet sein, denn die meisten Benutzer werden sicherlich heutzutage die Konfiguration einer eigenen FRITZ!Box mit einer halbwegs aktuellen Version bearbeiten und nicht irgendwelche Dateien (oder alten Boxen) von vor vier und mehr Jahren.

FBEditor braucht man den denn Überhaupt noch?!

FBEditor braucht man den denn Überhaupt noch ?

Danke, dass es den FBEditor noch gibt

Bei mir Funktioniert er noch

Bei mir Funktioniert er nicht, warum Schreibe es in den Beitrag dazu

Bei mir geht der FBEditor nur noch mit Checksumme ab Firmware xxx.06.xx

Ja, es soll noch weitere Versionen geben sofern Anpassungen zur Firmware noch möglich sind

Ja, es kann die Entwicklung dess FBEditors eingestellt werden

Ja, er sollte ab mindestens Java 1.6 Funktionieren

Nein, er sollte ab mindestens Java 1.7 Funktionieren

Bei mir Funktioniert er noch, auch mit einer OEM Box(Speedport usw.)

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Aktives Mitglied

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Promi

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Aktives Mitglied

IPPF-Urgestein

IPPF-Promi

Mitglied

Aktives Mitglied

IPPF-Urgestein

Statistik des Forums