FRITZ!Box 7490 07.19 Labor Serie

[stoney]

Ein "unsichtbares" Leerzeichen ?

 

[kleinkariert]

Aktuell funktioniert bei meinem NextCloud als Anzeigename / FN nur "Vorname Nachname" korrekt, bei "Nachname, Vorname" wird das Komma unschön intern in "\," umgewandelt (siehe VCF-Export/Import). Der schon immer wenig elegante Weg der Kommaschreibweise für die AVM-Telefonbuchsortierung nach Nachnamen muss wohl vorerst vermieden werden.

 

[PeterPawn]

Bisher m.W. auch einmalig (zumindest ist es mir noch nie aufgefallen): AVM wechselt mitten in einer Labor-Reihe noch einmal die Versionsnummer der verwendeten C-Library ... aus der bisher genutzten uClibc-ng 1.0.30 wird mit der 75160 (auch bei den Inhouse-Versionen) die 1.0.31.

Witzigerweise erfolgte dieser Wechsel (zumindest für die veröffentlichten Versionen - die Inhouse-Firmware lasse ich bei solchen Betrachtungen immer außen vor) jetzt genau 6 Tage (am 21.01.2020 ist die 75160 gebaut), nachdem das OpenSource-Paket für die 07.19 der 7490 von AVM am 15.01.2020 geschnürt wurde (nach den Dateidaten zu urteilen) und einen Tag, nachdem mich der AVM-Support per E-Mail über die Bereitstellung der 07.19-Quellen (auch für die 7490) benachrichtigt hatte.

Schaut man genauer auf die Versionen, wird die Update-Politik von AVM für die "verbauten Komponenten" aber immer rätselhafter ... die bisher verwendete 1.0.30 stammte aus dem April 2018 (https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/log/), die war bei AVM bis Mitte Dezember 2019 (mind. bis zur 74231 vom 12.12.2019) in Benutzung und danach aktualisiert man auf eine Nachfolge-Version - aber auch nicht etwa auf die neueste (die 1.0.32 gibt es seit dem 15.10.2019), sondern auf die auch wieder bereits ein Jahr ältere 1.0.31 (14.11.2018).

Nun mag es zwar tatsächlich keine für die VR9-Modelle relevanten Änderungen an der uClibc-ng in dem knappen Jahr gegeben haben, seitdem die 1.0.31 erschien (bis zur 1.0.32) ... aber wenn sich tatsächlich bei AVM jemand hinstellen und jeden Commit dahingehend untersuchen kann, ob der Auswirkungen auf das FRITZ!OS haben würde oder nicht, dann hat man dort wohl doch noch zu viele freie Kapazitäten - die meisten (auch die meisten Entwickler) würden hier wohl einfach die neueste Version nehmen, wenn es nicht irgendeinen (dann aber tatsächlich hieb- und stichfesten) Grund gibt, genau dieses nicht zu tun.

Es mag ja sein, daß die 1.0.30 irgendetwas nicht enthielt, was "musl" oder die "glibc" bereithalten und was daher mittlerweile von AVM in eigenen Programmen genutzt wird - das wäre ein Grund, die 1.0.30 auf die 1.0.31 zu hieven, wenn das dort dann ebenfalls enthalten ist.

Aber warum man dann nicht gleich auf die 1.0.32 geht, würde mich mal brennend interessieren ... so viel "Vorlauf", daß die 1.0.31 schon vor dem Erscheinen der 1.0.32 "getestet" wurde und man das jetzt nicht noch einmal machen wollte, dürfte es eigentlich auch nicht geben ... das wäre wieder eine (erschreckend bzw. sehr) lange Zeit, bis dann der Übergang zur 1.0.31 nach (mind.) 3 Monaten den Weg in die Labor-Reihe (und auch in die Inhouse-Versionen) gefunden hat.

Eigentlich müßte man jetzt gleich noch einmal hingehen und bei AVM das OpenSource-Paket für die 07.19 der 7490 ab der Revision 75160 anfordern (das auf osp.avm.de hat keine Revisionsnummer im Namen der Datei und auch kein "Labor", wie das früher mal der Fall war) ... ich frage mich tatsächlich, ob das Absicht oder doch nur das Zusammentreffen äußerst ungünstiger Umstände war - zumal es eben bisher noch nichts Vergleichbares gab (oder das wäre mir dann nicht aufgefallen, s.o.).

Nervig ist es trotzdem allemal, weil es eine weitere Kombination aus Kernel- und Library-Version zur Liste der "gebräuchlichen" Zusammenstellungen hinzufügt - wobei man die 1.0.30 dann wohl doch auch wieder einfach "vergessen" kann, wenn man nicht explizit auf die paar damit gebauten Labor-Versionen zielt bei den eigenen Anstrengungen.

 

[DickS]

Ganz ehrlich, ist es leider eine oft verbreitete Ansicht, dass es nicht gut ist immer die neuesten Versionen einzusetzen. Wozu das führt, sieht man bei dem kürzlich massiv aufgetretene Problem mit Citrix.

Es gibt hier, meine ich, eher psychologische Hintergründe wie (a) es läuft doch also warum was ändern oder (b) wenn wir die neueste Version nehmen handeln wir uns vielleicht neue Bugs ein.

In meiner Firma war das lange so, es wurden keine Updates der Systeme gemacht da man sonst das Risiko hat etwas funktioniert nicht mehr.

Allerdings ist in der heutigen Zeit mit den ganzen "Hack-Kompetenzen" da draußen diese Einstellung auf Dauer einfach Fatal.

Nur so kann ich mir AVMs Herangehensweise erklären, die vorherrschende kulturelle Einstellung....

 

[PeterPawn]

Wenn das "Never touch a running system." wäre (das ist bei Dir ja Punkt a und das beschriebene Vorgehen in der Firma), dann wäre die weitere Verwendung der 1.0.30 (oder gar der 1.0.14, wie in den vorherigen Versionen) ja "die Lösung" gewesen.

Wenn man aber ohnehin schon aktualisiert (warum auch immer, darüber kann man ja nur spekulieren - ich habe es bei AVM innerhalb einer Labor-Reihe eben noch nicht erlebt, zumindest dann, wenn die Labor-Reihe ja schon mit einem Update dieser Komponente begann, was hier ja auch der Fall war ... 1.0.14 -> 1.0.30 war von Beginn an geändert), dann kann man auch gleich die neueste Version nehmen, wenn die nur einigermaßen "abgehangen" ist und da sind 3 Monate schon ziemlich viel Zeit bei der Entscheidung, ob man eine 3 oder 14 Monate alte Version verwendet.

Und Punkt b ist hier auch nicht wirklich stichhaltig - das macht dann Sinn als "Überlegung", wenn man entweder gar nicht erst aktualisiert oder wenn die neueste Version (so wie die AVM-eigene Firmware) tatsächlich auch neue Funktionen enthält, die dann auch potentiell neue Bugs beinhalten könnten (und die muß man dann aber auch erst noch benutzen, damit das wirklich relevant wird als zu berücksichtigender Punkt).

Handelt es sich bei den zwischenzeitlichen Änderungen aber nur um Fehlerkorrekturen/Verbesserungen (auch solche mit Relevanz für die MIPS-Architektur der 7490 (bzw. VR9-SoCs) sind dabei, z.B. hier:

- https://cgit.uclibc-ng.org/cgi/cgit.../?id=3538ba34e0e415105d3fe235605e6dba1597ad98
- https://cgit.uclibc-ng.org/cgi/cgit.../?id=fa9cfbfcb70bd3736ec54eeeb4d0796aa4b9521f
- https://cgit.uclibc-ng.org/cgi/cgit.../?id=5efc10d24e1fb7f59817f007c18219dfc46bf457

... die Patches für memmove()/memcpy() sind für MIPS am Ende egal, weil das Ergebnis dasselbe ist, wenn beide fehlen),

dann braucht es für meine Begriffe eben länger, die einzelnen Patches hinsichtlich ihrer Relevanz zu untersuchen/bewerten, als einfach nur davon auszugehen, daß Patches, die es bis in eine Release-Version eines verwendeten Pakets schaffen (Reverts bzw. Korrekturen kommen meist unmittelbar, wenn die ersten Benutzer auf irgendeiner Plattform Probleme feststellen mit einem neuen Patch), dann auch ihre Berechtigung haben bzw. "nicht schaden" (weil sie für eine ganz andere Plattform bestimmt sind).

Ich habe jetzt nicht genau nachgesehen, wo sich die fehlenden Locks beim Anfordern von "aligned memory" (valloc/memalign) tatsächlich befinden und welche Auswirkungen ihr Fehlen hat, aber wenn andere dort Probleme gesucht und gefunden haben und diese Änderungen wiederum als "generell gültig" akzeptiert und in die Library übernommen wurden, dann setze ich doch schon aus Prinzip die korrigierte Version ein (und wie gesagt: Ein "bloß nichts ändern" fällt als Motivation hier ja bereits aus.) und hoffe, damit auch ein paar (bisher ungeklärte/unerklärliche/sporadische) Probleme mit der Speicherverwaltung in meinen eigenen Programmen nicht wiederzusehen oder ein paar künftige gleich ganz zu vermeiden.

Zwar kann man das Verwenden von solchen Funktionen wie "valloc()" oder "memalign()" auch "verbieten" (per Style-Guide), aber erstens ist das ineffektiv (wenn etwas in der C-Library geboten wird, muß man es ja nicht in eigenem Code noch einmal (und häufig genug sogar schlechter) implementieren) und zweitens braucht sich nur irgendjemand (aus reiner Unkenntnis oder als "schnell mal versuchen, ändere/ergänze ich später") nicht daran halten und schon enthält der Code meines "Teams" am Ende doch die Benutzung von (in der C-Lib enthaltenen) Funktionen, die ich gar nicht auf dem Schirm habe.

 

[DickS]

Ist zwar alles OT, aber ich kann schon irgendwie nachvollziehen das man sagt "Wir aktualisieren grundsätzlich auf die vorletzte Stable". Außer es gibt Sicherheitsbedenken, die ein sofortiges Handeln erfordern (gab es ja auch schon).

 

[NDiIPP]

Vielleicht ist die Sache viel banaler, als man glauben mag (oder wahrhaben möchte). Vielleicht wurde bei einer internen Verkostung in Berlin festgestellt, dass ein bestimmtes belgisches Bier doch nicht nicht so gut bei den Mitarbeitern und Mitarbeiterinnen angekommen ist wie Kölsch. Und beim (internen) Kölsch-Test hat dann Früh-Kölsch vielleicht etwas besser abgeschnitten als das Reissdorfer. Obwohl ich da als Laie damals keinen Unterschied feststellen konnte...

DuW

 

[PeterPawn]

@DickS:
Ich eben nicht ... erst recht nicht, wenn der "Verwender" solcher Software in seiner eigenen Rolle als Hersteller wieder so "verschwiegen" ist hinsichtlich konkreter Probleme, daß er sich selbst auf den Standpunkt stellt: "Wir gehen einfach davon aus, daß UNSERE Kunden immer die neueste Version verwenden werden und daher braucht es solche konkreten Angaben zu behobenen Problemen gar nicht bzw. erst seeeehr viel später, wenn die Updates dann auch alle auf den Boxen angekommen sind (so in 3-4 Jahren)."

Denke dieses "immer die vorletzte stabile Version verwenden"-Paradigma einfach mal konsequent bis zum Ende ... wenn das jeder in der "Pipeline" so macht, braucht man sich um Software-Security und "zeitnahe Fixes" eigentlich gar nicht mehr zu kümmern - nicht jedes Problem ist auf jeder Stufe einer solchen Kette auch sicherheitsrelevant und praktisch kein Hack findet heutzutage mehr über ein einzelnes, isoliertes Problem statt, das ist inzwischen immer die Kombination mehrerer, alleine gar nicht wirklich kritischer Lücken.

 

[gurkey]

Für mich zumindest durchaus nachvollziehbar, dass man zwar relativ aktuell sein aber trotzdem einen gewissen zeitlichen Sicherheitspuffer haben möchte, um sich nicht irgendwelche Anfangsfehler der aktuellsten Version einzufangen, die erst einige Zeit benötigen, bis sie ausgemerzt sind.

 

[NDiIPP]

In dem Fall eigentlich nicht verständlich. Handelt sich ja nicht um ein neues Major-Release sondern letztlich nur um so etwas wie ein Bugfix/Patch-Release. Zudem die Änderungen zwischen Ver. 1.0.31 und Ver. 1.0.32 eher "übersichtlich" scheinen.

Bei neuen Major-Releases könnte man tatsächlich noch nachvollziehen, wenn man nicht sofort auf die neue Version wechseln möchte. Bei vielen Softwareprodukten gibt es dementsprechend auch eine gewisse Zeit weiterhin Patch-Releases für die jeweilige Vorgänger-Version oder entsprechende LTS-Versionen. Das trifft aber hier nicht zu, ein dermaßen hoher Sicherheitspuffer (mehrere Monate) bei einem Bugfix- oder Patch-Release ist nicht nachvollziehbar.

 

[Grisu_]

@gurkey: Nach dem Grundsatz könnte die 1.0.31 genauso Fehler haben die in der 32 sehr wohl ausgemerzt wurden. Da ist eine sogut wie die andere.

Allerding könnte (rein theoretisch) auch sein, daß in der 32 erst welche eingebaut wurden oder auch nur gewisse Inkompatibilität zur AVM-Firmware bzw. daraus folgender Mehraufwand (und seis nur fürs Testen) sie bei der Wahl beeinflußt haben.
Oder es wurde schon lange früher entschieden und begonnen als die 32 noch gar nicht spruchreif war.
Und wenn es keine spürbare Verbesserung oder Fehlerbehebung bedeutet, wozu dann nochmals upgraden mitten im Prozeß.

 

[Black Senator]

Wer hat eine Lösung hierfür ?

Vorschlag: schau einmal hier (obwohl du ja die Lösung schon kennst)

Vermutliche Ursache:

U+00A0

\xc2\xa0

 

NO-BREAK SPACE

 

[mary-lou]

Kann jemand reproduzieren, dass es Probleme mit Endgeräten gibt, die eine feste IP haben (in der Netzwerkkarte des Endgeräts selbst eingetragen), insbesondere mit Fritz!Boxen, die als Clients fungieren?

Was mir eben noch aufgefallen ist, meine Client-7490 ist seit dem Tag der Installation der Beta bei myfritz inaktiv. Eine Client-7362SL ist weiterhin auch in myfritz als aktiv gemeldet.

 

[HarryP_1964]

Kann ich beides nicht bestätigen:

Mit meinen Shelly‘s mit fester IP (im Shelly WI) ist alles i.O. und meine 7490-CLIENT-Box taucht problemlos bei myfitz auf.

Harry

 

[mary-lou]

MyFritz klappt nach erneutem Zusenden der Bestätigung bei mir auch wieder. War aber nur bei der 7490 nötig.
Mit den festen IPs gibt es nach wie vor Probleme. Aber wenn ich den Geräten in der FB-Router feste IPs zuweise, läuft mit der neuen Beta alles gut.

 

[DickS]

Was bedeutet "Redzone-Check" auf der Supportseite?

 

[KunterBunter]

Diese Frage ist schon fast ein Jahr alt.

 

[PeterPawn]

Wobei der es - warum auch immer - inzwischen auch in die regulären Labor-Versionen geschafft hat (war iirc schon bei der 07.08 so), während er vorher nur in den Inhouse-Versionen auftauchte.

Ist das gesetzt, aktivieren die AVM-Binaries wohl eine noch ausführlichere Protokollierung ihrer Speicherverwaltung (zumindest legen das die dann zusätzlich gesetzten Environment-Variablen "SLAB_DEBUGUSER=y" und "SLAB_ABORT=y" nahe) ... vermutlich verwendet AVM auch für die Verwaltung von Speicher innerhalb der Userspace-Binaries (zumindest solchen mit Netzwerk-Funktionen) ein Konzept, das mit "slabs" (Scheiben Platten) arbeitet und im Prinzip einen Speicherpool für Objekte gleichen Typs darstellt (https://en.wikipedia.org/wiki/Slab_allocation).

Das spart (sofern die Strukturen eine halbwegs feste/identische Größe haben) einiges beim Initialisieren und Freigeben von (Haupt-)Speicher für solche Objekte und wirkt - dadurch daß der Platz praktisch reserviert ist - einer Zersplitterung entgegen, die bei den "üblichen" Speicherverwaltungsmechanismen (malloc/free) früher oder später einsetzt (fragmentation), wenn die Programme nur lange genug laufen und die Abläufe/Aufrufe nur ausreichend "chaotisch" aufeinander folgen.

Im Kernel existiert das ebenfalls und dort hat AVM in das anderenorts (bei der Nutzung von 192.168.180.1/2 für die Abfrage von DNS-Servern) diskutierte "SLAB management" auch einige zusätzliche Traces eingebaut, die - meist in Labor-/Beta-Versionen mit zusätzlichen Optionen beim Kompilieren des Kernels - auch zusätzliche Abbruchbedingungen beinhalten, wenn irgendwo die Speicherverwaltung "komisch" aussieht und analysiert werden sollte.

Das gibt es wohl in den Userspace-Programmen von AVM auch (natürlich dann nicht für Kernel-Speicher) und da solche zusätzlichen Kontrollen i.d.R. einen negativen Effekt auf die Performance haben, müssen sie wohl über diesen "Redzone-Check" aktiviert werden, wenn man sie verwenden will.

Geht man davon aus, daß dann auch in den Userspace-Programmen von AVM bei jeder Anforderung bzw. Freigabe von Speicherbereichen zusätzliche Prüfungen aktiviert werden (ich habe keine Idee, ob AVM da ein fertiges Paket oder etwas Selbstgeschriebenes verwendet für diese Aufgabe), drückt das natürlich auf die Performance und sollte wohl nur auf Aufforderung vom AVM-Support aktiviert werden, wenn man tatsächlich ein Problem in der Verwaltung von Speicherobjekten vermutet (z.B. beim Referenzieren von NULL-Pointern oder bei "out of memory"-Bedingungen in einem AVM-Programm) - die verwendeten Namen (SLAB_DEBUGUSER für das Aktivieren einer ausführlicheren Protokollierung und SLAB_ABORT für den Abbruch, wenn etwas komisch erscheint) verleiten mich jedenfalls zu dieser Interpretation, wobei ich andere Ideen, was das sein könnte/soll, auch gerne zur Kenntnis nehme.

TL;DR: Ich empfehle dem "normalen Benutzer" dringend, diese Option nicht aus eigenem Antrieb zu aktivieren ... es müßte (wenn ich nicht komplett falsch liege) negative Auswirkungen auf die Performance der Netzwerk-Daemons von AVM (vom "ctlmgr" bis zum "deviceinfod" und zum "WAN-Stack" "dsld" - dort werden dann nämlich in erster Linie diese zusätzlichen Variablen gesetzt, siehe "/etc/init.d/rc.net") haben (wg. der Protokollierung und der Prüfungen) und könnte auch zu zusätzlichen Abbrüchen (bei Inkonsistenzen, die ansonsten vielleicht in den Skat gedrückt würden) führen.

 

[DickS]

Neuer Labor:

--- Weitere Verbesserungen und Fehlerbehebungen in FRITZ!OS 7.19-75736/75737 ---

Internet:
• Verbesserung Bei Änderungen der Konfiguration der DoT (DNS over TLS) Einstellungen erfolgt eine Benachrichtigung (Push-Mail)
• Behoben Reproduzierbarer Neustart bei Hinzufügen einer Netzwerkanwendung unter "Internet / Filter"
• Behoben Priorisierte Anwendungen wurden nach Neustart gelöscht
• Behoben Aktivierung der verschlüsselten Namensauflösung im Internet (DNS over TLS) war nicht mit 2-Faktor-Authentifizierung geschützt
• Behoben Nur eine Portfreigabe bei manueller Adresseingabe möglich

WLAN:
• Verbesserung Stromverbrauch im Modus "Green AP" bei einer Kanalbandbreite von 160 MHz (VHT160) optimiert (7590 und 6590)
• Verbesserung Meldungen unter "System / Ereignisse" bei Anmeldungen am WLAN-Gastzugang verbessert

Smarthome:
• Behoben Fehlerhafte Solltemperatur bei Zugriff auf die FRITZ!Box über MyFRITZ!

System:
• Verbesserung Stabilität
• Verbesserung Anzeige gesperrter Geräte auf der Übersichtsseite ergänzt
• Verbesserung Schnelleres Laden der Benutzeroberfläche
• Behoben Überflüssiger Text bezüglich entgangener Anrufe war noch in den Einstellungen der "Info"-LED vorhanden

USB:
• Behoben RSS-Feeds ließen sich nicht mehr hinzufügen
• Behoben Zugriff auf den Online-Speicher schlug aufgrund des vermeintlich vollen Speichers fehl
• Behoben Falsche Anzeige der Speicherkapazität


ADSL/VDSL: gleicher Treiber
DECT: 5.95 (war 5.94)

 

[MikeNeoMike]

Fehler entdeckt. Wenn ihr auf den Link der siehe Bild eingekreist ist klickt, passiert auf der Oberfläche erst mal gar nichts und kurze Zeit später startet die Box neu. Drei mal getestet eben.




Bild geschrumpft by stoney