FritzOS 6.83: automatisches Abmelden aus dem Web-Interface

[rk97]

Hallo,
bisher hatte ich eine Fritzbox 7270 mit FritzOS 6.06. Mehr war nicht nötig wg. der installierten Telekom-Infrastruktur. In ein paar Tagen bekomme ich einen Port am hier frisch eingeweihten VDSL-Netz.

Also habe ich eine Fritzbox 7412 beschafft und habe jetzt FritzOS 6.83 drauf. Relevanter Unterschied: wenn ich einige Minuten im Web-Interface nichts mache, fliege ich raus, muß mich dann neu anmelden und manchmal durch die Menüs hangeln, bis ich wieder dort bin, wo ich vorher war. Sehr lästig, weil ich manchmal den "Online-Monitor" dauerhaft laufen lasse(n möchte). Ich finde keine Einstellmöglichkeit, um hier die Zeit bis zum automatischen Abmelden zu ändern, z.B. auf "unendlich".

Gibt's Abhilfe? Meine Suche sowohl hier im Forum wie im Web waren nicht von Erfolg gekrönt.

TIA

 

[deoroller]

Ist die erweiterte Ansicht der Benutzeroberfläche aktiviert?
https://avm.de/service/fritzbox/fri...e-Ansicht-der-Benutzeroberflaeche-aktivieren/

 

[HabNeFritzbox]

Man kan nur auf die Zeit selbst drücken und somit Timer auf 20 Min zurücksetzen.

Timer abschalten geht nicht. Wenn es nur um den Traffic geht, gibt es da ein nettes Windows Tool https://www.ip-phone-forum.de/threa...ox-traffic-sidebar-gadget-applikation.222771/

 

[rk97]

Ist die erweiterte Ansicht der Benutzeroberfläche aktiviert?

Ja, klar
Beiträge zusammengefügt - HabNeFritzbox

Man kan nur auf die Zeit selbst drücken und somit Timer auf 20 Min zurücksetzen.

Was meinst Du damit? Ich hatte jetzt mehrfach die Situation, daß ich irgendwo in den Tiefen des Web-Interfaces unterwegs war, dann wenige Minuten Pause gemacht habe, also deutlich unter 20min, um dann trotzdem rauszufliegen. Vielleicht waren das 20min nach Anmelden? Aber darauf hatte ich noch nicht so genau geachtet.

Wenn es nur um den Traffic geht, gibt es da ein nettes Windows Tool

Tja, Windows ... Das ist eine gute Idee, aber nichts für meine Umgebung.

Wenn es nicht geht diesen Timer abzuschalten, muß ich den "Fortschritt" beim FritzOS offensichtlich hinnehmen. Ich hatte insgeheim die Hoffnung, daß man irgendwo in irgendwelchen Verzeichnissen der FritzOS-Shell-Skripte was anpassen könnte, auch wenn Telnet (wie bisher gewohnt) nicht mehr geht, aber die 5sec-FTP-Methode noch diese letzte Möglichkeit bietet.

 

[PeterPawn]

https://www.ip-phone-forum.de/threads/wie-kommen-die-19-minuten-zustande.298392/

 

[rk97]

Unnötiges Vollzitat entfernt - HabNeFritzbox
Danke Jetzt habe ich "spontan" herausgefunden, welche Funktionalität sich hinter den 3 Punkten rechts oben verbirgt.

Gibt's eine Beschreibung für "Dummies" (ja, ich bin Neuling mit Versionen > 6.06), wie ich die anderen Parameter/Environment-Variablen reinbekomme?

 

[HabNeFritzbox]

Wenn man z.B. IPv6 hat und Internetverbindung neu aufgebaut wird und somit neues Präfix hat, ändert sich auch am PC die IP und damit wirst gekickt auch vor Ablauf der 20 Minuten.

Die 20 Minuten sind jeweils ab laden der jeweiligen Seite.

 

[PeterPawn]

ändert sich auch am PC die IP

Warum sollte ein PC auf die Box selbst mit ihrer oder seiner öffentlichen IPv6-Adresse zugreifen?

Dafür gibt es doch im Normalfall die link-lokalen Adressen aus fe80:: und die "unique local addresses" (ULA - fd00:: wäre hier der reservierte Präfix) und die sollten sich ja nicht ändern, wenn die FRITZ!Box ihre Internetverbindung neu aufbaut.

Gerade dann, wenn man auch intern (ggf. sogar noch über zusätzliche Router hinweg, wo dann die link-lokale fe80:: nichts mehr bringt) auf IPv6 zwischen den Geräten setzt, sollte man auch generell auf der Zuweisung von ULA beharren. Bei AVM werden in der Standardeinstellung ULA m.W. nur dann vom DHCPv6-Server geliefert, wenn die Box noch keine IPv6-Adresse hat - das ist bei mir immer eine der ersten Einstellungen, denen es an den Kragen geht ... gleich nach der Expertenansicht.

Dann behalten die Rechner für die Kommunikation untereinander (sofern die link-lokalen fe80-Adressen nicht bereits ausreichen) wenigstens eine "konstante" ULA, mit der sie auch untereinander (und natürlich mit der FRITZ!Box) kommunizieren können.

Ist das also "beobachtetes Verhalten" mit diesen Abbrüchen oder nur Theorie und wie sieht es aus, wenn man die ULA-Einstellungen beim AVM-DHCPv6-Server (auf "sinnvoll") ändert?

 

[HabNeFritzbox]

Moin Peter,

der Standard ist "Unique Local Addresses (ULA) zuweisen, solange keine IPv6-Internetverbindung besteht (empfohlen)" welchen ich auch verwende.

Wenn man also Internetverbindung neu aufbaut oder auf dem Smartphone WLAN aus/an macht, hat man andere IP, und damit Sitzung ungültig und wird beendet.

Habe es nur als eine mögliche Option genannt. Innerhalb des Netzwerkes ist es doch eh egal welcher der 3 Adressen verwendet werden.

Edit: Habe es mal getestet, Anmeldung erfolgt trotzdem über öffentliche IP, diese wird wohl bevorzugt. Daher kann man auch auf diese verzichten, spielt bei Nutzung von Hostnamen eh keine Rolle.

 

[PeterPawn]

Das entscheidet nun mal der Client, welche der (i.d.R. mehreren) angebotenen Adressen er für die Kontaktaufnahme verwendet ... die Box macht hier (aus meiner Sicht jedenfalls) vieles richtig:

vidar:~ # dig @192.168.xxx.1 fb6490.fritz.box. aaaa               <= "any" ginge auch

; <<>> DiG 9.11.2 <<>> @192.168.xxx.1 fb6490.fritz.box. aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27900
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3

;; QUESTION SECTION:
;fb6490.fritz.box.              IN      AAAA

;; ANSWER SECTION:
fb6490.fritz.box.       9       IN      AAAA    fd00::...
fb6490.fritz.box.       9       IN      AAAA    2a02:8109:8...

;; AUTHORITY SECTION:
fb6490.fritz.box.       9       IN      NS      fritz.box.

;; ADDITIONAL SECTION:
fritz.box.              9       IN      A       192.168.xxx.1
fritz.box.              9       IN      AAAA    fd00::...
fritz.box.              9       IN      AAAA    2a02:8109:8...

;; Query time: 0 msec
;; SERVER: 192.168.xxx.1#53(192.168.xxx.1)
;; WHEN: Wed May 30 09:59:29 CEST 2018
;; MSG SIZE  rcvd: 176

vidar:~ # dig -6 @fd00::ca0e:14ff:fe... fb6490.fritz.box. any

; <<>> DiG 9.11.2 <<>> -6 @fd00::ca0e:14ff:fe... fb6490.fritz.box. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50200
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 3

;; QUESTION SECTION:
;fb6490.fritz.box.              IN      ANY

;; ANSWER SECTION:
fb6490.fritz.box.       9       IN      A       192.168.xxx.1
fb6490.fritz.box.       9       IN      AAAA    fd00::ca0e:14ff:fe...
fb6490.fritz.box.       9       IN      AAAA    2a02:8109:8...

;; AUTHORITY SECTION:
fb6490.fritz.box.       9       IN      NS      fritz.box.

;; ADDITIONAL SECTION:
fritz.box.              9       IN      A       192.168.xxx.1
fritz.box.              9       IN      AAAA    fd00::ca0e:14ff:fe...
fritz.box.              9       IN      AAAA    2a02:8109:8...

;; Query time: 1 msec
;; SERVER: fd00::ca0e:14ff:fe...#53(fd00::ca0e:14ff:fe...)
;; WHEN: Wed May 30 10:21:09 CEST 2018
;; MSG SIZE  rcvd: 192

vidar:~ #

Das Einzige, was man vielleicht "kritisieren" könnte, ist die IPv6-ACL, die von der Box für die DNS-Verwaltung verwendet wird:

# aicmd multid dnsd dump
[...]
allowedv4:
 192.168.xxx.0 255.255.255.240 (0.xxx.168.192.in-addr.arpa)
 169.254.0.0 255.255.0.0 (254.169.in-addr.arpa)
allowedv6:
 fd00::/64 (0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa)
 2a02:8109:8xxx:xxxx::/64 (x.x.x.x.x.x.x.8.9.0.1.8.2.0.a.2.ip6.arpa)
[...]
#

Damit kriegt wohl eine Abfrage mit der link-lokalen IPv6-Adresse eines Clients (also "fe80::irgendwas") keine Antwort vom DNS-Server (hier eine 06.83 auf der 6490) ... was zumindest theoretisch auch funktionieren sollte/müßte, aber vermutlich kriegt man ansonsten Probleme mit dem Gastnetz (das ja für link-lokales IPv6 auch den "fe80::/64"-Präfix nutzt), da man wohl am DNS-Server nur noch auf der Basis der IPv6-Adresse des Absenders und nicht mehr anhand des eingehenden Interfaces filtern kann, welche Daten der DNS-Server herausgibt und für das Gastnetz braucht es ja ein anderes "view" auf die (lokale) Domain. Bei "stabilen" ULA verwendet die Box dann wieder einen getrennten Präfix (fd80::1::0:0:0:0/64), wenn man keinen eigenen, abweichenden ULA-Präfix (von "fd00::/64") festgelegt hat, was aber auch ginge.

Aber über eine ULA ist auch die Abfrage des DNS-Servers über "reines" IPv6 möglich sein ... siehe das Beispiel oben. Wer also auf ein solches Problem trifft, daß seine interne IPv6-Kommunikation mit dem Wechsel der IPv6-Adresse (bzw. eines delegierten Präfix vom Provider) auch komplett zusammenbricht, der sollte die Box auf "immer ULA zuweisen" stellen und gleichzeitig dafür sorgen, daß seine Clients für die lokale Kommunikation dann auch die ULA bevorzugt verwenden.

Wer sich mit dem Thema etwas genauer befassen will, liest sich RFC 7368 (Punkt 3.4.2.: Stable Internal IP Addresses) durch ... eine derartige Unterbrechung einer Verbindung ist jedenfalls weder notwendig noch "normal" (und hier vermutlich auch eher nicht die Ursache, weil die 7412 wohl kaum alle 20 Minuten das öffentliche Präfix wechseln wird) und im Allgemeinen eher das Ergebnis einer Fehlkonfiguration.

Warum AVM hier auf die (permanente) ULA-Bereitstellung verzichtet in der "Standardkonfiguration", erscheint auch wenig einleuchtend (zumindest kann ich es mir nicht erklären und von AVM gibt es - m.W., gegenteilige Beweise nehme ich gerne - dazu auch keine plausible Erklärung/Beschreibung) ... schließlich hält sich das FRITZ!OS ja durchaus für fähig, den "neuen Sheriff" in der Stadt auch bei IPv6 zu geben und da sollte man die Benutzer (erst recht diejenigen, die weniger Ahnung von Netzwerken im Allgemeinen und IPv6 im Speziellen haben) nicht im Regen stehen lassen, zumal es erst dann "Synchronisationsprobleme" gäbe, wenn mehrere DHCPv6-Server mit demselben Präfix unterwegs wären (durch die IPv6-BC-Mechanismen auch einigermaßen leicht zu ermitteln für eine automatische Konfiguration) ... spätestens beim "Meshen" dürfte das dann auch nicht mehr der Fall sein.