[Info] FRITZ!Box 7590 / FRITZ!OS 8.25

Die Labor läuft bei mir völlig problemlos.
 
  • Like
Reaktionen: Deleted member 479035
Warum soll das ein Fehler gewesen sein? 7590 mit 2400 läuft hier an einem Telekom Anschluss ohne Probleme.
 

Anhänge

  • IMG_8308.jpeg
    IMG_8308.jpeg
    259.1 KB · Aufrufe: 93
  • IMG_8309.png
    IMG_8309.png
    404.8 KB · Aufrufe: 91
Wenn man, so wie ich, diese IMHO für ONU wirklich sinnvollen Dienste wirklich nicht benötigt, kann man das an der o.g. Stelle jederzeit problemlos tun. Und selbst, wenn man bspw. bei einer Störung, einen Fritz-Dienst benötigt, ist das nach der erneuten Zustimmung auch jederzeit wieder möglich.
 
Habe gerade einen Schreck gekriegt meine 7590 zeigt zur Repeaterbox 7530 und dem Repeater 2400 im 2,4GHz-Band sehr niedrige Verbindungswerte an, sollte das WLAN sterben? Dann bemerkt, dass sind die Uploadwerte der Repeater, die Downloadwerte sind normal hoch. Habe ich was verpasst..? Änderung der Anzeige..? Alle anderen, direkt mit der 7590 verbundenen Geräte zeigen normale Werte an...
EDIT: Nach Neustart alles wieder ok...
 
Zuletzt bearbeitet:
fritzbox_reconnect.sh basiert wie viele anderen Funktionen auf UPnP und funktioniert nur noch von lokalen IPs aus mit aktivierter Option "Selbstständige Portfreigaben und das Trennen und Wiederherstellen der Internetverbindung für dieses Gerät erlauben".
Dass man die nützliche Funktion "reconnect" mit dem risikoreichen "Selbstständige Portfreigaben ... erlauben" kombiniert, erzeugt bei mir einen leichten Brechreiz.
Hat eigentlich schon jemand ein Ticket bei AVM aufgemacht um das hierdurch entstehende Sicherheitsrisiko zu rügen ? Denn selbstständige Portfreigaben sind per se ein Sicherheitsrisiko, weil jeder Virus sich dadurch Ports öffnen kann. Daher sollte die Reconnect-Funktion auf jeden Fall separat einstellbar sein, ohne gleichzeitig Portfreigaben zu erlauben.

Alternativ: Gäbe es eine Möglichkeit daß sich ein Script mit den Zugangsdaten auf der Fritz!box einloggt und dort die Funktion zur Neuverbindung auslöst ? Also praktisch so, als ob ich im Browser auf die Webseite gehen wurde und dort "Neu verbinden" anklicke ? Hierdurch liese sich das Problem ja umgehen, weil dann nicht mehr das Gerät im LAN, sondern die FB selber den Recconect auslöst.
 
Gäbe es eine Möglichkeit daß sich ein Script mit den Zugangsdaten auf der Fritz!box einloggt und dort die Funktion zur Neuverbindung auslöst ?

Allerdings sind die ForceTermination-Funktionen (oder auch RequestConnection) auf verschiedene Interfaces verteilt, je nach Typ des WAN-Zugangs. Warum es da keine entsprechende Funktion auf dem common-Interface gibt (afaik ist das immer noch der Fall), versteht so mancher Nutzer (dieser Schnittstellen) nicht.
 
Nun ist es aber so, dass AVM/Fritz genau beim Reconnect per TR-064-Zugriff die Rechte auf lokale und eben über die seltsam gefährliche Berechtigung zugelassene Geräte beschränkt hat.
Da die Berechtigung nur für meinen Home-Assistant-Mini-PC erteilt ist, wo ich eine um Längen bessere Kontrolle über das OS habe als über meine Windows-Gurken, sehe ich das als nicht ganz so gefährlich aber immer noch als bedenklich an. Ein funktionierender Script müsste also über die Web-UI gehen.
 
Genau daran dachte ich, Ich habe die Google KI mal dazu befragt, und die nennt die nötige Vorgehensweise "web scraping". Sie hat mir auch ein python Script mit einem Modul namens Selenium ausgespuckt, welches ich aber nicht getestet habe. Dieses Script arbeitet so, daß es entweder den Edge oder den Firefox startet und dem Browser dann sagt, was er machen soll. Nun hat aber unter Windows nicht jeder python installiert. Daher wäre meine Idealvorstellung ein Shell-Skript (Powershell oder bash), welches das Verhalten des Browsers simuliert um auf der Weboberfläche der FB den richtigen Knopf zu drücken. Aber ich kenne mich nicht gut genug damit aus um so etwas selber programmieren zu können.
 
die nennt die nötige Vorgehensweise "web scraping"
So einen Schwachsinn kann auch nur eine KI verzapfen, zumindest im Kontext des FRITZ!OS, von dem (genauer: dessen GUI-Funktionen) sie offenbar keinen Schimmer hat.

Erstens ist es gar nicht (mehr) erforderlich, irgendwelche HTTP-(GET-)Requests (abseits der Anmeldung zur Erzeugung einer gültigen Session-ID) an die Box zu senden, um HTML-Inhalte (egal ob statisch oder dynamisch, wobei das ganze GUI ja mittlerweile eher eine "single page application" ist und damit "scraping" (zumindest "statisches") ohnehin Blödsinn ist, denn die Inhalte im DOM des Browsers werden alle dynamisch erzeugt) zu erhalten - man kann genauso gut direkt die Requests absetzen, die die anzuzeigenden Daten (als Response im JSON-Format) erst einsammeln, die dann ins DOM eingebastelt werden.

Zweitens hat AVM seit einiger Zeit auch ein JSON-basiertes (Aktions-)Interface ins FRITZ!OS eingebaut (https://www.ip-phone-forum.de/threads/fritzbox-7590-ax-steuern-via-skript.324286/post-2635595) und wenn im GUI der "Neu verbinden"-Button gedrückt wird, werden da nacheinander zwei (PUT-)Requests an die Box gesendet (dafür braucht es einen passenden Header: AUTHORIZATION: AVM-SID <sid> im Request, die sid für die Sitzung (mit einem Konto mit administrativen Rechten) muß man ggf. zuvor erzeugen - wie das geht, steht bei AVM: https://fritz.support/resources/HTTP_Session-ID_DE.pdf), der erste mit dem (JSON-)Kommando
JSON:
{
    "cmd_disconnect": "1"
}
und danach (logischerweise) ein weiterer mit
JSON:
{
    "cmd_connect": "1"
}
... ob der zweite tatsächlich erforderlich ist, wenn andere Clients im LAN Daten anfordern aus dem Internet, sei mal dahingestellt.

Man kann also auch einfach diesen (oder diese beiden) PUT-Request(s) auslösen (wie geschrieben, muß dafür eine SID erzeugt werden und vermutlich sollte der Content-Type-Header auch den Payload als application/json ausweisen, sicher ist sicher) und die Box sollte sich genauso verhalten (vielleicht muß man noch ein kurzes Delay zwischen beiden Aufrufen einbauen, wobei das bei AVM auch nicht der Fall ist:
Javascript:
reconnect = async() => {
  const LX = a96i;
  await a96g[LX(407)](baseUrl, {
    'cmd_disconnect': '1'
  }),
  await a96g[LX(407)](baseUrl, {
    'cmd_connect': '1'
  });
},
), als wenn da jemand den oben erwähnten Button gedrückt hätte.

In PowerShell sähe das dann in etwa so aus (nur die Trennung wird gezeigt und die SID war auch aus dem Browser kopiert):
C-ähnlich:
PS C:\Users\XXX> $hdr = @{ Authorization = "AVM-SID 5883faae68b23511" }

PS C:\Users\XXX> Invoke-WebRequest -Uri "http://192.168.65.1/api/v0/generic/connections" -Method PUT -Body '{"cmd_disconnect":"1"}' -ContentType "application/json" -Headers $hdr

StatusCode        : 200
StatusDescription : OK
Content           : {}
RawContent        : HTTP/1.1 200 OK
                    Connection: Keep-Alive
                    Transfer-Encoding: chunked
                    Pragma: no-cache
                    Keep-Alive: timeout=60, max=300
                    X-Frame-Options: SAMEORIGIN
                    X-Content-Type-Options: nosniff
                    Content-Security-P...
Forms             : {}
Headers           : {[Connection, Keep-Alive], [Transfer-Encoding, chunked], [Pragma, no-cache], [Keep-Alive, timeout=60, max=300]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : System.__ComObject
RawContentLength  : 2

PS C:\Users\XXX>
Alles keine "rocket science" und dafür einen Browser "fernsteuern" zu wollen (inkl. der Tatsache, daß der ja dann auch sein JavaScript ausführen muß, ansonsten bleibt das DOM nur der Rumpf), ist (1) nicht erforderlich, wie gezeigt, und (2) eine wirklich blöde Idee in meinen Augen.
 
Hallo an die Community
Als neuer User mein Problem, das mir schon den Pfingstmontag gekostet hat.
AVM hat mir heute Nacht das OS 8.25 auf die FritzBox 7590 aufgespielt (vorher 8.21). Ich habe an der 7590 4 Stk. Repeater 600 (Soft 8.25) als Kette dran. WiFi 6GHz ist deaktiviert, ebenso der automatische Kanalwechsel.
Das eigentliche Problem ist folgendes: Nach dem Update wardie Mesh Struktur der Repeater voellig weg, jetzt sind sogar die Repeater aus dem lokalen Netz verschwunden.
Ich habe die Repeater mit Reset auf Werkseinstellung und Einbinden ins Mesh wieder ins Rennen bekommen, aber 1..2h spaeter ist alles wieder weg, yuerst sieht man die Repeater noch als Nicht-Mesh Geraetem, Minuten spaeter sind die komplett verschwunden (und natuerlich auch meine ESP32, die ueber die Repeater verbunden sind).

Das ist mit der 7590 und den 4 Repeater 600 mit dem FritzOS 8.21 im letzten halben Jahr nie passiert.
Passt zwar nicht in die laufende Unterhaltung, aber der Threat trifft es ja genau,
Hat jemand einen Tip oder aehnliche Erfahrungen ??
Vg Matthias
 
Mach alle deine Repeater stromlos und alle 2 Minuten häng einen nach dem andern in der Kette wieder an.
 
Danke für den Hinweis. dann würde ich die "Intelligente Vernetzung" sofern aktiviert einmal testweise deaktivieren. Gerade bei Repeaterketten kann es dort zu Problemen kommen.
 
Des Pudels Kern ist aber eher hier im Forum zu finden denn in irgendeiner einer KI.
Hier hats nämlich zuerst begonnen und wurde auch hier analysiert und schlußendlich auch gelöst von 2 Usern.
 
Hallo, habe hier eine 7590 mit FW 8.25 an einem Telekom Regio Anschluss (VDSL50 ca. 358m) im Einsatz. Eher durch Zufall habe ich im Log sporadisch DSL Sync Verlust mit anschliessend direkter Neuverbindung gesehen. Das passierte so ziemlich jeden Tag zu unterschiedlichen Zeiten, bisher aber nie beim Telefonieren bzw bei Internetnutzung. Daher wurde es nicht bemerkt. Bis zur Version 8.21 war mir das nicht aufgefallen. Box wurde länger stromlos gesetzt, DSL Kabel, Netzteil getauscht - keine Änderung. Da vor einiger Zeit bereits die 1. Dose von der Telekom getauscht wurde, dachte ich zunächst an ein HW Problem der Fritzbox. Geholfen hat jetzt die Option, die vorherige DSL Version zu verwenden. Damit sind die Werte bei Dämpfung und Störabstand etwas besser und der Syncverlust hat aufgehört. Da demnächst die 8.50 ansteht die Frage, welche DSL Version dort verwendet wird. viele Grüße sulihari
 
Kostenlos!

Statistik des Forums

Themen
248,873
Beiträge
2,303,533
Mitglieder
378,534
Neuestes Mitglied
test-forcepaster