FRITZ!WLAN Repeater DVB-C Firmware FRITZ!OS 6.21 vom 19.01.2015

tester25

Aktives Mitglied
Mitglied seit
23 Feb 2010
Beiträge
823
Punkte für Reaktionen
26
Punkte
28
Produkt: FRITZ!WLAN Repeater DVB-C
Version: FRITZ!OS 6.21
Sprache: deutsch
Release-Datum: 19.01.2015

Verbesserungen in 133.06.21:
System
- Stabilität verbessert

Und teils aus den Vorversionen:
Neue Features: - Ausführliche Sendersuche
- Signalisierung eines vorhandenen Updates in FRITZ!App TV
- Gesteigerte WLAN-Performance
- IP TV-Streaming über WLAN optimiert (Multicast zu Unicast)
- Interoperabilität mit der Videorekorderfunktion von T-Home Receivern verbessert
- Die WLAN-LEDs blinken bei WPS für den WLAN-Gastzugang
- Anzeige des gesamten Repeater-Namens in der Benutzeroberfläche

Hinweise zur Durchführung des Updates:

Führen Sie das Update über die in der Benutzeroberfläche
angebotene Aktualisierungs-Funktion durch. Diese bietet
Ihnen automatisch das richtige FRITZ!OS an. Klicken Sie
auf "Assistenten", wählen Sie "Update" und folgen Sie den
Hinweisen auf dem Bildschirm.

Link zur Infoseite bei AVM
 
Naja viel ist das ja nicht gerade.

Edit:
Schon die ersten Updateprobleme. Hab direkt ausm Repeater heraus das Update gestartet Und außer dem Ladebalken dass das Update übertragen wird tut sich nichts. Aber DVBC Signal schon weg und Wla LED dauerhaft am Blinken. seit gefühlten 5-8 Minuten. Kann ich das nun einfach abbrechen?
 
Zuletzt bearbeitet:
Scary674, das selbe hatte ich auch nach starten des Updates aus dem Gerät heraus. Nach ca. 10 Mins. einfach den Repeater kurz vom Strom getrennt, wieder eingesteckt und dann das Update mit Datei von AVM gemacht. Somit nun die 6.21 installuiert.
 
Online-Update lief bei mir ohne Probleme durch, allerdings Betrieb als LAN-Brücke.
 
Das Update über die Oberfläche hat funktioniert.
Ob mein Problem mit der identischen Belegung zweier Bouquets gelöst ist, kann ich nicht mehr prüfen, da der Betreiber die Belegung geändert hat.

Aber zwei alte Fehler habe ich wiedergefunden:

1. Kosmetik: WLAN -> Funknetz "Ihre FRITZ!Powerline kann ein WLAN-Funknetz sowohl ..."
2. In der Übersicht sind immer beide WLANs als aktiv markiert, auch wenn nur wirklich eines aktiv ist.

Aber nach dem Update hat das Fernsehen sofort wieder funktioniert.

Marcus
 
DieWilde13, ich habe auch die LAN-Brücke, da ich, wenn ich den Repeater über WLAN-Brücke laufen lasse, nur noch mit Gräten ins Intenet komme, die mit dem Repeater verbunden sind, nicht aber mit Geräten, die mit der Fritte direkt verbunden sind.

MarcusF.

Noch ein Fehler, der schon in der 6.20 war:
Auf der Übersichtsseite "Netzwerk" und dahinter das "mehr" kommt man immer noch beim anklicken auf die Funknetz-Übersichtsseite und nicht auf das Netzwerk selbst.
Details für das Netzwerkgerät lässt sich auch beim ersten mal auf OK klicken nicht speichern. Da kommt dann erst die Meldung: Es ist ein Fehler aufgetreten.
Fehlercode: 1
Ihre Eingaben wurden möglicherweise nicht übernommen.
Bitte geben Sie Ihre Daten noch einmal ein. Sollte der Fehler erneut auftreten, wenden Sie sich bitte an den AVM-Support.
Beim 2. mal auf ok klicken kommt zwar die Meldung wieder, aber die ännderungen werden dann gespeichert
 
Zuletzt bearbeitet:
Online Update ohne Probleme

Die WLAN Anzeige in der Übersicht ist immer noch fehlerhaft.
Es werden immer beide als aktiv angezeigt.
 
Auch bei mir schlug das Onlineupdate fehl, habe dann über das Image das Update ausgeführt.

Die bis jetzt bekannten Fehler im WEBgui kann ich bestätigen: @Marcus F., @Kaffeejunkie, @mardu
Leider besteht auch weiterhin die fehlerhafte Angabe zur IP-Adresse eines aus dem normalen WLAN bekannten
Gerätes im GASTWLAN.
Ich erhalte im übrigen jedesmal wenn der Repeater startet ein neues Zertifikat angeboten (neue Seriennummer?)

Mal sehen op die Stabilität, WLAN 5 GHz etc. verbessert wurde.
Gewisse Ungereimheiten bleiben uns wahrscheinlich länger erhalten.
 
Crash auch mit OS 06.21 - leider

Ich habe leider wieder einen Crash des Repeaters hinter mir, diesmal mit dem neuen OS 06.21.

Trigger: ??? Ich hatte gerade mehrmals die Sender in der TV-App gewechselt.

Auch hier wird wie mit OS 06.20 kein Fehlerbericht versendet: "TCP-Fehler".
Pushmails gehen auch nicht - dauerhaft laufender blauer Balken bei der Testmail für mehr als 5 Minuten,
danach per Hand abgebrochen.
PoR ausgeführt - und die PUSHmails funktionieren wieder - der Fehlerbericht natürlich nicht mehr.
Soweit zur Stabilität der neuen Version 06.21 bei mir.
(Und 2x neues Zertifikat akzeptieren - mein Repeater hat einen abweichenden Namen)
 
Zuletzt bearbeitet:
Das Update hat bei mir über die Online-Funktion problemlos geklappt.

Ich habe nur das Problem, dass der Repeater die Kanalbandbreite im 2,4 GHz-Netz immer runtersetzt, so dass sich mein Laptop nur noch mit 144 MBit/s statt 300 MBit/s verbinden kann. Kann man die Option im Repeater irgendwo abschalten? Gefunden habe ich diesbezüglich bisher nichts.
In der 7490 ist die Option WLAN-Koexistenz ausgeschaltet und solange ich den Repeater nicht in die Steckdose stecke, bleibt die Bandbreite bei 300 MBit/s bei Verbindung mit der Box. Kurz nachdem der Repeater betriebsbereit ist (im Log steht auch: WLAN-Übertragungsqualität durch reduzierte Kanalbandbreite erhöht (2,4 GHz).), verbindet sich der Laptop mit dem Repeater nur noch mit 144 MBit/s. Wenn ich danach den Repeater wieder entferne, verbindet sich der Laptop auch mit der 7490 nur noch mit 144 MBit/s. Abhilfe schafft erst ein Neustart. So optimal ist das nicht.
Soweit ich mich erinnern kann, hatte ich das Problem auch mit der 6.20.
 
Das mit der reduzierten Kanalbandbreite obwohl WLAN-Koexistenz in der 7490 deaktiviert ist kann ich auch schon seit 6.20 bestätigen.

WLAN-Übertragungsqualität durch reduzierte Kanalbandbreite erhöht (2,4 GHz).
 
Zuletzt bearbeitet von einem Moderator:
Die Firmware hat das gleiche Problem wie die 6.20 mit der Fritz!Box 7490 mit Firmware 6.23. Das 5 GHz WLAN lässt nach ca. 5 Minuten keinen Zugang zum Internet zu, weder via Box noch über Repeater, das 2,4 GHz WLAN ist weiterhin nicht betroffen. Meldung ist raus, zurück per Recover auf 6.12 hilft da nur noch.
 
Bei mir als AP via LAN - also kein Repeaterbetrieb
5 GHz (80 MHz) mit Smartphone (325/325 Mbit/s): Internet - UPnplay/Youtube etc. laufen bei mir (ebenso wie lokal die TV-App) ohne Probleme.
Bei mir läuft der LAN-Betrieb des FRITZ!WLAN AP DVB-C übrigens über PLC-adapter (aktuell 279 / 246 Mbit/s)

Bis jetzt kein weiterer Crash. Der gestrige nach dem Update war übrigens neu und nicht mehr in Verbindung mit dem l2tpv3d.
Es tut sich was . . . Neue Meldung an AVM.
 
Zweiter Crash des DVB-C WLAN AP's nach dem Update - Ursache? Ich kann z.Zt. keinen Anlass erkennen.
Crashlog ist leer - nur paniclog vorhanden:
.....
<4>[99243.756000] wmi_unified_vdev_stop_send
<4>[99243.764000] All nodes should be freed before bss node gets freed. node count is 2 Investigate!!!!
<1>[99243.972000] CPU 0 Unable to handle kernel paging request at virtual address 00000354, epc == 813242e8, ra == 81324290
<4>[99243.972000] Oops[#1]:
....
<4>[99243.972000] Code: 14600002 24430330 24430258 <8c640024> 26050018 8c680020 8c660034 02642021 8c6e0030
<4>[99244.264000] Call Trace:
<4>[99244.268000] [<8001d7a8>] dump_stack+0x8/0x40
<4>[99244.272000] [<80031678>] panic+0x58/0x160
<4>[99244.276000] [<8001e264>] die+0xc4/0x100
<4>[99244.280000] [<80024c20>] do_page_fault+0x360/0x420
<4>[99244.284000] [<80002dc0>] ret_from_exception+0x0/0x10
<4>[99244.288000] [<813242e8>] process_tx_stats+0x1c8/0x460 [umac]
<4>[99244.296000] [<81324618>] ol_ath_get_all_stats+0x98/0xe0 [umac]
<4>[99244.304000] [<81353aac>] wdi_event_handler+0x6c/0x160 [umac]
<4>[99244.308000] [<81358be0>] htt_t2h_msg_handler_misc+0x4a0/0x520 [umac]
<4>[99244.316000] [<81358de0>] htt_t2h_msg_handler_fast+0x180/0x220 [umac]
<4>[99244.324000] [<81344bd0>] CE_per_engine_service_each+0x210/0x560 [umac]
<4>[99244.332000] [<812cafb0>] ath_tasklet+0x50/0x160 [umac]
<4>[99244.336000] [<800382d0>] tasklet_action+0xd0/0x100
<4>[99244.340000] [<80038bc4>] __do_softirq+0xe4/0x1c0
<4>[99244.344000] [<80038d28>] do_softirq.part.13+0x88/0xa0
<4>[99244.352000] [<800391e8>] irq_exit+0xa8/0xc0
<4>[99244.356000] [<800166c8>] ath_dispatch_wlan_intr+0xa8/0xc0
<4>[99244.360000] [<80002dd0>] ret_from_irq+0x0/0x4
<4>[99244.364000] [<80016f54>] r4k_wait_irqoff+0x34/0x38
<4>[99244.368000] [<80017b94>] cpu_idle+0x74/0xc0
<4>[99244.372000] [<805028d0>] start_kernel+0x338/0x350
<4>[99244.380000]
<0>[99244.380000] Kernel panic - not syncing: Fatal exception in interrupt
-----
(first) sent on: Wed Jan 21 16:14:33 2015 UTC by crash report

Vielleicht habe ich ein Montagsexemplar der Firmware erwischt, sehr mysteriös.:confused:
 
Zuletzt bearbeitet:
Jeden Tag ein Crash des FRITZ!WLAN Repeaters DVB-C mit dem aktuellen Fritz!OS 6.21 - auch heute mittag und aus bislang unerfindlichen Gründen schlägt der automatische Versand der Supportdaten jedesmal fehl.

2 Tickets bei AVM angemeldet: 1) Wiederholter Crash des Repeaters -gleiche Panic Meldung wie hier oben http://www.ip-phone-forum.de/showthread.php?t=276244&p=2066928&viewfull=1#post2066928; 2) Kein Versand der Supportdaten nach einem automatischen Neustart.

Ist meine Konstellation die einzige mit derartigen Problemen?
 
Das sieht so aus ...
 
Ist meine Konstellation die einzige mit derartigen Problemen?
Irgendwo in den Weiten des WLANs stürzt Dein Repeater ab ... wenn die Entry-Points halbwegs sprechend sind, beim Aktualisieren irgendeiner Empfangsstatistik (process_tx_stats dürfte der letzte "normale" Call im Flow sein). Vielleicht ist ja nur etwas in der WLAN-Konfiguration des Repeaters ungewöhnlich oder auch in Deiner kompletten WLAN-Umgebung sind irgendwelche merkwürdigen Umstände vorhanden.

Aus der "All nodes should be freed"-Meldung würde ich (freie Interpretation, ohne jedes gesicherte Wissen) ableiten, daß da ein "Basic Service Set" irgendwie freigegeben werden soll, während noch zwei weitere - von diesem abhängige Knoten - in irgendeiner Liste vorhanden sind. Kann es eventuell sein, daß da in Deiner Umgebung jemand mit einem WLAN-Scanner ab und an mal herumspielt und dabei "deauthentication packets" verschickt werden (nur mal so geraten)?

Ansonsten würde ich einfach zum Test mal das WLAN deaktivieren (der hat doch lt. Spec auch einen LAN-Anschluß) und dann eine Weile beobachten. Was da allerdings tatsächlich durch den "Äther" schwirrt und den Absturz des Repeaters verursacht, wirst Du wohl eher nicht herausbekommen (vielleicht mit einem Packetdump über LAN-Verbindung, wenn der das kann und schnell genug ist, um noch das "packet of death" zu protokollieren) ohne einen parallel irgendwo mitlaufenden Analysator. Schon der Gedanke, daß man ja mal mindestens zwei Abstürze reproduzieren müßte, um sicher die Situation im WLAN vor den beiden Abstürzen vergleichen zu können und daß dieser Absturz ja offenbar nicht auf Kommando erfolgt, würde mich allerdings davon abschrecken.

Vielleicht einfach mal die WLAN-Sendeleistung drosseln (damit der Nachbar das WLAN nicht mehr wahrnimmt) oder auf andere Kanäle/Bänder ausweichen/beschränken? Ist halt bei WLAN etwas schwer zu handhaben und die Möglichkeiten sind vielfältig, was man dafür/dagegen versuchen könnte.

Mit DVB-C würde ich den Absturz jedenfalls eher nicht in Verbindung bringen, wenn das panic-Log wirklich reproduzierbar dasselbe ist.
 
@Peter Pawn
In der Tat - DVB-C ist so gut wie auszuschliessen. Vielleicht werde ich demnächst Kali auf meinem Netbook befragen, auch um irgendwelche WLAN scanner (deauth etc.) auszuschliessen.
Obwohl ich erst noch einige Crashs abwarten will um einige kleine Unterschiede und natürlich die Gemeinsamkeiten zu dokumentieren.
Nach dem nächsten Crash werde ich das WLAN wahrscheinlich für ca. 48 Stunden ausschalten, ich erwarte allerdings keinen Crash in dieser Zeit.

Interessanterweise war mit der Firmwareversion 6.20 häufig/immer? der l2tpv3d laut CRASHLOG beteiligt, bei der Version 06.21 bei drei Crashs ist keine Spur davon zu finden.
Mit der Version 6.12 funktionierte das GASTWLAN bei mir übrigens nicht (nach Association keine IP-Adresse), was ich selbst dem irgendwie nicht funktionierenden l2tpv3d zuschrieb.
Wird sicher fortgesetzt (auch von AVM?)
 
Das mit dem Gastnetz und auch der Hotspot-Funktion blicke ich selbst noch nicht komplett ... aber ich würde annehmen, daß da irgendwo Layer2 Tunneling Protocol (V3) eingesetzt wird, um einerseits den Traffic im/für das Gastnetz vor neugierigen Blicken aus dem LAN/WLAN zu schützen und andererseits das LAN/WLAN so weit zu isolieren, daß niemand aus dem Gastnetz ausbrechen kann. Ich weiß aber bis heute noch nicht, ob bei diesem Hotspot dann eine weitere Public-IP zum Einsatz kommt, die ohnehin vorhandene Public-IP mitbenutzt wird (das dürfte ein Problem bei Störerhaftung werden (falls die weiterhin überlebt)) oder ob da tatsächlich ein Tunnel direkt vom WLAN-Interface zum Provider gelegt wird und der Traffic dort erst wieder ausgepackt wird. Ansonsten könnte man ja an einem Homespot auf der WAN-Seite problemlos den Verkehr der Hotspot-Benutzer mitschneiden ... das ist alles noch etwas im Dunkel der neuen Funktionalitäten und harrt der genaueren Analyse.

Aber gerade auch bei der Verbindung zu Repeatern bilde ich mir ein, die Verwendung von l2tpv3 auf der Strecke Basis <-> Repeater schon als "Verpackung" in Packetdumps gesehen zu haben ... ich habe jedoch nur einen alten 300E und den eigentlich auch nie im Regel-Betrieb, der wird nur für Angriffssimulationen aus dem WLAN von mir mißbraucht, weil man da mit einem Kabel ganz prima auch per Telnet draufkommt.

Daher hat mich das nie wirklich interessiert ... ich habe mir nur für mein Weltbild die Erklärung bereitgelegt, daß L2TPv3 zwischen Basis und Repeater im "universal repeater mode" zum Einsatz kommt, damit die eigentlichen Pakete im Payload, die schon die MAC-Adresse des Clients als Ziel tragen, erst einmal auch bis zum Repeater "vordringen", wo sie dann wieder ausgepackt und an den Client gesendet werden, der sich ja - je nach Topologie - durchaus auch irgendwo "zwischen" Basis und Repeater befinden könnte und bei nicht gekapselter Aussendung die Pakete direkt empfangen könnte. Ob das aber tatsächlich so möglich wäre (das setzt ja mal mindestens denselben PMK zwischen Basis+Client und Repeater+Client voraus, wie es mit PTKs aussieht, weiß ich nicht), mü0te ich für eine stichhaltige oder auch nur wahrscheinliche These erst noch einmal durchdenken. Ich weiß nicht einmal, ob ein Repeater tatsächlich irgendwie einen Key von der Basis erhalten kann, wenn ein Client per Roaming jetzt auf einmal mit dem Repeater anstelle der Basis reden will (ggf. auch umgekehrt).
 
Hm, hab mit der neuen Firmware jetzt zwei Mal hintereinander Probleme gehabt...

Ich hab nur drei Geräte im WLAN: Laptop, Handy, Chromecast. Wenn ich in's Bett gehe ist der Chromecast aus, der Laptop auch und das Handy schaltet sich auch über Nacht weg. Dementsprechend geht der Repeater in den Stromsparmodus solange bis eines der Geräte wieder angeht. Bis jetzt hat das immer innerhalb von wenigen Sekunden funktioniert. Also Laptop wird hochgefahren und flupps - schon fährt der Repeater das WLAN mit hoch. Macht er jetzt irgendwie nicht mehr...

Gestern musste ich bestimmt ne Minute warten bis er da war. Heute war das WLAN zwar da, aber das Ding war irgendwie total abgemeldet - der Laptop meldete "Unidentifiziertes Netzwerk" und der AP war unnerreichbar. Hat dann ein paar Minuten später von selbst neu gestartet und alles war wieder gut...

Ich werd das mal weiter beobachten.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.