[Info] FRITZ!Box 7490 Labor-Firmware Version 6.10-28144 vom 06.06.2014

[Hans Juergen]

Hast du mal eine andere Mailadresse versucht? Die Test- und IP-Mail gehen grundsätzlich nur an die Absenderadresse, die Adresse der Statusmail ist änderbar.

 

[PeterPawn]

Welche Infos brauchst Du denn?

Das hängt davon ab, wo das Problem auftritt.

Ein Anfang wäre schon mal eine Prozessliste vor und nach dem Fehler ... eine iwconfig-Ausgabe zu diesen Zeitpunkten wäre auch interessant, genauso wie
- die Liste der geladenen Treiber (lsmod)
- die Konfiguration der Bridge (brctl show)
- die Liste der verbundenen WLAN-Clients
Vielleicht ist ja auch das WLAN selbst i.O. und nur der DHCP-Server will nicht mehr nach dem WLAN-Neustart oder es wird automatisch der WPS-Modus gestartet usw. usf.
Ich kann es - wie schon geschrieben - bei mir hier absolut nicht reproduzieren.

Eigentlich hat AVM alles schon schön in den Support-Daten zusammengefaßt, was für eine Fehleranalyse benötigt werden könnte. Dabei werden auch schon alle verschlüsselten Daten aus den Konfigurationsdateien entsprechend maskiert. Leider bleiben noch genug sensitive Informationen übrig (die braucht man zum Teil auch, um etwas analysieren zu können), daher ist das Posten der Support-Daten in einem öffentlichen Forum keine gute Idee.

Ansonsten *vor* dem Abschalten des WLANs (möglichst dicht am Abschaltzeitpunkt, damit sich die Umgebung nicht zu sehr ändert) die Support-Daten abspeichern und dann wieder (möglichst zeitig, das meint so innerhalb von 1-5 Minuten) *nach* dem Reaktivieren des WLANs erneut abspeichern. Wenn jetzt in der Prozessliste irgendwelche WLAN-bezogenen Prozesse nicht vorhanden sind und/oder irgendwelche Kernel-Module für das WLAN nicht geladen sind und/oder die Bridge nicht richtig eingerichtet ist usw. ... dann kommt man dem Problem vielleicht näher.

Ich habe eine verborgene SSID und die MAC-Filterung aktiv. Im Protokoll wird gemeldet, dass WLAN aktiv sei und die WLAN Lampe blinkt.

1. Auch das "Verbergen" der SSID und die MAC-Filterung schützt nicht wirklich vor Angriffen ... höchstens vor "Gelegenheitsbesuchern" ohne entsprechendes Werkzeug, gegen die aber auch ein ordentliches Kennwort hilft. Jeder halbwegs vernünftige WLAN-Scanner entdeckt auch derartige Service-Sets und bringt sie zur Anzeige.
Lediglich die, in einigen WLAN-Routern ja ansatzweise funktionierende, "friedliche" Aufteilung der verfügbaren Kanäle wird - je nach Qualität der dabei eingesetzten Algorithmen - erschwert. Wer einmal seine Fritz!Box in Berlin-Prenzlauer Berg nach Nachbarnetzen befragt hat und dabei dann - je nach Standort - mehr als 40 "sichtbare Nachbarn" gefunden hat, der freut sich besonders über zusätzliche "versteckte" Nachbarn, die sein Router vielleicht nicht ad-hoc erkennt und in die Wahl eines passenden Kanals mit einbezieht.

OT: Unter diesen Bedingungen ist auch das Abschalten des WLANs (so sehr es der Umwelt helfen mag, durch Vermeidung von Elektrosmog und Reduzierung des Energieverbrauchs) eher kontraproduktiv, da wohl kein WLAN-Router nachträglich den Kanal wechselt (und es auch nicht kann, da es meines Wissens kein Protokoll zum konzertierten Kanalwechsel für ein komplettes Service-Set gibt), wenn es auf dem gerade verwendeten Kanal enger wird, weil einige "Kollegen" einfach mal dazukommen. Auf Kanal 6 im 2.4GHz-Netz tummeln sich offenbar die meisten Router im Auslieferungszustand. Eine Fritz!Box, die dabei um 06:00 Uhr einen - fast unbelegten - Kanal 6 ausgewählt hat, liegt ggf. meilenweit daneben, wenn um 09:00 Uhr rundherum die Nachbarn erwachen (ob automatisch oder per schaltbarer Steckerleiste ist dabei egal). Und das - gerade in diesem Szenario extrem sinnvolle - Beschränken der Sendeleistung im WLAN beherrschen leider nicht alle WLAN-Router. Vollkommen abgesehen davon, daß bei vielen Nutzern bei "schlechtem" WLAN-Durchsatz offenbar als erstes mal die Sendeleistung wieder erhöht wird ... es könnte ja sein, daß irgendwie die "Funkstrecke" zwischen den 3 Meter voneinander entfernten Geräten blockiert wird (wahrscheinlich durch den Quarzkristall auf dem Schreibtisch ) und viel hilft bekanntlich auch viel.

2. Das Blinken der WLAN-LED kann mehrere Zustände signalisieren. Die Blinkfrequenz (Ein/Aus jeweils mit Dauer) könnte (muß aber nicht, es gibt wohl auch mehrere Zustände mit identischem "Blink"-Code, aber unterschiedlichen "Events" als Auslöser) da genauer Auskunft geben. Aber das mit dem "Dauerblinken" meinte ich, als ich die Vermutung äußerte, daß irgend etwas beim "Wiederstart" des WLANs nicht zum Ende kommt.

Erst nach dem Neustart der Box war die Darstellung plötzlich fehlerhaft.

Nur wenn die Fritz!Box eine TCP-Verbindung auf Port 80 zu diesem Gerät herstellen kann (ob wirklich das Vorhandensein eines HTTP-Servers getestet wird, kann ich im Moment nicht genau sagen), wird das Gerät mit einem Link im GUI angezeigt. Bei der Anzeige unter "Bekannte WLAN-Geräte" wird dabei einmal zuviel "encoded", daher kommt kein gültiger HTML-Link dabei heraus.
Edit: Da bei einem - von der 7490 verlinkten - Gerät im Log des Apache-Servers keine Requests auftauchen, gehe ich davon aus, daß irgendein aktiver TCP-Service auf Port 80 ausreicht, damit die Box daraus einen HTTP-Link macht.

 

[Chris_e]

@PeterPawn

Irgendwie ist das am Thema vorbei.

Ich wollte jetzt keine Lehrstunde über Sinn und Unsinn einer verborgenen SSID oder über WLAN aus oder an. Ich wollte nur die Einstellungen bekannt geben, um vielleicht einen Zusammenhang zu erkennen. Irgendeinen Grund muss es ja haben, dass es bei vielen Usern funktioniert und bei anderen nicht.

 

[PeterPawn]

Ich wollte jetzt keine Lehrstunde ...

Keine Lehrstunde, meine Meinung samt Begründung ... also auch geeignet, einfach ignoriert zu werden.

Dass die generelle Frage "WLAN an/aus/an/aus" nicht ganz zum Thema gehört, wußte ich schon selbst, sonst hätte ich den Absatz nicht gekennzeichnet.

Und der Mythos mit der "hidden SSID" hält sich leider hartnäckig und ist häufig genug die Ursache von Problemen, die es bei "sichtbarer" SSID gar nicht erst gibt.

Ich wollte nur die Einstellungen bekannt geben ...

Da Du ja auch das Fehlerbild der "blinkenden WLAN Lampe" beschreibst, könnte eine Bekanntgabe der LED-Blinkfolge u.U. schon weiterhelfen.

 

[elmicha]

2.) WLAN Geräte haben jetzt einen schönen Namen, wie etwa <a target="_blank" href=..."
Anhang anzeigen 76289

Das tritt hier nur bei einem Eintrag auf, der ein "-" im Rechnernamen hat ("dd-wrt"), die anderen Einträge sind ok. Haben Deine Geräte evtl. alle ein "-" im Namen?

 

[Bombadillo]

Das WLAN / USB 3.0 Problem (reduzierte WLAN Reichweite bei Nutzung von USB 3.0) tritt mit dieser Labor immer noch auf. Ich habe inzwischen auch eine Antwort von AVM erhalten:

Guten Tag Herr ...,

die Kollegen haben sich gerade zurückgemeldet.

Das beschriebene Verhalten ist leider nicht vermeidbar, weil in der
FRITZ!Box mehrere HF-Technologien (WLAN, DECT) auf engsten Raum angeboten
werden. Es kann daher insbesondere in Verbindung mit USB 3.0 zu
Einschränkungen kommen. Hieran lässt sich bauartbedingt nichts mehr
optimieren. Deshalb bieten wir die Möglichkeit an den USB-Port auf USB 2.0
zu konfigurieren, weil dieser weniger anfällig für Störeinflüsse ist. Zwei
Ansätze könnten Sie verfolgen:

1. USB 3.0 ist nur geringfügig schneller als der USB 2.0 - Anschluss. Sie
könnten daher wie beschrieben auf USB 2.0 gehen und die Downloadraten beim
Zugriff auf den USB-Speicher im Vergleich mit USB 3.0 betrachten. Sollte
das ausreichend sein, dann wäre das die einfachste Lösung.

2. Sie versuchen WLAN selbst weiter zu optimieren. Dazu gehören ein fester
WLAN-Kanal und die Begrenzung der Kanalbandbreite. Einige Kunden erzielen
auch durch eine andere Positionierung der FRITZ!Box Verbesserung. Zudem der
Verweis auf folgende Hinweise in diesem Zusammenhang:

->
http://service.avm.de/support/de/SK...ger-Abbruch-der-WLAN-Verbindung-zur-FRITZ-Box

->
http://service.avm.de/support/de/SK...t-130-Mbit-s-statt-mit-450-Mbit-s-hergestellt


Freundliche Grüße aus Berlin

Hmm, ich weiss im Moment nicht so richtig was ich davon halten soll.

 

[Chris_e]

Das tritt hier nur bei einem Eintrag auf, der ein "-" im Rechnernamen hat ("dd-wrt"), die anderen Einträge sind ok. Haben Deine Geräte evtl. alle ein "-" im Namen?

Das kann ich leider nicht bestätigen. Bei mir taucht diese Phänomen auch bei normalen Bezeichnungen ohne jegliche Sonderzeichen auf.

 

[Outlaw]

....
Und der Mythos mit der "hidden SSID" hält sich leider hartnäckig und ist häufig genug die Ursache von Problemen, die es bei "sichtbarer" SSID gar nicht erst gibt.
....

Was gibt's denn für Probleme mit Hidden SSIDs ?? Hatte noch nie Probleme damit, egal bei welchem Gerät .... (egal ob Sinn oder Unsinn)

 

[wusel-09]

Was gibt's denn für Probleme mit Hidden SSIDs?

Das hat PeterPawn doch schön dargelegt. Kurz: Sicherheitsgewinn: keiner. Interoperabilitätsproblem: vorhanden.

 

[Outlaw]

Ich wohne aber nicht am Prenzlauer Berg ....

 

[Thomas5]

Meine DECT-Telefone verbinden sich bei dieser Labor nicht mehr mit dem Fritz!DECT 100 Repeater. In der Box ist der Repeater zu sehen und verbindet sich auch sauber mit dieser. Kann das jemand bestätigen?

*edit* Problem konnte durch Löschen des Repeaters, Reboot der Box und Neuanmeldung des DECT100 behoben werden. Danke an den AVM-Support!

 

[PeterPawn]

Ich wohne aber nicht am Prenzlauer Berg ....

Ein "überbelegtes" WLAN-Band ist aber auch nur ein Aspekt, unter dem "hidden SSID" eine - eben auch meiner Meinung nach - schlechte Entscheidung ist.

http://lmgtfy.com/?q=hidden+ssid+myth

Bisher konnte mir jedenfalls noch niemand plausibel erklären, welchen Sinn es heutzutage machen sollte, ein vorhandenes WLAN-Netz nicht "zu melden" (und sich damit in gewisser Weise auch um die rare Resource "Sendezeit" zu bewerben). In den Kindertagen, als es noch keine Tools gab ... da mag das ja mal ein erster Ansatz gegen "War-Driving" gewesen sein. Heute ist es nur noch ein Verstoß gegen den Standard ...

Alles weitere ist OT und nur eine Meinungsäußerung:
Auch wenn ich immer wieder von den Problemen lese, daß die aktuelle Fritz!OS-Labor die "bekannten MAC-Adressen" vergißt ... dann frage ich mich immer, warum AVM diesen MAC-Adressfilter überhaupt weiter anbietet und warum einige ihn immer noch benutzen.
Damit schafft man sich in meinen Augen doch nur selbst Probleme, die man ohne den Filter gar nicht hätte. Für das Spoofen von MAC-Adressen im WLAN (gerne auch genutzt zur Umgehung von Kindersicherungen) gibt es heute komplette HowTos für Kinder auf Mittelschul-Niveau im Internet ... wie sollte damit ein "ernsthafter" Angreifer aufgehalten werden ? Selbst als "second line of defense" ist das nur trügerische Sicherheit.

Besser ist wohl der Ansatz, den AVM wahrscheinlich auch schon verfolgt: Beim ersten Anmelden eines bisher unbekannten WLAN-Gerätes wird ja jetzt bereits eine entsprechende Meldung im Ereignisprotokoll festgehalten. Wenn man bei AVM den - für mich neuen - Eintrag für "NewDevice" in den Push-Mail-Einstellungen ((noch?) nicht im GUI sichtbar) für eine entsprechende E-Mail benutzen will, wäre das meines Erachtens sinnvoller als der MAC-Adressfilter, der in puncto Sicherheit einfach ein Placebo ist. Daß diese E-Mail beim Spoofing einer schon bekannten MAC-Adresse trotzdem nicht gesendet wird, ist aber auch klar ... es ist und bleibt kein Ersatz für die Absicherung des WLANs.

Wer um die Sicherheit seines Netzes besorgt ist, sollte - ich betone es gerne noch einmal: meiner Meinung nach - besser dafür sorgen, daß es nur da auch empfangbar ist, wo es gebraucht wird (Sendeleistung runter, dann klappt's auch mit dem Nachbarn ... selbst wenn man keinen ausreichend nahen Nachbarn hat, muß das WLAN ja nicht *vor* dem Gartentor empfangbar sein und ich glaube nicht an "war driver", die den Hofhund kennenlernen wollen) und sich eher auf ein ordentliches Kennwort und den WPA-Modus (besser noch WPA2) stützen. Wer sich dann noch etwas besser abschotten will, deaktiviert auch noch WPS-PBC (oder auch gleich WPS komplett) ... dann bleibt auch der Freundeskreis des Nachwuchses, der nachmittags unbeaufsichtigt im Haus ist, aus dem WLAN heraus.
Edit: Damit man mich nicht falsch versteht ... auch das Reduzieren der Sendeleistung schützt nicht wirklich vor einem ernsthaften Angreifer. Der nimmt dann einfach eine bessere Antenne und sendet selbst (ggf. auch verbotenerweise) mit etwas höherer Leistung. Aber den "Gelegenheitssniffer" oder den Nachbarsjungen auf der Suche nach Beschäftigung muß man eben nicht aus seinem Netz extra heraushalten, wenn er von dessen Existenz gar keine Ahnung hat. Das ist - auch wenn es vielleicht auf den ersten Blick nicht so aussieht - aber ein wesentlicher Unterschied zum "Verstecken" der SSID. Im diesem Fall braucht ein Angreifer nicht nur eine andere Software, sondern muß eben in entsprechende Hardware investieren.

Ich habe leider schon zu viele Haushalte und Büros gesehen (inzwischen baut AVM ja offenbar WEP endlich aus der GUI aus), wo "aus Kompatibilitätsgründen" immer noch WEP verwendet wurde, weil irgendein liebgewonnenes Gerät aus der Steinzeit des WLANs kein WPA (geschweige denn WPA2) beherrscht.

Und die gesundheitsbewußten Mitmenschen, die zur Nacht ihr WLAN ausschalten, damit die Strahlenbelastung nicht so hoch ist, aber gleichzeitig ihr Smartphone als musikalischen Wecker (und zwar nicht im Flugmodus) auf dem Nachttisch liegen haben, leben häufig auch in der Vorstellung: "Wenn ich mein WLAN ausschalte, hat das Handy ja gar keine WLAN-Verbindung ... was soll es da senden ?". Wenn man sie dann darauf aufmerksam macht, daß gerade bei nicht erreichbarem (möglichst auch noch "hidden") AP u.U. die Sendeleistung automatisch vom Smartphone immer mehr erhöht wird, um vielleicht doch noch eine Verbindung herstellen zu können, fallen sie meist aus allen Wolken ...
Ich frage mich in solchen Fällen immer wieder, ob bei der Abschaltung des WLANs dann auch alle potentiellen WLAN-Clients mit abgeschaltet werden. Ein Smartphone mit automatischer Umschaltung zwischen WLAN/3G/4G und regelmäßigem Polling, z.B. nach neuen Mails, dürfte im Mobilfunk-Modus eine wesentlich höhere "Elektrosmog"-Belastung darstellen, als im WLAN-Modus.

Obwohl ich die WLAN-Abschaltung auch einsetze ... und zwar in kleinen Firmen und Büros, da wo die Mitarbeiter nach Feierabend mitsamt ihren Smartphones, Tablets und Notebooks dann auch wirklich verschwunden sind. Da ist es dann meines Erachtens ein Zeichen guter Nachbarschaft, wenn man den diversen privaten WLANs rundherum in deren Hauptnutzungszeit das Band überläßt, auch wenn ein AP ohne aktive Clients nur in regelmäßigen Abständen mit Beacons seine Anwesenheit bekannt gibt. Aber schon ein WLAN-Drucker im Büro, der dann nicht auch schläft und verzweifelt alle 3 Sekunden nach seinem AP schreit, relativiert da den Erfolg.

Der Gewinn an Sicherheit durch die zeitweise Abschaltung des WLANs ist aber sicherlich für viele auch ein Aspekt. Gerade zur Nacht, wenn die Alarmanlage eingeschaltet ist und das WLAN ausgeschaltet wurde, ergibt sich so ein anheimelndes Gefühl der Abgeschiedenheit von der Welt ... das kann ich gut nachvollziehen.
Und rein rechnerisch verringert sich die Angriffswahrscheinlichkeit bei 16h "WLAN ein" und 8h "WLAN aus" ja auch um ein Drittel ... aber die meisten potentiellen Angreifer haben (anders als Diebe in der Nacht) wahrscheinlich auch ein gewisses Bedürfnis nach nächtlicher Ruhe.
Ich will das mit der Abschaltung zur Verringerung der Angriffsfläche aber nicht kleinreden ... man muß eben nur - je nach seiner konkreten Situation - die Vor- und Nachteile abwägen. Wenn ich (selbst erlebt) eine Fritz!Box in einem Haus sehe, das nur alle 5-6 Wochen mal für ein Wochenende genutzt wird (weil der Eigentümer samt Familie inzwischen im Ausland lebt) und da wird dann täglich zur Nacht das WLAN abgeschaltet, dann frage ich mich eben eher, warum es am Tage überhaupt ständig läuft.

 

[PeterPawn]

Ungültige Anzeige der verlinkten Namen von WLAN-Geräten

Wer ohnehin wegen der debug.cfg-Problematik ein eigenes Image mit dieser Labor-Version benutzt (oder sonst irgendwie ein eigenes Patch-System auf seiner Box pflegt), kann ja mal den folgenden Patch auf /usr/www/avm/lua/net_devices.lua anwenden:

--- /usr/www/avm/lua/net_devices.lua
+++ /var/media/ftp/patched/net_devices.lua
@@ -1738,6 +1738,15 @@
 str = str..get_netdev_buttons(elem,false,true,true)..[[</tr>]]
 return str
 end
+function get_ssid_with_link_new(elem)
+local ssid = {}
+if elem.url and elem.url~="" and elem.active=="1" then
+ssid = html.a{get_ssid(elem), target="_blank", href=elem.url}
+else
+ssid = html.raw(get_ssid(elem))
+end
+return ssid
+end
 function create_dev_row_wlan_new(n, elem, show_list)
 if (elem.radiotype=="1") then
 return ""
@@ -1771,7 +1780,7 @@
 end
 end
 if show_list["name"] then
-row.add(html.td{get_ssid_with_link(elem), title=get_ssid_as_title(elem), class="cut_overflow"})
+row.add(html.td{get_ssid_with_link_new(elem), title=get_ssid_as_title(elem), class="cut_overflow"})
 end
 if show_list["ip"] then
 row.add(html.td{net_devices.get_ip(elem)})

Damit sollte die Darstellung von Links zu WLAN-Clients mit aktivem Dienst auf TCP-Port 80 wieder funktionieren.
Ist zwar nur eine Interimslösung ... aber man weiß ja nie, wann die nächste Labor-Version dann kommt.

 

[H´Sishi]

In der -28144-Build der 7390 ist auch der Fehler mit der fehlerhaften Link-Erzeugung in der WLAN-Übersicht. Ich habe hier die Schnipsel aus den jeweiligen Quelltexten gepostet.
Der entsprechende Schnipsel aus der LAN- und der WLAN-Übersicht sollte zwar das Gleiche machen, aber aus irgendeinem Grund kommt der Webserver der Box nicht damit zurecht und verbockt es in der WLAN-Übersicht.

 

[PeterPawn]

Der entsprechende Schnipsel aus der LAN- und der WLAN-Übersicht sollte zwar das Gleiche machen, aber aus irgendeinem Grund kommt der Webserver der Box nicht damit zurecht und verbockt es in der WLAN-Übersicht.

In der 28144 (7390 und 7490) wurde bei der Umstellung der Anzeige von WLAN-Clients auf die zusätzlichen Angaben (und nur für die WLAN-Clients) auch "unter der Haube" vom Zusammenklittern von Zeichenketten aus HTML-Schnipseln auf einen eher objektorientierten Ansatz umgestellt. Bei der Darstellung der Namensspalte wurde dann wieder auf die alten "String"-Methoden zurückgegriffen. Aus diesem Mischmasch entsteht die Anzeige eines HTML-Links als "reiner" Text.

PS: Der Patch funktioniert auch für die 28144 der 7390 ...

 

[Canni]

Ich hatte zwischenzeitlich massive Probleme mit Vodafone TV: dort wurde das EPG nicht mehr geladen, es konnte auch nicht mehr manuell aktualisiert werden. Dadurch schlugen die geplanten Aufnahmen fehl. Ich musste daher leider zurück auf FRITZ!OS 06.05.

Wer kann das Problem nachstellen? Auch die Mediathek lässt sich nun wieder bedienen. Es muss also mit den aktuellen Beta-Versionen zu tun haben.

 

[Hans Juergen]

Bei der Rufumleitung werden bei mir die Wahlregeln nicht mehr beachtet. Die Umleitung (Parallelruf) zum Handy soll über FVD.com gehen, lief aber über den Standardanschluss 1&1. Habe jetzt die Ausgangsnummer auf FVD.com festgelegt.

 

[r0mek]

Die "Internet-Telefon LED" blinkt die ganze Zeit seit dem Update - gibt es hierzu eine Abhilfe. Alle Mailboxen haben meine Nachrichten. Mit der regulären FW gibt es dieses Phänomen nicht.

 

[Lecter]

Labor-Bugs:

- Nokia C7 läßt sich nicht mehr ans WLAN anmelden

- WLAN wacht nicht mehr auf nach Nacht-Abschaltung

-Sony Smart-TV steht cryptisch in der WLAN-Geräteliste: <a target="_blank" href="http://192.168.

Lausige Labor-Version...

 

[tricker2000]

Habe gerade diesen Logeintrag entdeckt und weiss nicht was er Bedeutet.
Anmeldung einer App des Benutzers dslf-config von IP-Adresse 192.168.XXX.XX gescheitert (falsches Kennwort).
Kann mir da Jemand mal mit der Fackel Leuchten bitte.

Danke Tricker2000