Fritzbox 7490 Firmware Version 6.20 (vom 12.08.2014)

[HabNeFritzbox]

Nicht vergessen die Sachen im Kummerkasten zu werfen.

IP Telefonfreigaben mit sehr einfachem Passwort oder keinem sollte normal nicht möglich sein, da muss AVM schon eher Zahlen+Buchstaben bei min 7 Zeichen fordern, und sonst nur Freigabe aus dem Heimnetz.

Die Logs sollten auch erfolgen, beim WLAN wird ja auch wie bekloppt geloggt mit An- und Abmeldung, keine Reaktion ect. mit Fehler #0300 und #0302 ect.

 

[informerex]

und wenn man gerade dabei ist, evtl. Passwort vom System vorschlagen - bei VPN ist es ja auch möglich.
somit schreibt niemand "meinpasswortistsicher" rein

 

[eisbaerin]

Der Fehler mit der falschen "load average" Anzeige besteht auch noch:
http://www.ip-phone-forum.de/showthread.php?t=264459

Tritt nur bei der FB7490 auf.
Ich weiß nicht ob das an der Hardware oder an der Software liegt.

 

[AndreasD]

Hallo,

ich habe mir mal den Test erlaubt ein externes Modem vor der FritzBox 7490 mit der Firmware 6.20 anzuschließen. Das Modem war das ALLNET ALL0333CJ Rev.C - DSL-Modem. Anschluss war spielend einfach, es musste nur in der FritzBox auf externes Modem umgestellt werden, der Rest ging von alleine.
Da man nicht auf das Modem zugreifen kann wenn alles angeschlossen ist, habe ich indirekt versucht über ein Speedtest die Geschwindigkeiten zu vergleichen. Möglichst zu einem Zeitpunkt an dem bei uns auf dem Netz nicht viel los ist. Das Ergebnis ist überraschend, die Verbindung der FritzBox war schneller und ergab mehr Download Geschwindigkeit. Also scheint das DSL Modem der FritzBox doch ganz in Ordnung zu sein. Natürlich lässt sich das nicht auf alle Gegebenheiten übertragen. Bei meinen Anschluss lohnt sich ein externes Modem nicht.

Gruß

Andreas

 

[qwertz.asdfgh]

Hoffentlich habe ich die Recover noch.

Und wenn nicht lädst du sie dir eben direkt bei AVM herunter:
ftp://ftp.avm.de/fritz.box/fritzbox.7490/x_misc/deutsch/

 

[ta99]

VDSL 50 IP Anschluss bei der Telekom:

Eine VoIP Rufnummer der Telekom ist in der FB registriert und darüber wurden mehrere Gespräche geführt. Trotzdem gibt es dazu in den Systemmeldungen nicht einen einzigen Eintrag, nicht mal für die Registrierung der Nummer.

Bei den DSL-Infos unter Internet -> DSL-Informationen -> DSL scheint der Wert für die Leitungsdämpfung in Senderichtung falsch zu sein: im Vergleich zur 6.05 ist er deutlich gestiegen und auf mehreren Screenshots die ich gesehen habe, ist bei der 6.20 der Wert immer identisch zum Wert der Empfangsrichtung. Sieht so aus, wie wenn der Wert der Empfangsrichtung in beiden Spalten angezeigt wird.

 

[Versaboy]

Also bei mir schaut es an einem VDSL 50 der Telekom mit ISDN so aus:
Gegenstelle ist Infineon 10.8.6.5

Anhang anzeigen 77294

 

[Kaffeejunkie]

bei mir sind auch beide Werte identisch.

 

[Scaraflipper]

Beide Werte bei Leitungsdämpfung identisch kann ich bestätigen. Ich hatte vorher 5/1, jetzt steht da 5/5.

 

[kwirk]

kann ich nicht bestätigen. Bei mir sind die Werte unterschiedlich...

 

[ta99]

Es sieht so aus, wie wenn der Fehler nur dann auftritt, wenn der Wert bei der Senderichtung bisher niedriger war.

Bei Versaboy und kwirk ist der Wert in Senderichtung größer als der in Empfangsrichtung.

 

[Hans Juergen]

Eine VoIP Rufnummer der Telekom ist in der FB registriert und darüber wurden mehrere Gespräche geführt. Trotzdem gibt es dazu in den Systemmeldungen nicht einen einzigen Eintrag, nicht mal für die Registrierung der Nummer.

Erfolgreiche Gespräche werden in den Systemmeldungen nie aufgeführt, sondern nur unter Telefonie>Anrufe und Telefonie> Eigene Rufnummern>Reiter Sprachübertragung

Es sieht so aus, wie wenn der Fehler nur dann auftritt, wenn der Wert bei der Senderichtung bisher niedriger war.

Nöö, ich habe 12 dB in Empfangs- und 11 dB in Senderichtung.

 

[japes]

War bei mir auch noch nie gleich imho...nachwievor nicht

 

[ta99]

Dann kann es eigentlich nur noch vom DSLAM/MSAN Typ abhängen, oder?

Bei mir: Infineon 9.10.6.2

 

[Kaffeejunkie]

bei mir: Infineon 10.8.5.8

und da drunter steht noch: B5004946544EA458 00 35353032

Was auch immer das zu bedeuten hat.

 

[PeterPawn]

99 Verbesserungen

Eine der Verbesserungen "unter der Haube", die man seitens AVM ruhig deutlicher und mit mehr Brimborium hätte herausstellen können, findet sich bei den VPN-Verbindungen.

Endlich werden nicht mehr beim (De-)Aktivieren einer VPN-Verbindung alle anderen derzeit aktiven (aufgebauten) Verbindungen erst einmal getrennt. Das alleine lohnt in einigen Anwendungsszenarien das Update auf die 06.20. :rock:

 

[dancedoc]

Ich habe heute morgen auch das Update auf die 06.20 gemacht.

Ich habe mir dafür ein neues Freetz-Image gebaut und dabei u.a. die Dateien allcfgconv, usbcfgconv und wlancfgconv aus der 06.05 genommen und per own-files-addon in die Firmware eingebaut. Damit kann man z.B. wieder mit dem ruKernelTool die Passwörter im Klartext auslesen.

Positiv ist mir aufgefallen, dass jetzt auch der ausgewählte 5 GHz-Kanal verwendet wird. Bei der 06.05 hatte ich das Problem, dass obwohl Kanal 44 ausgewählt war der Kanal 52 (oder war es 48?) genutzt wurde, was zur Folge hatte, dass die Radarerkennung ansprang.

Mein VDSL-Sync ist erst mal um ca. 5 Mbit/s gefallen, aber wenn ich jetzt als DownstreamMarginOffset -9 wähle (vorher -10) komme ich wieder auf den gleichen Sync wie in der 06.05. Bei Gelegenheit werde ich noch mal mehr DownstreamMarginOffset-Werte testen.

Bei mir funktioniert in der 06.20 mit ctlmgr_ctl das Auslesen der Statusparameter im Modul sar nicht mehr. Ich kann mir also nicht mehr per "ctlmgr_ctl r sar status/dsl_ds_rate" den aktuellen Downstream-Sync anzeigen lassen (und z.B. in eine Logdatei speichern). In anderen Modulen scheint es aber noch zu funktionieren (z.B. "ctlmgr_ctl r power status/act_temperature"). Kann jemand das Problem bestätigen? Hat jemand Lösungsvorschläge?

Positiv finde ich auch, dass im Webinterface bei den DSL-Informationen bei einem Synchronisationsverlust die Werte vom letzten Sync angezeigt werden (mit entsprechender Überschrift) bis ein neuer Sync ausgehandelt wird. So hat man bei Leitungsproblemen eine größere Chance sich die Leitungswerte anzugucken (wenn z.B. der Sync nach wenigen Sekunden wieder abbricht).

edit: mir ist gerade noch aufgefallen, dass die Internettelefonie-LED blinkt. Im Ereignis-Log tauchen auch Meldungen auf, dass die Internetrufnummern nicht registriert werden konnten (Gegenstelle antwortet nicht. Zeitüberschreitung), die jetzt aber schon etwas länger her sind. Auf der Übersichtsseite und bei Eigene Rufnummern werden aber alle Rufnummern als markiert angegeben. Bisher war mir noch nie aufgefallen, dass die Internettelefonie-LED blinken kann.
Anrufe funktionieren übrigens. Während des Anrufs leuchtet die Internettelefonie-LED dauerhaft, nach Rufende blinkt sie dann wieder.
Einen Reboot habe ich noch nicht probiert, da ich gerade keinen Disconnect möchte.

 

[PeterPawn]

Hat jemand Lösungsvorschläge?

ctlmgr_ctl r dslstatglobal status/in => Downstream 
ctlmgr_ctl r dslstatglobal status/out => Upstream

beides in Bit/s und nur die Effektiv-Werte, nicht die Leitungskapazität.

nach Rufende blinkt sie dann wieder.

MWI vom Anbieter ?

 

[full2000]

Ich weiss nicht, ob das erlaubt ist, aber ich habe jetzt von der originalen 6.20 eine eigene Firmware erstellt, bei der die debug.cfg wieder aufgerufen werden sollte (für die 7490). Hat einer Lust/Zeit, die Firmware zu testen?!

 

[dancedoc]

Danke für den Tipp mit MWI. In der voip.cfg mwi_supported auf no gestellt, Box rebootet und das Blinken ist weg. Das MWI in dieser Firmware ein Problem sein kann, wurde ja schon mal geschrieben, aber ich hatte da bisher nur an DECT-Telefone gedacht und nicht an die Internettelefonie-LED.

Im Modul dslstatglobal gibt es aber nicht so viele Möglichkeiten wie im Modul sar. Ich habe nämlich auch die SNR-Werte gespeichert um später ggf. Veränderungen im Spektrum nachvollziehen zu können. Irgendwie müssen diese Parameter jetzt ja per ctlmgr_ctl abrufbar sein.

edit: eine Sache ist mir noch aufgefallen. Bei mir ist die Upstream-Leitungsdämpfung von 5dB auf 21dB angestiegen (21dB ist auch die Upstream-Störabstandsmarge).