An der Leitung hat sich nix geändert, vor ca. 4 Labors ging das alles noch und der Anschluss läuft ansonsten ohne Probleme.
Zudem bin ich in diesem Fred nicht der einzige.
Zudem bin ich in diesem Fred nicht der einzige.
ciesla
Aktives Mitglied
- Mitglied seit
- 12 Dez 2004
- Beiträge
- 2,215
- Punkte für Reaktionen
- 65
- Punkte
- 48
Ich habe auch solche Erfahrungen in dieser Art gemacht.
Unklar bleibt, ob es nur nachlässige Programmierung der Firmwares bei AVM ist (= Masse statt Klasse) oder ob die Box (firmware-)speichermäßig am Ende ist, so daß bestimmte Kollisionen entstehen, die sich nur durch PoR beseitigen lassen ...
An der CPU dürfte es (noch) nicht liegen, da die einigermaßen Reserven hat.
Unklar bleibt, ob es nur nachlässige Programmierung der Firmwares bei AVM ist (= Masse statt Klasse) oder ob die Box (firmware-)speichermäßig am Ende ist, so daß bestimmte Kollisionen entstehen, die sich nur durch PoR beseitigen lassen ...
An der CPU dürfte es (noch) nicht liegen, da die einigermaßen Reserven hat.
Das Heißt trotzdem nichts, denn die allermeisten haben keine Probleme. Ich vermute ein KKK.
Ich empfehle die Box neu auszusetzen und alles von Hand neu eingeben.
UsAs
Mitglied
- Mitglied seit
- 7 Dez 2014
- Beiträge
- 218
- Punkte für Reaktionen
- 32
- Punkte
- 28
Hatte ich auch nie gehabt. DIe Dauer des Syncs war vielleicht etwas unterschiedlich, gekommen ist er aber immer ohne POR.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Bei mir wird seit einigen Labor-Versionen das WLAN nicht mehr richtig initialisiert (Fehler #0101). Aus irgendeinem Grund wird bei Starten des wland keine korrekte Laufzeit-Konfiguration für das WLAN erzeugt, obwohl die 06.30 mit genau denselben WLAN-Einstellungen (jeweils nach Umschaltung auf das alternative System) problemlos arbeitet, die Konfiguration in der wlan.cfg kann also nicht vollkommen ungültig sein und ein Hardware-Fehler ist auch auszuschließen.
Nun ist meine WLAN-Konfiguration alles andere als jungfräulich und ich habe sicherlich häufig genug auch daran von Hand Änderungen vorgenommen, damit da einiges durcheinander sein kann ... Problem ist bloß, daß selbst ein Werksreset unter der Labor-Version offenbar nicht helfen will, jedenfalls nicht unter einer mit modfs behandelten Firmware und ich weiß noch nicht, woran das liegen soll.
Da AVM auch die WLAN-Konfiguration überarbeitet hat (das, was sich früher in /etc/ath tummelte, ist jetzt verschwunden - vermutlich wurde es ohnehin schon eine Weile nicht mehr genutzt und durch die libacfg.so ersetzt?), weiß ich auch noch nicht, wo diese Vorbereitungen jetzt stattfinden sollen - ich bin nur verblüfft, daß offenbar niemand anderes dieses Problem bisher hatte.
Ich habe auch die Box schon stromlos gemacht ... die Tatsache, daß nach Umschaltung auf 06.30 das WLAN auch vorher sofort wieder funktionierte, ließ mich ohnehin an einer solch simplen Lösung zweifeln - es hat auch nichts geholfen.
Sieht also so aus, als wenn ich nicht wirklich auf die neue Version umsteigen könnte, sofern der aktuelle Stand zum Release befördert wird. Aber vor einer endgültigen Entscheidung muß ich erst mal die definitive Release-Version abwarten ... die o.a. Feststellungen (mit dem Werksreset) gelten für die 31996 und die 31739 vor vier Wochen bei meinem ersten halbherzigen Versuch der Fehlersuche - das nicht funktionierende WLAN tritt m.E. seit 31504 auf (ein systematischer Test zur Ermittlung der ersten betroffenen Version ist mir derzeit noch zu viel Aufwand) und hatte mich halt nie wirklich beeinträchtigt, da ich immer nur für einige Tests auf die 06.36 gegangen bin und dann ein WLAN-Ausfall kaum auffiel, bevor ich wieder zur 06.30 zurück bin.
Meine Frage geht also an die Benutzer von modfs in Kombination mit dieser (oder einer der letzten drei) Labor-Version(en): Hat noch jemand ähnliche Probleme? Ich habe zwar sicherlich einige zusätzliche Modifikationen eingebaut und auch einige Binaries (insb. die Busybox) ersetzt, aber keine Dateien, die für eine WLAN-Konfiguration notwendig sein könnten, bewußt geändert. Das ist also vermutlich ein "side effect" einer anderen Änderung.
Die wlan_sanity.log sieht bei Auftreten des Fehlers so aus:
und die wland_support.log enthält nach dem Crash noch einige zusätzliche Zeilen:
Der fehlende Pfad unterhalb von /proc/sys/dev macht mich weniger nervös als das überzählige Leerzeichen in der Fehlermeldung für eeprom_count, der Pfad existiert sicherlich erst dann, wenn wenigstens eine Basisfunktionalität des WLAN-Treibers zur Verfügung steht nach dem Laden von Treibermodulen. Bei mir werden ja nicht einmal diese Treiber richtig geladen ... der Grund dafür liegt im Moment für mich noch im Dunklen.
Irgendwann heute nacht werde ich dann mal ergründen, ob nun wirklich Modifikationen der Firmware durch mich daran die Schuld tragen oder ob das ein generelles Problem dieser 7490 ist ... vielleicht mißfallen der Box ja auch die ständigen Wechsel zwischen 06.36 und 06.30 oder irgendwo hat AVM ein Flag versteckt ("wlancfg_version" ist bei mir nebenbei bemerkt "6"), mit dem nach dem ersten Umstieg auf 06.36 dann doch vermerkt wird, daß die Konfiguration an die neue Version angepaßt wurde und das findet nun (event. nach zwischenzeitlichen Änderungen am WLAN in der 06.30) nicht erneut statt. Aber das erklärt wieder nicht, warum es nach Werksreset auch nicht funktionieren will. Alles etwas merkwürdig ... aber wenn AVM tatsächlich ein Release für angezeigt hält, wird es wohl Zeit für eine intensivere Fehlersuche.
Nun ist meine WLAN-Konfiguration alles andere als jungfräulich und ich habe sicherlich häufig genug auch daran von Hand Änderungen vorgenommen, damit da einiges durcheinander sein kann ... Problem ist bloß, daß selbst ein Werksreset unter der Labor-Version offenbar nicht helfen will, jedenfalls nicht unter einer mit modfs behandelten Firmware und ich weiß noch nicht, woran das liegen soll.
Da AVM auch die WLAN-Konfiguration überarbeitet hat (das, was sich früher in /etc/ath tummelte, ist jetzt verschwunden - vermutlich wurde es ohnehin schon eine Weile nicht mehr genutzt und durch die libacfg.so ersetzt?), weiß ich auch noch nicht, wo diese Vorbereitungen jetzt stattfinden sollen - ich bin nur verblüfft, daß offenbar niemand anderes dieses Problem bisher hatte.
Ich habe auch die Box schon stromlos gemacht ... die Tatsache, daß nach Umschaltung auf 06.30 das WLAN auch vorher sofort wieder funktionierte, ließ mich ohnehin an einer solch simplen Lösung zweifeln - es hat auch nichts geholfen.
Sieht also so aus, als wenn ich nicht wirklich auf die neue Version umsteigen könnte, sofern der aktuelle Stand zum Release befördert wird. Aber vor einer endgültigen Entscheidung muß ich erst mal die definitive Release-Version abwarten ... die o.a. Feststellungen (mit dem Werksreset) gelten für die 31996 und die 31739 vor vier Wochen bei meinem ersten halbherzigen Versuch der Fehlersuche - das nicht funktionierende WLAN tritt m.E. seit 31504 auf (ein systematischer Test zur Ermittlung der ersten betroffenen Version ist mir derzeit noch zu viel Aufwand) und hatte mich halt nie wirklich beeinträchtigt, da ich immer nur für einige Tests auf die 06.36 gegangen bin und dann ein WLAN-Ausfall kaum auffiel, bevor ich wieder zur 06.30 zurück bin.
Meine Frage geht also an die Benutzer von modfs in Kombination mit dieser (oder einer der letzten drei) Labor-Version(en): Hat noch jemand ähnliche Probleme? Ich habe zwar sicherlich einige zusätzliche Modifikationen eingebaut und auch einige Binaries (insb. die Busybox) ersetzt, aber keine Dateien, die für eine WLAN-Konfiguration notwendig sein könnten, bewußt geändert. Das ist also vermutlich ein "side effect" einer anderen Änderung.
Die wlan_sanity.log sieht bei Auftreten des Fehlers so aus:
Code:
--BEGIN_SANITY_META--
severity: fatal
error: 0101
count: 5
--END_SANITY_META--
--BEGIN_WLAND_SUPPORT--
01:00:53: open
WLAND:[03568]:01:00.53/[53.60]:checking wland prerequisites...
WLAND:[03568]:01:00.54/[54.45]:derived config 'AP-only mode Dual', ID: 1 (0x00000000)
WLAND:[03568]:01:00.54/[54.89]:repeating_module_init:173: krextd lib available 0
WLAND:[03568]:01:00.55/[55.16]:cfg_hal_setup_eeprom: error opening /proc/sys/dev/ath/avm_ath_extensions/ eeprom_count (No such file or directory)
WLAND:[03568]:01:00.55/[55.16]:lib_hal_hardware_init:380: failed to create EEPROM device nodes
WLAND:[03568]:01:00.55/[55.16]:lib_hal_hardware_init: failed with status 0x80000001 (0x80000001)
WLAND:[03568]:01:00.55/[55.22]:cfg_mgr_event_handler_cb:1744: Hardware initialization failed with status 0x80000001
WLAND:[03568]:01:00.55/[55.76]:cfg_hal_handle_target_crash:3368: /proc/sys/dev/ath/avm_ath_extensions/tgt_crashed: failed
WLAND:[03568]:01:00.55/[55.76]:cfg_hal_handle_target_crash:3439: aborting with error: No such file or directory
WLAND:[03568]:01:00.56/[56.1]:cfg_hal_setup_eeprom: error opening /proc/sys/dev/ath/avm_ath_extensions/ eeprom_count (No such file or directory)
WLAND:[03568]:01:00.56/[56.1]:lib_hal_hardware_init:380: failed to create EEPROM device nodes
WLAND:[03568]:01:00.56/[56.1]:lib_hal_hardware_init: failed with status 0x80000001 (0x80000001)
WLAND:[03568]:01:00.56/[56.2]:cfg_mgr_event_handler_cb:1744: Hardware initialization failed with status 0x80000001
WLAND:[03568]:01:00.56/[56.21]:cfg_hal_handle_target_crash:3368: /proc/sys/dev/ath/avm_ath_extensions/tgt_crashed: failed
WLAND:[03568]:01:00.56/[56.21]:cfg_hal_handle_target_crash:3439: aborting with error: No such file or directory
WLAND:[03568]:01:00.56/[56.44]:cfg_hal_setup_eeprom: error opening /proc/sys/dev/ath/avm_ath_extensions/ eeprom_count (No such file or directory)
WLAND:[03568]:01:00.56/[56.44]:lib_hal_hardware_init:380: failed to create EEPROM device nodes
WLAND:[03568]:01:00.56/[56.44]:lib_hal_hardware_init: failed with status 0x80000001 (0x80000001)
WLAND:[03568]:01:00.56/[56.44]:cfg_mgr_event_handler_cb:1744: Hardware initialization failed with status 0x80000001
WLAND:[03568]:01:00.56/[56.64]:cfg_hal_handle_target_crash:3368: /proc/sys/dev/ath/avm_ath_extensions/tgt_crashed: failed
WLAND:[03568]:01:00.56/[56.64]:cfg_hal_handle_target_crash:3439: aborting with error: No such file or directory
WLAND:[03568]:01:00.56/[56.92]:cfg_hal_setup_eeprom: error opening /proc/sys/dev/ath/avm_ath_extensions/ eeprom_count (No such file or directory)
WLAND:[03568]:01:00.56/[56.92]:lib_hal_hardware_init:380: failed to create EEPROM device nodes
WLAND:[03568]:01:00.56/[56.92]:lib_hal_hardware_init: failed with status 0x80000001 (0x80000001)
WLAND:[03568]:01:00.56/[56.92]:cfg_mgr_event_handler_cb:1744: Hardware initialization failed with status 0x80000001
WLAND:[03568]:01:00.57/[57.9]:cfg_hal_handle_target_crash:3368: /proc/sys/dev/ath/avm_ath_extensions/tgt_crashed: failed
WLAND:[03568]:01:00.57/[57.9]:cfg_hal_handle_target_crash:3439: aborting with error: No such file or directory
WLAND:[03568]:01:00.57/[57.31]:cfg_hal_setup_eeprom: error opening /proc/sys/dev/ath/avm_ath_extensions/ eeprom_count (No such file or directory)
WLAND:[03568]:01:00.57/[57.31]:lib_hal_hardware_init:380: failed to create EEPROM device nodes
WLAND:[03568]:01:00.57/[57.31]:lib_hal_hardware_init: failed with status 0x80000001 (0x80000001)
WLAND:[03568]:01:00.57/[57.31]:cfg_mgr_event_handler_cb:1744: Hardware initialization failed with status 0x80000001
WLAND:[03568]:01:00.57/[57.33]:config_mgr_prepare_recovery:1598, WARNING: Explicit wland shutdown, reason: Maximum number of consecutive recoveries exceeded!
--END_WLAND_SUPPORT--
--BEGIN_DEV_DEBUG--
--END_DEV_DEBUG--
--BEGIN_HOSTAPD_SUPPORT--
--END_HOSTAPD_SUPPORT--
--BEGIN_WPA_SUPP_SUPPORT--
--END_WPA_SUPP_SUPPORT--
--BEGIN_HOSTAPD_SOCKETS--
--END_HOSTAPD_SOCKETS--
--BEGIN_WPA_SUPP_SOCKETS--
--END_WPA_SUPP_SOCKETS--
--BEGIN_DEV_TGT_DEBUG--
--END_DEV_TGT_DEBUG--
--BEGIN_WLANCFG_SSIDS--
ssid = "Midgard";
ssid_scnd = "Asgard";
hidden_ssid = 0;
guest_ssid = "G_Midgard";
STA_ssid = "";
STA_ssid_scnd = "";
--END_WLANCFG_SSIDS--
--BEGIN_EMPTY_PSKS--
Empty PSKs: STA_pskvalue STA_pskvalue_scnd
WLAN key is set in Urlader-Env
--END_EMPTY_PSKS--
Code:
WLAND:[03568]:01:00.58/[58.23]:cfg_hal_handle_target_crash:3368: /proc/sys/dev/ath/avm_ath_extensions/tgt_crashed: failed
WLAND:[03568]:01:00.58/[58.23]:cfg_hal_handle_target_crash:3439: aborting with error: No such file or directory
WLAND:[03568]:01:00.58/[58.61]:cfg_hal_handle_target_crash:3368: /proc/sys/dev/ath/avm_ath_extensions/tgt_crashed: failed
WLAND:[03568]:01:00.58/[58.61]:cfg_hal_handle_target_crash:3439: aborting with error: No such file or directory
WLAND:[03568]:01:00.58/[58.61]:__event_mgr_unregister_ext_event_handler:540: Invalid event_fd '-2'
WLAND:[03568]:01:00.58/[58.61]:cfg_hal_get_ap_boot_mode:2648: invalid AP_BOOT_MODE mode 0x0
WLAND:[03568]:01:00.58/[58.84]:Unload 'libwlanrext'((nil))
WLAND:[03568]:01:00.58/[58.87]:util_deinit:28: ENTERIrgendwann heute nacht werde ich dann mal ergründen, ob nun wirklich Modifikationen der Firmware durch mich daran die Schuld tragen oder ob das ein generelles Problem dieser 7490 ist ... vielleicht mißfallen der Box ja auch die ständigen Wechsel zwischen 06.36 und 06.30 oder irgendwo hat AVM ein Flag versteckt ("wlancfg_version" ist bei mir nebenbei bemerkt "6"), mit dem nach dem ersten Umstieg auf 06.36 dann doch vermerkt wird, daß die Konfiguration an die neue Version angepaßt wurde und das findet nun (event. nach zwischenzeitlichen Änderungen am WLAN in der 06.30) nicht erneut statt. Aber das erklärt wieder nicht, warum es nach Werksreset auch nicht funktionieren will. Alles etwas merkwürdig ... aber wenn AVM tatsächlich ein Release für angezeigt hält, wird es wohl Zeit für eine intensivere Fehlersuche.
Zuletzt bearbeitet:
@PeterPawn: Ich habe auch kein reguläres Update durchgeführt, stattdessen schon seit der 06.29 immer ausschließlich über modfs. Dennoch kann ich bei mir dieses Problem mit dem WLAN nicht beobachten. Allerdings hatte ich es mal in grauer Vorzeit. Die Lösung damals war, die WLAN-Einstellungen über die Oberfläche hier und da zu verändern, damit die Konfigurationsdateien mal neu geschrieben wurden. Danach habe ich einfach neu gestartet, und das WLAN-System konnte wieder initialisiert werden.
Zuvor half aber tatsächlich nichts: Stromlos machen oder Werksreset - WLAN wurde nicht gestartet. Daher ging ich seinerzeit schon von einem Defekt der Box aus!
Ich vermute, es liegt auch daran, dass die Box über ein vollkommen eigenständiges WLAN-System verfügt, nämlich dieses SoC von Qualcomm Atheros. Das bringt ja sogar seinen eigenen Flash mit.
Ich verweise dazu auf diese Bilderstrecke bei Teltarif, in der sehr gut alle Teile der 7490 aufgezeigt werden (hier im Speziellen das WiFi-SoC):
http://www.teltarif.de/avm-fritzbox-7490-aufgeschraubt-innenleben/news/55666.html?page=9
Auch beim DECT-Modul ist es ja bekanntlich so, dass die Schlüsselpaare für die angemeldeten Geräte direkt im DECT-Chip und nicht etwa in einer Config-Datei abgelegt werden. Deswegen kann man diese auch nicht restaurieren und muss die Geräte ggf. neu anmelden. Beim WLAN stelle ich mir das ähnlich vor: Die Box startet einfach nur das eigenständige System und wartet auf Rückmeldung oder prüft hin und wieder den Status. Die Config wird dann bei Änderungen neu da rein geschrieben. Aber das System arbeitet trotzdem vollkommen eigenständig.
Hinzu kommt noch der Umstand "WLAN key is set in Urlader-Env": Ich hoffe, der Schlüssel ist dort bei Dir so gespeichert, wie das neue FRITZ!OS es erwartet. An Deiner Stelle würde ich bei laufender 06.36 einmal den Schlüssel über die Oberfläche (!) ändern und danach wieder zurück ändern. Ich hoffe, dass dies bei nicht gestartetem WLAN möglich ist. Dadurch wird vielleicht die Config neu in den EEPROM vom WiFi-SoC geschrieben (und nicht nur in den URLADER).
Das aktivierte Profil "config 'AP-only mode Dual', ID: 1 (0x00000000)" ist bei mir jedenfalls dasselbe. Somit arbeitet das SoC als AP in beiden Netzen und nicht etwa als Repeater oder Client eines anderen Netzes.
PS.: Wenn diese Version final werden sollte, dann viel Spaß mit Telekom-Anschlüssen. Mein ADSL2+ der Telekom läuft mit dem DSL-Treiber ganz und gar nicht vernünftig. Kann man im Prinzip vergessen. Sowohl ein "popeliger" Speedport Entry 2 als auch eine olle Easybox 803a schlagen die FRITZ!Box an meinem Anschluss um Längen - das kann ja wohl nicht sein. Und bei V-VDSL2 der Telekom scheint's bei vielen Nutzern ja auch nicht gerade rund zu laufen.
Zuvor half aber tatsächlich nichts: Stromlos machen oder Werksreset - WLAN wurde nicht gestartet. Daher ging ich seinerzeit schon von einem Defekt der Box aus!
Ich vermute, es liegt auch daran, dass die Box über ein vollkommen eigenständiges WLAN-System verfügt, nämlich dieses SoC von Qualcomm Atheros. Das bringt ja sogar seinen eigenen Flash mit.
Ich verweise dazu auf diese Bilderstrecke bei Teltarif, in der sehr gut alle Teile der 7490 aufgezeigt werden (hier im Speziellen das WiFi-SoC):
http://www.teltarif.de/avm-fritzbox-7490-aufgeschraubt-innenleben/news/55666.html?page=9
Auch beim DECT-Modul ist es ja bekanntlich so, dass die Schlüsselpaare für die angemeldeten Geräte direkt im DECT-Chip und nicht etwa in einer Config-Datei abgelegt werden. Deswegen kann man diese auch nicht restaurieren und muss die Geräte ggf. neu anmelden. Beim WLAN stelle ich mir das ähnlich vor: Die Box startet einfach nur das eigenständige System und wartet auf Rückmeldung oder prüft hin und wieder den Status. Die Config wird dann bei Änderungen neu da rein geschrieben. Aber das System arbeitet trotzdem vollkommen eigenständig.
Hinzu kommt noch der Umstand "WLAN key is set in Urlader-Env": Ich hoffe, der Schlüssel ist dort bei Dir so gespeichert, wie das neue FRITZ!OS es erwartet. An Deiner Stelle würde ich bei laufender 06.36 einmal den Schlüssel über die Oberfläche (!) ändern und danach wieder zurück ändern. Ich hoffe, dass dies bei nicht gestartetem WLAN möglich ist. Dadurch wird vielleicht die Config neu in den EEPROM vom WiFi-SoC geschrieben (und nicht nur in den URLADER).
Das aktivierte Profil "config 'AP-only mode Dual', ID: 1 (0x00000000)" ist bei mir jedenfalls dasselbe. Somit arbeitet das SoC als AP in beiden Netzen und nicht etwa als Repeater oder Client eines anderen Netzes.
PS.: Wenn diese Version final werden sollte, dann viel Spaß mit Telekom-Anschlüssen. Mein ADSL2+ der Telekom läuft mit dem DSL-Treiber ganz und gar nicht vernünftig. Kann man im Prinzip vergessen. Sowohl ein "popeliger" Speedport Entry 2 als auch eine olle Easybox 803a schlagen die FRITZ!Box an meinem Anschluss um Längen - das kann ja wohl nicht sein. Und bei V-VDSL2 der Telekom scheint's bei vielen Nutzern ja auch nicht gerade rund zu laufen.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Woher weißt Du, daß es sich tatsächlich um die 06.50 handelt und nicht nur erst einmal um eine "Probeversion"? Abgesehen davon mag AVM ja langsam auf die Zielgerade einbiegen, aus den verfügbaren Developer-Versionen und dort event. per Update-Abfrage aufgetauchten Versionen jetzt einen Paarhufer aus bäuerlicher Zucht zu kreieren, den man durch's Dorf treiben kann, ist vielleicht trotzdem nicht sehr hilfreich.
Oder willst Du tatsächlich, daß hier jetzt der nächste Leser Dich fragt, wo Du diese Version gesehen hast und wie er da rankommt? Du bist hier nicht in Deinem "Sammelthread" und den liest auch nicht jeder ... der einzige, der in diesem Thread bisher über eine 06.50 schwadronierte und über deren baldiges Erscheinen spekulierte, bist seit gestern morgen Du in mehreren Beiträgen gewesen. Kannst Du nicht erst einmal die Veröffentlichung durch AVM abwarten, bevor Du Deinerseits den Erscheinungstermin bekanntgibst?
Den Vorschlag mit "Recovery" greife ich natürlich gerne auf ... sollte ich dazu die Recovery-Version für die 06.30 verwenden oder hast Du die 06.50 auch schon als Recovery-Version gesichtet? Warum sollte das eigentlich einen Unterschied machen im Vergleich zu den "Werkseinstellungen"? Ich habe im Moment keine TFFS-Nodes < 100 mit irgendwelchen Daten, wenn man mal von der "fwattrib" absieht, die zeitweise den Inhalt "TELNET" hat, bis ich sie wieder löschen lasse (im 60-Minuten-Rhythmus läuft einfach das Skript:
Code:
#!/bin/sh
rc=0
[ x"$(ctlmgr_ctl r box status/signed_firmware)" == x"0" ] && echo clear_id 87 >/proc/tffs || rc=1
exit $rcAber das bringt mich dann wieder darauf, daß ein Skript zum Zerlegen eines TFFS-Dumps in die einzelnen Einträge (egal ob Environment, Konfigurationsdatei oder "hidden setting" wie Betriebsstundenzähler - wird der überhaupt noch richtig verwendet? bei mir steht da nur Unsinn, wenn man die Namen wörtlich nimmt) schon lange überfällig ist und wenn jetzt AVM im Rahmen der erweiterten Support-Daten einen solchen Dump mit ausgibt, braucht es ohnehin eine Kontroll-Möglichkeit für den Benutzer, was da am Ende enthalten ist. Vielleicht finden sich da tatsächlich irgendwelche anderen Werte wieder ... lassen wir uns mal überraschen.
UsAs
Mitglied
- Mitglied seit
- 7 Dez 2014
- Beiträge
- 218
- Punkte für Reaktionen
- 32
- Punkte
- 28
Inwiefern problematisch bei dir? Ich frage aus Interesse, da bei mir das genaue Gegenteil der Fall ist.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
@KiRKman:
Leider läßt die neue GUI-Version keinerlei Änderungen an den WLAN-Einstellungen zu, solange der wland nicht richtig läuft - damit ist auch kein "Neuschreiben" der wlan.cfg möglich (und ohne den Treiber kommt die Box wohl auch nicht an das EEPROM des WLAN-Chipsets).
Neben Werksreset hatte ich in einem ersten Schritt auch das Ersetzen der wlan.cfg durch die Standard-Datei aus /etc probiert (das macht der init-Prozess der Box auch, wenn keine Konfiguration existiert) ... das brachte aber auch nicht den gewünschten Erfolg.
Sollte wirklich demnächst eine finale Version erscheinen (und das heißt bei mir, daß sich AVM gerne noch zwei Wochen Zeit nehmen möge), habe ich ja über die Feiertage genug Zeit, das genauer zu untersuchen. Nach meinem Eindruck werden eben die Treiber schon nicht richtig geladen. aae.ko müßte der erste zu ladende Treiber sein, der wird dann (wahrscheinlich auch bei der 06.36 noch) von den folgenden Treibern (adf, hif_gmac, athlogger, fwd und atd) zumindest teilweise benötigt. Aber unter 06.36 ist bei mir dann keines dieser Module geladen ... die werden wohl auch explizit und in der richtigen Reihenfolge von irgendeiner Komponente geladen ... denn in der modules.dep tauchen sie nicht auf, was das automatische Laden eigentlich ausschließt. Irgendwie muß die Box vorher feststellen (wenn man mal unterstellt, daß dieser Konfigurationsmechanismus - wie alle anderen AVM-Komponenten auch - wieder für alle Boxen derselbe sein wird), auf welcher Hardware sie läuft und daraus die zu ladenden Treiber ableiten. An dieser Stelle sitzt nach meiner Vorstellung das Problem ... ich glaube eigentlich daran, daß nicht einmal die Basis-Kommunikation mit der WLAN-Hardware ins Rollen kommt, weil schon der dafür zuständige Treiber (welcher das auch immer sein mag) bei mir nicht geladen wird.
Leider läßt die neue GUI-Version keinerlei Änderungen an den WLAN-Einstellungen zu, solange der wland nicht richtig läuft - damit ist auch kein "Neuschreiben" der wlan.cfg möglich (und ohne den Treiber kommt die Box wohl auch nicht an das EEPROM des WLAN-Chipsets).
Neben Werksreset hatte ich in einem ersten Schritt auch das Ersetzen der wlan.cfg durch die Standard-Datei aus /etc probiert (das macht der init-Prozess der Box auch, wenn keine Konfiguration existiert) ... das brachte aber auch nicht den gewünschten Erfolg.
Sollte wirklich demnächst eine finale Version erscheinen (und das heißt bei mir, daß sich AVM gerne noch zwei Wochen Zeit nehmen möge), habe ich ja über die Feiertage genug Zeit, das genauer zu untersuchen. Nach meinem Eindruck werden eben die Treiber schon nicht richtig geladen. aae.ko müßte der erste zu ladende Treiber sein, der wird dann (wahrscheinlich auch bei der 06.36 noch) von den folgenden Treibern (adf, hif_gmac, athlogger, fwd und atd) zumindest teilweise benötigt. Aber unter 06.36 ist bei mir dann keines dieser Module geladen ... die werden wohl auch explizit und in der richtigen Reihenfolge von irgendeiner Komponente geladen ... denn in der modules.dep tauchen sie nicht auf, was das automatische Laden eigentlich ausschließt. Irgendwie muß die Box vorher feststellen (wenn man mal unterstellt, daß dieser Konfigurationsmechanismus - wie alle anderen AVM-Komponenten auch - wieder für alle Boxen derselbe sein wird), auf welcher Hardware sie läuft und daraus die zu ladenden Treiber ableiten. An dieser Stelle sitzt nach meiner Vorstellung das Problem ... ich glaube eigentlich daran, daß nicht einmal die Basis-Kommunikation mit der WLAN-Hardware ins Rollen kommt, weil schon der dafür zuständige Treiber (welcher das auch immer sein mag) bei mir nicht geladen wird.
Zuletzt bearbeitet:
Einmal nervt mich, dass die Geschwindigkeit jedes Mal anders ist: Von 4.000 bis 11.500 kbit/s ist alles dabei. Dann habe ich unfassbare Mengen an CRC-Fehlern; teilweise gibt's 400 Fehler pro Minute (!). Wie kann sowas sein? Die Balken unter "Statistik" kann ich gar nicht erst sehen, auch fehlt die Beschriftung an der linken Seite. Anscheinend geht die Grafik nur bis 10.000 Fehler pro Stunde.
Hinzu kommt, dass es teilweise ziemlich lange dauert, bis ich überhaupt "showtime" gehe. Und da ich nach dem Start der Box rund ein Dutzend mal manuell neu syncen muss, bis es endlich ordentlich ist, und dabei teilweise zwei Minuten auf den nächsten Sync warten muss, nervt es noch mehr.
Das Komische an der Sache: Ist der Sync mal ordentlich, läuft es perfekt. Dann habe ich eine hohe Geschwindigkeit und keinerlei CRC-Fehler. Da kommen im schlimmsten Fall 80 CRC-Fehler pro Minute zusammen. Trotz hoher Geschwindigkeit!
Ich kann also 4.000 kbit/s haben mit 450 CRC-Fehlern pro Minute; aber ich kann auch 12.000 kbit/s haben mit 00 CRC-Fehlern pro Minute. Das hängt nämlich bei mir überhaupt nicht mit der Geschwindigkeit zusammen!
Mit den Reglern der Störsicherheit habe ich stundenlang rumprobiert und auch den Port durch die Telekom resetten und sogar mal neu konfigurieren lassen. Es hängt damit ebenfalls nicht zusammen. Ich kann den SNR-Regler ganz nach links schieben (4), habe eine winzige Geschwindigkeit und trotzdem irre viele Fehler. Regler ganz nach rechts (0), hohe Geschwindigkeit und keine Fehler - dies ist ebenso möglich.
Auffällig ist, dass der alte Treiber die tiefen Frequenzen wesentlich mehr belegt als der neue Treiber. Dieser legt anscheinend alles nach hinten, und dort erleide ich viele Störungen. Ich ersehe das am Spektrum.
Natürlich sende ich fast täglich Feedback dazu an AVM. Manchmal benötige ich 17 bis 21 Re-Syncs, bis es läuft. Und dann darf es keinen Stromausfall geben...
Wenn dieser Treiber final werden sollte, werde ich den alten Treiber dauerhaft aktivieren müssen, denn der läuft ja soweit ganz gut.
Ich sehe ja ähnliches Verhalten am VDSL 100 Vectoring mit 1.100.133.42 VDSL Treiber. Entweder die Box läuft gut an mit mäßig vielen CRC Fehlern oder schlecht mit extrem vielen CRC Errors bis zum automatischen Resync. Also da es mit Treiber 1.100.133 41 sogar tagelang keine CRC Errors gibt und keine Resyncs bei identischer Leitungskapazität und identischen SNR Werten, scheidet eine Störung der Leitung aus. Mit Treiber 1.100.133.41 war die Fritzbox schon fast so gut wie ein SpeedPort V724 im Punkt VDSL Verhalten.
Ältere Labore und die 6.30 laufen aber problemlos, aber mit Syncs teilweise deutlich unter 100 Mbit, der Speedport V724 schafft aber immer Vollsync 109.3 Mbit.
Ältere Labore und die 6.30 laufen aber problemlos, aber mit Syncs teilweise deutlich unter 100 Mbit, der Speedport V724 schafft aber immer Vollsync 109.3 Mbit.
Zuletzt bearbeitet:
bastiks1988
Mitglied
- Mitglied seit
- 24 Jan 2011
- Beiträge
- 343
- Punkte für Reaktionen
- 45
- Punkte
- 28
Hi, ich hab mit keiner Labor probleme ( Zum Glück )
Ich betreue mehrere Fritzboxen 7490 und da gibt es keine Probleme.
ADSL2+ 16000 Annex J an Infineon
ADSL2+ 8000 Annex J an Infineon
ADSL2+ 16000 Annex B an Broadcom
VDSL2 50000 Annex B an Infineon
VDSL2 25000 Annex B an Infineon
Sry weis gerade die DSLAM versionen nicht aber bei den Anschlüssen läuft alles mit 0 Fehlern und Fullsync.
Ich betreue mehrere Fritzboxen 7490 und da gibt es keine Probleme.
ADSL2+ 16000 Annex J an Infineon
ADSL2+ 8000 Annex J an Infineon
ADSL2+ 16000 Annex B an Broadcom
VDSL2 50000 Annex B an Infineon
VDSL2 25000 Annex B an Infineon
Sry weis gerade die DSLAM versionen nicht aber bei den Anschlüssen läuft alles mit 0 Fehlern und Fullsync.
Bei den meisten Nutzern scheint es ja gut zu funktionieren, sonst würden sich hier noch viel mehr Leute melden. Mich interessieren besonders die Fälle, wo andere Modems (Speedport, Easybox) perfekt funktionieren, die 7490 jedoch nicht. Und natürlich die Fälle, wo man explizit sagen kann, dass ältere Treiberversionen viel besser funktionieren.
Andere Anschlusskabel zur TAE habe ich natürlich auch schon probiert; ebenso habe ich die FRITZ!Box direkt am APL im Keller angeklemmt - also komplett ohne Dose.
Ein Doppeldrossel-Kabel von eBay habe ich ebenfalls schon probiert, welches aber wegen höherer Dämpfungswerte alles nur verschlimmerte (musste ich folglich zurückschicken).
Wenn - wie in meinem Fall - der Speedport der Telekom einwandfrei am Anschluss funktioniert, kann man natürlich schlecht einen Techniker der Telekom einbestellen
Andere Anschlusskabel zur TAE habe ich natürlich auch schon probiert; ebenso habe ich die FRITZ!Box direkt am APL im Keller angeklemmt - also komplett ohne Dose.
Ein Doppeldrossel-Kabel von eBay habe ich ebenfalls schon probiert, welches aber wegen höherer Dämpfungswerte alles nur verschlimmerte (musste ich folglich zurückschicken).
Wenn - wie in meinem Fall - der Speedport der Telekom einwandfrei am Anschluss funktioniert, kann man natürlich schlecht einen Techniker der Telekom einbestellen
Neueste Beiträge
-
-
Fritz!DECT 302 regelt nicht mehr
- Letzte: Base
-
[Sammlung] FRITZ!Smart Gateway - Labor/Inhaus 7.90 (Zyklus 'Smart24P1')- Letzte: Ralf-Fritz
-
[Sammlung] FRITZ!Smart Thermo 302 - Firmware 0.22 - 5.xx- Letzte: Jstessi
-
[Frage] Deutsche Giganetz und 5590 Fiber- Letzte: nschill
-
[Frage] Layer 2 Traffic übers VPN leiten?- Letzte: PeterPawn
