FRITZ!Box 7270 Labor-Firmware xx.05.29-24296 vom 19.12.2012

Status
Für weitere Antworten geschlossen.
Rukernel Tool fragt nach Passwort, obwohl ich in der Anmeldseite User und Passwort für weoberfläche eingegeben hatte, kommt diese Fehlermedung bei z.B. in Tools den Warnhinweis zu entfernen. Telnet log in geht aber.
Hat man ggf. einen neuen user für RuKernelTool-Zugriff im "Hintergrund" in der Firmware eingerichtet?
 
Das wird wohl eher die gleiche neue Zugriffsmethode sein, die auch die Benutzung von Fritzbox-Monitor, jFritz etc. verhindert.
 
@07000fernweh

ruKernelTool funktioniert mit der "Nur Passwort"-Anmeldung

@KunterBunter

Nein, daran liegts nicht. Die anderen Programme gewinnen ihre Infos durch die Weboberfläche. ruKernelTool nicht.
 
Das ist korrekt. Aber wenn die Anmeldung mit FRITZ!Box-Benutzernamen und Kennwort in der Fritzbox eingerichtet wurde, funktionieren die Tools im ruKernelTool nicht. Nach der Passwortabfrage kommt dann eine Fehlermeldung: "TCP-Receive-Fehler. Vermutlich wurde die Verbindung aufgrund eines falschen Passworts geschlossen!"
Die Fritzbox muss also für die Tools im Experten-Modus des ruKernelTools auf die "Nur Passwort"-Anmeldung umgestellt werden.
 
Folgende Konfiguration: 7390 als Basis und 7270 v3 als DECT- und WLAN-Repeater. Telefon: MT-F.

Gestern erst wieder ein längeres Gespräch geführt und vier Gesprächsabbrüche gehabt. Wobei der Vierte kein Abbruch war, die Stimme meines Gesprächspartner war plötzlich (vermeintlich nach einem Handover) völlig zerhackt (komplett unverständlich) und in unerträglicher Lautstärke. Jeweils nach dem Auflegen klappt alles wieder bis zum nächsten Abbruch.
Ein weiteres DECT-Telefon das per Basis und Kabel an der 7390 hängt, hat keine Probleme - Telefonanschluss also als Fehlerquelle ausgeschlossen.
Habe den Fehler bereits zur letzten Labor-Version der 7270 an AVM gemeldet, und wollte das gerade wieder tun, leider finde ich kein Feedbackformular zu dieser Version. Wobei der Fehler natürlich auch am DECT-Treiber der 7390 liegen könnte.
Hat jemand eine ähnliche Konfiguration und ähnliche Probleme?
 
Zuletzt bearbeitet:
Sorry - wer lesen kann ist glatt im Vorteil. Im Changelog steht tatsächlich nur WLAN. Meine Probleme beziehen sich aber auf DECT.
 
@ Porztanker

Du bringst es auf den Punkt. Genau das Gleiche Problem liegt auch bei mir vor.
 
Die neue Repeaterfunktion geht sehr viel schlechter als mit WDS

Habe gerade mal zwei Boxen (7270v2 und v3) auf die neue Repeaterfunktion umgestellt. Leider funktioniert es überhaupt nicht :mad: . Im WDS-Betrieb hatte ich auf beiden Boxen noch 3 bzw. 4 Balken Verbindungsqualität. Mit der neuen Firmware findet die Repeaterbox zwar noch die Basis, allerdings nur mit (k)einem Balken. Und sie verbinden sich nicht, auch nicht nach mehreren Neustarts (Strom weg) beider Boxen. Mit WDS habe ich wenigstens 36MBit Verbindungsqualität, was ich mit der neuen Funktion zu verbessern versuchte, leider ohne Erfolg. Hoffen wir mal auf die nächste Beta :cool: . Bis dahin kann ich von der Verwendung als WDS-Ersatz nur abraten.
 
Wurden in den letzten Versionen auch Änderungen an der Priorisierung vorgenommen? Sitze seit Monaten auf dem Problem des nicht funktionierenden TrafficShapings fest ;-)
 
Damit habe ich überhaupt keine Probleme. Hast Du einen besonders langsamen Anschluß oder eine besonders alte Konfiguration über mehrere Updates mitgeschleppt? Ich habe mir angewöhnt bei jedem größeren Versionssprung alles von Hand (mit Hilfe von Screenshots) neu zu konfigurieren und seitdem blieb ich von größeren Problemen verschont.
 
Wurden in den letzten Versionen auch Änderungen an der Priorisierung vorgenommen? Sitze seit Monaten auf dem Problem des nicht funktionierenden TrafficShapings fest ;-)

Mit der alten Konfiguration bricht der Download bei gemeinsamen Upload zusammen. Mit der aktuellen Beta und den wiederhergestellten Werkseinstellungen funktioniert das TrafficShaping ohne jegliches zutun an den Prioritäten -> TOP. Das Resultat ist flüssigeres Surfen - vor allem laden nun 720p und teilweise 1080p mit 6000 kBit-Sync sehr viel öfter flüssig als mit der alten FW.

Ich werde im laufe der Tage die Priorisierung noch testen und gebe wieder bescheid :cool:

@erik: Genau das kann die Probleme bei vielen Usern verursachen - wie auch bei mir. Es ist auf jeden Fall empfehlenswert die Werkseinstellungen der aktuellen Firmware wiederherzustellen.

----

Hinzugefügte Anwendungen unter der Priorisierung verändern das Verhalten des TrafficShapings nun nicht mehr.
 
Zuletzt bearbeitet:
Wenn ich die Box neu starte oder wenn eines meiner MT-F mal die Basis verliert, kommt es neuerdings relativ häufig vor, dass eines der MT-Fs wild mit der roten Nachrichten-LED blinkt und dann dauerleuchtet.
Meist genügt ein Drücken der Nachrichtentaste, zweimal musste ich aber auch schon das MT-F neu starten. Kennt das jemand?
Das kann natürlich genauso gut an der MT-F-FW liegen und gar nichts mit der Labor zu tun haben ...
 
AVM hat mehrere RSS-Feeds voreingestellt, die dann erneut abgerufen werden. Deshalb leuchtet die Nachrichten-Lampe
 
@MauriceHOL: Danke für den Tipp - dachte auch erst, vielleicht "feature - not bug" - allerdings: Bei den RSS-Feeds-Einstellungen hab ich "Neue RSS-Nachrichten ... automatisch signalisieren" gar nicht aktiviert :confused: - und wenn, dann leuchtet ja auch nur EIN MT-F

So - durch deinen Tipp doch noch ein unnötiges Häkchen entdeckt: Unter den Podcasts war bei einem Eintrag das automatische Signalisieren an - denke das wars!
 
Zuletzt bearbeitet:
Habe in dieser Labor keinen Zugriff auf den 1&1 Onlinespeicher über UPNP, der hier (erstmalig?!) über UPNP seine Inhalte als extra Mediaserver im Netzwerk sichtbar ist und seine Inhalte darbietet/ darbieten soll...
 
Weiterhin besteht das Problem, dass sporadisch das DECT-ECO-Aufwecksignal nicht rechtzeitig ankommt. Man sieht dann nur am MT-F ein rotes Blinken, dass man einen Anruf verpasst hat. Angerufen wurde von Internet über 1&1 zu mir 1&1 Internet.
 
Selbiges Problem beobachtete ich mit der letzten Finalfirmware und einem Gigaset A400 als Mobilteil. Hab ECO einfach abgeschaltet und alles war gut, denn ich schob das Problem auf das Fremdgerät. Wenn natürlich auch ein AVM-Mobilteil dieses Problem hat, sollte AVM was tun.
 
so eben, den zweiten anruf so in folge verpasst. war gleiche konstellation (1u1 zu 1u1)...
 
Mal wieder neue Erkenntnisse. Jedes mal wenn die Nachtschaltung das WLAN an- und ausschaltet, gibts Probleme mit dem internen SIP-Registrar. Ungefähr im Durchschnitt eine halbe Stunde lang steht im Log "Anmeldung [...] nicht erfolgreich. Gegenstelle meldet Ursache 404".

Desweiteren kann man den DHCP-Server mittlerweile total in die Tonne treten. Wenn man schon vorher Geräte einträgt mit gewünschter IP macht die FRITZ!Box beim Anmelden des Geräts zwei Geräte draus. Einmal so wie man es eingetragen hat. Danach wird auch die IP an den Client vergeben. Nun steht aber eine weitere aktive Verbindung mit gleicher MAC in der Liste und der nächstmöglich freien IP. Selbst per telnet in der config alles zurecht biegen mit anschließendem reboot hilft nicht. Ich versuch momentan einen 30-Minuten-POR. Mal sehen wie es nachher aussieht.
 
Status
Für weitere Antworten geschlossen.

Zurzeit aktive Besucher

Keine Mitglieder online.

Statistik des Forums

Themen
244,868
Beiträge
2,219,771
Mitglieder
371,585
Neuestes Mitglied
PauSchmitz
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.