FRITZ!Box 7490 07.19 Labor Serie

Micha0815

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
3,891
Punkte für Reaktionen
213
Punkte
63
und Du nicht davon ausgehst, das es Grundlage zur Steuerung einer sich am fernen Horizont vielleicht mal abzeichnenden Hardware ist, die man von der Fritte ansteuern kann, um Rolladen zu bedienen?
Korrekt und meine persönliche, umassgebliche Einschätzung. Betrachtet man die aktuell unterstützten Teile (neuer Schalter-DECT440, LED-Bulb-DECT500, opt. Schalter, Rauchmelder) die offiziell angekündigt und/oder als Telekomvariante schon am Markt, fiele mir nur noch der ominöse/mutmassliche Bewässerungscomputer (DECT600?) ein, was auf ein wirklich neues Gerät hindeuten könnte. Andererseits tut sich lt. Letzter FW vom Oktober auch nix mehr "sichtbar", da wohl einschlägige Tests nur in den Sommermonaten Sinn ergäben.
Generell wäre AVM imo gut beraten, sich besser auf FW/Implementierung zu konzentrieren, als sich an "mechanischen Gerätschaften" in Eigenentwicklung zu versuchen, wo andere namhafte Hersteller bzgl. KnowHow+Qualität mehr Erfahrung haben. -Ich denke da an die DECT300, die im Gegensatz zu den Cometen nicht so der Bringer waren-
Dem folgend würde ich persönlich da auf "Gardena" als Bewässerungscomputer-OEM tippen. Bei Rolläden wäre "Schellenberg" sicherlich auch eine gute Adresse?
Allerdings sollte man imho bedenken, dass das Vorhandensein von Rolläden (gefühlt) regional sehr unterschiedlich ist/sein könnte? Z.B. habe ich in vielen Mietshäusern in Wuppertal selten Rolläden entdeckt (während meiner Studienzeit) ...-machmal im Paterre-... im Gegensatz zum "Ländle" (meiner Heimat).
LG and my2cent
P.S. : Unabhängig davon, tut sich AVM mit dem Zeitraum Ankündigung<->Auslieferung imho stets schwer, wenn man die Historie betrachtet :D
 
  • Like
Reaktionen: DiedrichsHW und VAZ

gerold

Neuer User
Mitglied seit
24 Dez 2006
Beiträge
10
Punkte für Reaktionen
5
Punkte
3
Wenn man sich auf der FB die Datei home_auto_edit_view.lua ansieht, findet man u.A. den Aufruf von Funktionen wie setBlindOpenCloseStop, setBlindMotorDirection, setBlindEndposition und setBlindReset, was für mich auf eine Implementierung einer Steuerung von Rollladenaktoren über die FB hinweist. Mir sind aber bis jetzt keine Rollladenaktoren bekannt, die über DECT_ULE angesteuert werden können.
 
  • Like
Reaktionen: VAZ

Micha0815

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
3,891
Punkte für Reaktionen
213
Punkte
63
was für mich auf eine Implementierung einer Steuerung von Rollladenaktoren über die FB hinweist
Ich würde das eher den Cometen bzw. DECT300/301 und deren verbauten Stellmotoren zuordnen wollen, da diese imho neue Funktionen bekommen haben bzgl. Schnell-Schliessen via Fritz!App etc. Aber so wirklich blindlings mag ich nicht spekulieren ... da gibt es sicherlich kompetentere Leutz hier im Forum, die einen geschulten "Blick unter die Haube" werfen könnten.
LG
 
  • Like
Reaktionen: VAZ

gerold

Neuer User
Mitglied seit
24 Dez 2006
Beiträge
10
Punkte für Reaktionen
5
Punkte
3
Es wird in dem Coding ein unittype 281 abgefragt, im Kommentar dazu findet man " -- 281 ist Rollo".
 
  • Like
Reaktionen: VAZ

Micha0815

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
3,891
Punkte für Reaktionen
213
Punkte
63
Danke für den Hinweis ... persönlich würde es mich freuen, wenn sich da etwas abzeichnet am Horizont ;) Vielleicht kann @Ohrenschmalz als "Werksspion" nach Erlkönigen Ausschau halten :D
DUW + LG
P.S.: Mein Schellenberg "Rolodrive 60 Comfort" (für einen schweren Balkonpanzer) und ein popeliger ALDI-GLC-NoName, dessen Fenstersensor ich entfernen musste, da er herumsponn (der war recht laut und am Limit mit dem schweren Balkonpanzer) gieren fast nach was "drahtlosem".
 

Xantorix

Mitglied
Mitglied seit
19 Mrz 2009
Beiträge
365
Punkte für Reaktionen
2
Punkte
18
Hallo, habe gerade mal die Labor zum Testen installiert.
Scheinbar tut sich doch was mit VPN.
Meine internen Telefonate über 2 Standorte sind jetzt sauberer geworden.
Noch nicht ganz. Aber man kann HD schon mal testweise aktivieren.

Gruß Xante
 

japes

Mitglied
Mitglied seit
17 Mai 2010
Beiträge
201
Punkte für Reaktionen
11
Punkte
18
Hab jetzt auch 5 Wochen Homeoffice hinter mir. Anfangs größere Probleme mit VPN Verbindung (Cisco Client), wenn DNS over TLS aktiviert war. Die ganze letzte Woche hatte ich es wieder aktiv ohne Probleme. Als DNS Server (verschlüsselt und unverschlüsselt, IPv4 und IPv6) kommen bei mir Quad9 und Cloudflare zum Einsatz.Allerdings hatte unsere IT auch das VPN Profil zur besseren Skalierung im Unternehmen zwischenzeitlich geändert. Was nun genau zum störungsfreien Betrieb beigetragen hat...who knows.
Des Weiteren gab es in der Labor immer mal wieder "Hänger" bei aktiviertem WPA3, sodass ich es genervt ausgeschaltet hatte. Kann allerdings auch nur mit Apple Geräten testen (MacBook Pro 2015 und iPhone X), welche WPA3 unterstützen. Hab es mit der aktuellen Labor 77201 wieder aktiviert und beobachte.
 
Zuletzt bearbeitet:

Ohrenschmalz

Aktives Mitglied
Mitglied seit
19 Apr 2006
Beiträge
801
Punkte für Reaktionen
27
Punkte
28
  • Like
Reaktionen: Micha0815

Robert T-Online

Mitglied
Mitglied seit
9 Apr 2016
Beiträge
720
Punkte für Reaktionen
349
Punkte
63
FRITZ.Box_7490-07.19-77568-LabBETA.image kündigt sich an.
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,806
Punkte für Reaktionen
341
Punkte
83
Weitere Verbesserungen im FRITZ!OS 7.19-77568/77553/77569 (innerhalb FRITZ!Labor)

Internet:
Verbesserung Anzeige gesperrter Netzwerkgeräte auch auf der Startseite
Verbesserung Fehlerbehandlung bei aktiver Gerätesperre überarbeitet
Verbesserung Stabilitätsverbesserung bei VPN-Verbindungen
Behoben Unvollständige Fehlerbehandlung für die Gerätesperre
Behoben Fehlerbehandlung für die Gerätesperre war unvollständig
Behoben An DS-Lite-Anschlüssen wurde die IPv4-Heimnetz-Adresse der FRITZ!Box im Online-Monitor als externe IPv4-Adresse angezeigt
Behoben Bei Einschränkung der Geräte für eine VPN-Verbindung konnte nur das erste Gerät diese VPN-Verbindung nutzen
Behoben Kindersicherung verhinderte den Zugriff auf Netzwerkgeräte über VPN
Behoben Fehlerhafte Darstellung von Downloads im "Online-Monitor"

WLAN:
Behoben Verbindungsverlust nach einem unterbrochenen Kanalwechsel
Behoben Meldungen zu Radar unter "System / Ereignisse / WLAN" vervollständigt
Behoben Bei der Anmeldung von WLAN-Geräten per Taste "Connect/WPS" konnten Probleme auftreten

Mesh:
Verbesserung Berücksichtigung der Kanalbandbreite bei Entscheidungen zum Mesh Steering
Verbesserung Mesh-Steering zwischen Zugangspunkten mit fester und solchen mit gemischter WPA-Verschlüsselung ermöglicht

Telefonie:
Behoben Diverse Fehlerbehebungen für CardDAV- und iCloud-Telefonbücher
Behoben Anrufbeantworternachrichten waren nicht über Benutzeroberfläche abspielbar

Heimnetz:
Behoben Zugangsprofil der Kindersicherung in den Gerätedetails war nicht mehr änderbar

USB:
Verbesserung Bei großen Dateien brach der Transfer nach unbestimmter Zeit ab

System:
Behoben Leere Seite bei mehrfacher Ausführung von "Diagnose / Sicherheit"
Behoben Wiederkehrende Neustarts im Zusammenhang mit einer speziellen Einstellung für den Faxempfang
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,806
Punkte für Reaktionen
341
Punkte
83

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
12,397
Punkte für Reaktionen
311
Punkte
83
Logisch, wie bei der doppelten Verneinung.
Also eine: Wiederschlechtmachung
 

DickS

Aktives Mitglied
Mitglied seit
22 Feb 2005
Beiträge
2,187
Punkte für Reaktionen
91
Punkte
48
Hatte ich bisher nicht so niedrig, seit dieser Labor scheint es nicht mehr auf 51% zu hängen wie bei vorherige Labors und Inhaus.

Snap8.png

UPDATE: sobald ich über DECT ein Telefonat gemacht habe, steht es wieder bei 50% und geht nicht mehr zurück auf 37%......
 
Zuletzt bearbeitet:

japes

Mitglied
Mitglied seit
17 Mai 2010
Beiträge
201
Punkte für Reaktionen
11
Punkte
18
Bei mir sind's immer noch 51% (VDSL, WLAN, Telefonie, VPN, DNSoTLS, DynDNS, Switch)
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Den irgendwo bei den Inhouse-Versionen bereits bemerkten Wechsel vom "ext2"-Image mit 256-Byte-Pseudoheader, der das als SquashFS-Image tarnt, hin zu einem "echten" SquashFS4-Image, hat AVM jetzt mit der 77568 auch in den offiziellen Labor-Versionen vollzogen.

Damit ist ein direktes Update von einer Version < 06.50 (bzw. der dieser vorausgehenden Labor-Reihe, das müßte die 06.35 gewesen sein) auf die aktuelle Labor-Reihe nicht mehr möglich, weil das vorherige System das Format der enthaltenen "filesystem.image" nicht verarbeiten kann.

Auch für diejenigen, die ihrerseits diese Firmware-Images mit eigenen Skript-Dateien "auseinandernehmen", gilt es jetzt u.U., die eigenen Dateien anzupassen. Dabei reicht es i.d.R. allerdings nicht aus, das "losetup" und ein nachfolgendes "mount" nur abzuändern (solange man das nicht gerade unter einem der AVM-Kernel mit BE-SquashFS4 macht) ... das "native" SquashFS4-Format anderer Linux-Distributionen weicht von dem von AVM verwendeten ab und die "filesystem.image" aus einem AVM-Firmware-File (für Modelle, die "big endian"-Formate bei der internen Darstellung verwenden) läßt sich i.d.R. nicht auf anderen Systemen mounten, sondern muß mit dem passenden "unsquashfs"-Tool (das Freetz-Projekt enthält z.B. die notwendigen Patches) entpackt werden.

AVM selbst stellt KEINE Tools (und auch keine Patches für die Quellen aus dem "squashfs-tools"-Projekt) bereit. Letztlich ist der Aufbau der Firmware-Images jetzt wieder derselbe, wie vor der Release-Version 06.50 - nur mit einem neueren SquashFS4-Format, welches von AVM so abgeändert wurde, daß es inkompatibel mit dem "üblicherweise" von den genutzten Kernel-Versionen unterstützten Format ist ... m.W. eine Änderung, die so nur bei AVM zu finden ist.

Meß- und reproduzierbare Performance-Zuwächse durch dieses eigene Format habe ich jedenfalls nicht wirklich feststellen können (auf VR9 mit 3.10.107 gemessen, einmal mit einem Kernel mit AVM-Patches in "fs/squashfs" und einmal ohne) ... alles das, was da an Unterschieden zutage tritt, schrammt knapp an der Grenze eines Meßfehlers vorbei.

Aber damit führt AVM jetzt die VR9- und die GRX-Modelle wieder etwas weiter zusammen, auch wenn weiterhin das eigentliche Root-Dateisystem bei den VR9-Modellen in einem zusätzlichen "Container" steckt, der jetzt halt ebenfalls das SquashFS4-Format verwendet.

Vielleicht schafft es AVM ja in der Zukunft tatsächlich auch noch, die Quellen nicht nur als "fertige Dateien" bereitzustellen, wo man sich die Änderungen halt irgendwie selbst zusammensuchen muß oder zumindest die von AVM-Mitarbeitern vorgenommenen Änderungen vernünftig zu kennzeichnen, denn die Bestimmungen der GPLv2 sehen in Punkt 2a ja durchaus auch vor, daß man ebendieses tut:
You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
Von solchen Vermerken ist - zumindest unterhalb von "fs/squashfs" - nichts, aber auch gar nichts, zu finden und das zieht sich auch bis zu den Anpassungen für den Kernel 4.9.198, der derzeit bei der 7590 zum Einsatz kommt.

Daraus folgt wiederum, daß es sich auch bei der Tatsache, daß man bei AVM quasi zum "Blindflug" gezwungen wird, was die Änderungen der Quellen gegenüber dem Vanilla-Kernel oder auch gegenüber den Patches durch den Chip-Lieferanten (bei VR9 noch "Lantiq") angeht, eigentlich um einen weiteren Verstoß gegen die Lizenzbestimmungen, unter denen AVM selbst die Nutzungsrechte am Linux-Kernel erhält, handelt.
 

schnurgly

Mitglied
Mitglied seit
17 Jun 2014
Beiträge
349
Punkte für Reaktionen
12
Punkte
18
Wäre ein Downgrade zu Version < 6.50 noch möglich?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Das geht doch über ein installiertes und laufendes FRITZ!OS nicht mal bis zu einer anderen Version auf dem (Rück-)Weg zur 06.50 - also nein.

Und AVM wird bei der Installation eines Downgrades über das GUI (die Frage, ob es geht und zu welcher Version, regelt AVM über den JUIS) kaum auf die Idee kommen, ein Downgrade auf eine Version < 06.50 zuzulassen - wenn doch, hätte diese dasselbe Problem ... das laufende FRITZ!OS (jenseits 06.50) kann mit dem Format einer "filesystem.image" aus den früheren Versionen nichts anfangen - da müßte AVM dann eine "Spezialversion" erstellen, die SquashFS4-Format für den Container verwendet und darin dann eine "filesystem_core.squashfs", die ihrerseits SquashFS3 nutzt (wie die alten FRITZ!OS-Versionen), enthält.

Der Weg über das Recovery-Programm (bzw. den Bootloader, wenn man ihn zu Fuß gehen wollte) bleibt davon natürlich unberührt ... dabei spielt das aktuell installierte System keine Rolle (ja, es wird nicht einmal geprüft) und der Speicher-/Schreibvorgang erfolgt "ohne Ansehen der Person".
 

DickS

Aktives Mitglied
Mitglied seit
22 Feb 2005
Beiträge
2,187
Punkte für Reaktionen
91
Punkte
48
AVM hat wohl gesehen, dass es kaum noch aktive Boxen mit 6.50 am Netz gibt......
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Wenn sie das auf der Basis von "Diagnose und Wartung" feststellen wollten, bräuchten sie eher eine Glaskugel - das ist erst seit 06.8x implementiert. Blieben also nur die Boxen, denen man (a) die Kommunikation mit dem Provider überhaupt erlaubt hat und die gleichzeitig (b) ständig nach Updates suchen.

Jede Box, die eine dieser Bedingungen reißt, ist für AVM "auf normalem Weg" nicht mehr zu sehen - es sei denn, sie hat gleichzeitig ein aktives MyFRITZ!-Konto. Aber die Schlußfolgerung, daß wenige oder gar keine Boxen mit älterer Firmware, die sich bei AVM melden, auch mit der Existenz weniger FRITZ!Boxen mit älterer Firmware an sich gleichzusetzen wäre, ist ja ohnehin nur eine Milchmädchen-Rechnung. Nur weil man etwas nicht kennt (oder zählen kann), heißt das ja noch nicht, daß es dieses "etwas" nicht gibt.

Wobei es immer noch genug Stellen gäbe, wo FRITZ!Boxen an AVM "petzen" (bzw. nicht nur an AVM) - das geht schon beim Abruf von RSS-Feeds los, wo man - geradezu eilfertig - dem befragten Server mitteilen möchte, welche FRITZ!OS-Version auf dem Gerät läuft und obendrein auch noch, welche Kernel-Version von dieser verwendet wird:
feeddaemon.PNG
Mir fällt jedenfalls kein offensichtlicher Grund ein, warum man das mit diesem Detailreichtum jedem Server mitteilen müßte, von dem man einen RSS-Feed abrufen will. Das Format eines solchen Feeds ist soo alt und so weit standardisiert, daß es überhaupt niemanden interessieren müßte, was da von demjenigen verwendet wird, der diesen Feed haben will.

Da (zumindest bisher, für die Labor-Reihe prüfe ich das jetzt nicht, weil man dazu die Box zurücksetzen müßte) auch der Feed von AVM.de standardmäßig aktiviert ist, braucht es nur noch ein passendes DECT-Gerät (zumindest früher hielt der "dect_manager" die Füße still, wenn kein FRITZ!Fon angemeldet war und schob den "feedd" dann nicht an) und AVM erhält auch auf diesem Wege (und das ist unabhängig von "Kommnunikation mit dem Hersteller zulassen") eine Information, wo sich welches FRITZ!OS tummelt.