[Info] Unter die Haube geschaut - Änderungen/Neuigkeiten im FRITZ!OS der Labor-Reihe 07.19

[Marcedo]

Wow - sieht alles sehr gut recherchiert drein. klasse!

 

[PeterPawn]

Seit gestern (oder seit heute, das Dateidatum suggeriert gestern) stehen die Quellen für die 07.19 der 7590 auf osp.avm.de bereit - ob das die endgültige Fassung sein wird oder nicht, ist (mir) noch nicht endgültig klar.

Aber ich kann/muß schon mal eine Sorge, die ich nach dem AVM-Wechsel auf "musl" als C-Library hatte, revidieren. Die Library an sich ist ja ohnehin "nichts Schlimmes" (schließlich wird sie bei OpenWRT ebenso verwendet) - nur die MIT-Lizenz ließ mich vermuten, daß AVM hier künftig mauern könnte.

DAS muß ich als "Unterstellung" zurückziehen ... in dem Paket ist sauber die Verwendung von "musl-1.1.23" zu erkennen (eine "detection" hatte ich erst vor kurzem in "extract_version_values" noch eingebaut) und sogar die von AVM verwendeten Patches(!) gegen die originalen Dateien liefert man hier mit (in "GPL-gcc.tar.gz" -> "sources" -> "musl-1.1.23") - dafür meinerseits Applaus und "Chapeau!".

Ansonsten ist jetzt erst mal etwas Lesen angesagt ... meine Versuche, die 7590-Version als Alien auf einer 7580 zum (vernünftigen) Laufen zu bekommen, waren bisher nicht so sehr von Erfolg gekrönt.

Wer die Treiber (aus #9) für die Crypto-Hardware sucht, muß (zumindest im Moment) nicht in die Kernel-Quellen sehen, sondern in die separate Datei "Intel-hwcrypto.tar.gz" schauen.

 

[hermann72pb]

Mich würde in dem Zusammenhang echt interessieren, was AVM jetzt zum ersten Mal in der Weltgeschichte dazu bewegt hat, Quellen zu einer Labor-Version zu publizieren? Denn ich kann mir schon gut vorstellen, dass für AVM die Publikation dieser Quellen mindestens 2 Mann-Tage einer hoch qualifizierten (und gut bezahlter) Arbeitskraft gekostet hat. Alleine die Trennung der OSS von eigenen Quellen und die internen Freigaben dafür dürfen nicht so einfach sein. Oder haben sie angesichts der Vielzahl der unterschidlicher Produkte mittlerweile vernünftige Skripte geschrieben, die eine automatische Generierung der Quellen quasi per Knopfdruck erlauben? Auch deine Beobachtungen in die Richtung, dass sie eher von der OSS mit GPL-2 weg gehen oder zumindest versuchen es durch MIT und ähnliches zu ersetzen zeigen doch, dass sie es gerade jetzt nicht unbedingt nötig haben (zumindest von ihrem eigenen Betrachtungswinkel). Und die Anzahl der anzufragenden Personen würde ich diesmal auch eher unter 5 schätzen. Da hatten wir schon um 2008 ... 2011 hier deutlich breitere Anfrageaktionen nach GPL-Quellen erlebt, sodass alle Teilnehmer danach per E-Mail angeschrieben wurden, dass die Quellen bereits auf dem FTP-Server liegen. Selbst damals hatte es sehr lange gedauert (2-3 Monate) und gar nicht nach einer Labor, sondern nach einem richtigen Release.
Desweiteren hat AVM zum gerade vergangenen Jahreswechsel meiner Beobachtung nach zum ersten Mal keine neue Firmwareversion für ihren "Flaggschiff" herausgebracht, was sie in den Jahren davor zumindest gefühlt immer getan hatten (hier kann ich mich zwar in Details irren, die Tendenz war aber schon so).
Das klingt alles irgendwie danach, dass AVM sich in ihrem Verhalten verändert. Da ich allerdings von der Grundhaltung her und vom Glauben ans Gute im Menschen sehr skeptisch bin, erwecken in mir solche spontane Aktionen von AVM eher Fragen als Begeisterung. Es ist aber nur rein Bauchgefühl...
Dennoch wünsche ich dir viel Erfolg beim studieren der Quellen!

 

[PeterPawn]

Vielleicht hilft eine gewisse (dabei aber immer freundliche) Hartnäckigkeit ja auch, gepaart mit einem Verweis auf die Lizenzbedingungen ... außerdem stimmt Deine Beobachtung hinsichtlich der Quellen für Labor-Versionen so auch nicht, wie ein Blick in die Verzeichnisse auf osp.avm.de belegt: http://osp.avm.de/fritzbox/fritzbox-7490/ - wie man sehen kann, gab es schon bei der 06.10 und der 06.98 für das (damalige) Flagship-Modell auch die Quellen für Labor-Versionen.

Trotzdem bin ich (positiv) überrascht vom Inhalt des Pakets für die 7590 ... es macht für mich den Eindruck, als hätte AVM darin auch etwas aufgeräumt und ich finde es (auf den ersten Blick) übersichtlicher. Leider sind einige Teile (u.a. das Füllen der "avm_kernel_module_memory"-Strukturen mit den Werten für die aktuellen Module) immer noch nicht dabei und auch bei den Host-Tools (wo sich ein passendes "mksquashfs" ja eigentlich finden lassen sollte) sehe ich noch einige Lücken. Aber steter Tropfen höhlt bekanntlich den Stein und vielleicht kommen ja auch diese Teile irgendwann noch nach.

Vielleicht habe ich mit meiner Einschätzung, daß AVM den Sprung zu "musl" nur wegen der MIT-Lizenz machte, ja auch geirrt (deshalb schreibe ich ja immer deutlich, daß das nur Annahmen sind und worauf sie letzten Endes beruhen) ... schließlich setzt OpenWRT auch auf diese Library und wer eine schlanke C-Library - auch für Embedded-Devices - haben will, ohne gleichzeitig den Konfigurationswust der uClibc-ng zu haben (eine ".config" für die uClibc-ng enthält 188 Einstellmöglichkeiten, auch wenn einige davon einander ausschließen), der kann auch aus diesem Grund zu "musl" greifen. Vielleicht war das bei AVM ja auch ein entscheidendes Kriterium ... wobei man bei der 7490 den Sprung ja offensichtlich (noch?) nicht wagte.

Andererseits sind eben einige Pakete, die unter MIT-Lizenz stehen und eher mit AVM-Daemons in Verbindung zu bringen wären, als mit dem "Basissystem", auch nicht dabei in diesem Quelltext-Paket (soo sehr daneben liegt man also mit einer Annahme, daß "MIT-Lizenz bevorzugt" gelten könnte, dann auch nicht) und es findet sich auch (zumindest auf den ersten Blick) kein Hinweis auf ihre Verwendung ... da fiele mir eben als erstes die "libasecutils.so" ein, die ziemlich eindeutig auf dem "nanomsg-ng"-Projekt basiert. Das steht unter MIT-Lizenz und die einzige Forderung aus dieser Lizenz an die Nachnutzer wäre es, den Copyright-Vermerk der originalen Dateien dem eigenen Produkt beizufügen ("The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.").

Nur sucht man (zumindest mit "grep" über die entpackte Firmware) vergeblich nach einem Vorkommen der Zeichenkette "Staysail", die in einem solchen Copyright-Vermerk für die "libnanomsg-next-generation" eigentlich enthalten sein müßte. Auch wenn das wohl eine "Zwei-Mann-Firma"ist ... bzw. eine Ein-Mann-und-seine-Frau-Firma und hier ist diese "Einordnung" sicherlich auch "politisch korrekt", denn Garrett D'Amore ist wohl derjenige, der die Entwicklung dort betreibt.

Dieses Fehlen der Infos gilt ebenso für die (derzeit aktuelle) Lizenz-Datei von AVM unter der URL http://ftp.avm.de/fritzbox/license.txt - auch da findet sich (hoffentlich noch) kein Hinweis darauf, daß die (neue) Firmware für die 7590 (und sei es dreist auch erst eine Labor-Version, auch die MIT-Lizenz macht da keinen Unterschied) nunmehr Software enthält, die dieser Lizenz: https://github.com/nanomsg/nng/blob/master/LICENSE.txt unterliegt - dort sind dann auch die Copyright-Holder (so ein (C) ist im deutschen UrhG anders bewertet, ein echtes "Copyleft" kennt das UrhG nicht) benannt.

Ich finde es auch nicht "unbillig", wenn AVM aufgefordert wird, auch für Labor-Versionen die Pakete bereitzustellen, die einer entsprechenden Lizenz unterliegen. Niemand zwingt AVM dazu, eine Labor-Version an die Öffentlichkeit zu bringen (hier rede ich nicht von den "Inhouse-Versionen"), BEVOR das entsprechende OpenSource-Paket ebenfalls so weit vorbereitet ist, daß es entweder pro-aktiv oder auf Anforderung bereitgestellt werden kann. Wenn dazu tatsächlich zwei PT eines hochqualifizierten Mitarbeiters erforderlich sind, dann muß man die eben auch in die Planung für "delivery" einbeziehen und das ggf. so lange verschieben, bis auch diese Daten bereitstehen und man damit "sauber" im Hinblick auf die Einhaltung der Lizenzbestimmungen der von einem selbst verwendeten "freien Software" ist. Das gehört eben auch dazu, immerhin spart man auf der anderen Seite ja durch die Verwendung solcher Software auch erheblich an eigenem Entwicklungsaufwand und macht das nicht nur, damit überhaupt irgendjemand diese Software-Pakete "nachnutzen" würde.

 

[PeterPawn]

C-Library-Version bei der 7490 noch einmal geändert von AVM: https://www.ip-phone-forum.de/threads/fritz-box-7490-07-19-labor-serie.305075/post-2356169

 

[zerokewl]

Hi Leute ich würde gerne die neuste INHAUS FW testen, da ich mit meiner FB7530 Probleme mit dem WLAN AP Steering habe.
Kann mir jemand sagen wie ich da ran komme?

 

[NDiIPP]

Ja, das würde mich auch interessieren!

 

[PeterPawn]

Ja, das würde mich auch interessieren!

Ein paar Geheimnisse sollte man AVM lassen ... mir würde es schon reichen, wenn AVM die Konfigurationsdateien für BusyBox, Buildroot und die "uClibc-ng" wieder in die OpenSource-Pakete packen würde.

Eine entsprechende Bitte per E-Mail (eigentlich eher den Hinweis, daß die in den derzeit veröffentlichten Paketen fehlen) habe ich am Montag auf den Weg gebracht ... mal sehen, wie lange es dauert, die drei Dateien "nachzuliefern". Die einzige Konfigurationsdatei, die da nach ein paar Umstrukturierungen seitens AVM noch übrig geblieben ist, wäre die für den Linux-Kernel ... die anderen Files, die bisher immer in der "GPL-gcc.tar.gz" im Verzeichnis "conf" lagen (für alle möglichen Plattformen, aber wenigstens waren sie dabei), hat man wohl vergessen beim Zusammensuchen.

 

[PeterPawn]

Nach Infos von AVM (E-Mail vom 04.03.2020 16:25 Uhr) enthält das OSS-Paket für die 7590 jetzt auch die Konfigurationsdateien für die C-Library (wobei "musl" eigentlich gar keine Konfiguration braucht) und die BusyBox, ggf. auch für die Buildroot-Toolchain, wenn man kein Freetz verwendet oder verwenden will.

Allerdings habe ich noch nicht reingesehen ... da wieder alle Datumsstempel der Dateien geändert wurden, ist das Synchronisieren (wieder mal) nervig und dauert, weil beim Mirroring (wget -m) alle Dateien erneut geladen werden. Aber AVM hat wohl kein Problem mit den zu übertragenden Datenmengen ... dann habe ich auch keins, außer daß es halt dauert (mehr als 5 MB/s (gemittelt) liefert der Server bei mir jedenfalls nicht).

 

[PeterPawn]

06.03.2020 16:10 Uhr

E-Mail von AVM, das Paket für die 113.07.19 ist jetzt auch erneuert und soll komplett sein, inkl. Konfigurationsdateien für die C-Library und die BusyBox (in "GPL-gcc.tar.gz/conf").

Danke an AVM und die Support-Mitarbeiter dort, schönes Wochenende.

======================================================

Das Paket enthält jetzt auch die uClibc-ng in Version 1.0.31 ... die hatte sich unmittelbar nach der ersten Veröffentlichung der Quellen in der 7490 dann geändert, vorher war es noch die 1.0.30.

Auch die 6490/6590 verwenden mittlerweile die 1.0.31, aber für diese beiden Modelle stehen die Quelltext-Pakete noch aus.

Hat die event. schon jemand anderes angefordert? Ich will nicht schon wieder mit dem nächsten Wunsch bei AVM aufschlagen.

Wie sieht es bei Dir aus, @f666? Hast Du weiterhin Interesse an den Puma6-Boxen oder nur noch an Puma7?

Was ist mit Dir, @fesc?

Ich denke mal, mein früherer "Aufruf", daß sich möglichst mehrere Leute für die zeitnahe Veröffentlichung der 07.19-Pakete stark machen, hat sich erledigt und wenn man die Anforderung weiterer Quelltext-Pakete für andere Modelle abspricht (7530 und die Puma6-Boxen, ggf. sogar Puma7, wären ja weitere Kandidaten nach dem heutigen Stand bei den veröffentlichten Labor-Versionen), hat AVM zumindest weniger Tickets zu diesem Thema zu verwalten und dann auch weniger E-Mails zu schreiben und zu versenden, wenn die Pakete verfügbar sind. An der prinzipiellen Bereitschaft, die Pakete auch jetzt schon "herauszugeben", sollte es ja nun nicht scheitern.

 

[fesc]

Was ist mit Dir, @fesc?

Die 6591 sourcen für 7.13/7.19 haben ich beantragt ...

 

[PeterPawn]

Danke für die Info, dann spare ich mir das schon mal. Verstehe ich das aber richtig, daß Du bei Puma6 nur noch mäßiges Interesse hast, trotz Deines Bitbucket-Repos?

 

[fesc]

Ich h

daß Du bei Puma6 nur noch mäßiges Interesse hast

Im Augenblick habe ich leider keine funktionstüchtige 6x90, deshalb bin ich da nicht up to date.

 

[f666]

Hi,

ich habe nach wie vor Interesse an der Unterstützung der 6{4,5}90, in den letzten Monaten aber nichts daran gemacht, da mir in den Laborversionen zu viel "in der Schwebe" war.
Ich schreibe eine Anfrage an AVM...

 

[PeterPawn]

Thx for info.

 

[Marlow]

Ansonsten würde ich mal raten, daß sich die neuesten Labor-Versioenn tatsächlich auch auf den internationalen Versionen der FRITZ!Box (mit Branding "avme") installieren und benutzen lassen ... sogar die 7490-Version enthält die notwendigen Daten und Einstellungen für eine internationale Box.

Ich kann dieses übrigens bestätigen. Sowohl auf der 7490 als auch auf der 7590 in Internationaler Variante lassen sich die Labor Versionen installieren. Derzeit kriegt man dann eine Mischung aus der Sprache die man gewählt hat und Deutsch, da gewisse Teile der Laborfirmware noch nicht übersetzt sind.

Das hat, mal abgesehen von den Bugs, dann auch keine nachhaltigen Nebenwirkungen.

/M

 

[eisbaerin]

Das könnte den IPSec-Durchsatz bei GRX-Boxen deutlich steigern ...

Bei der FB6591 (Puma 7) klappt es ja auch schon.
Wird das auch für die FB7520/7530 (IPQ) kommen? Oder hat die HW das nicht? Oder ist es in der neusten "Inhaus" 76891 schon vorhanden?

 

[eisbaerin]

@PeterPawn
Leider hast du nicht geantwortet.

Nach langem Suchen und mit Hilfe habe ich herausgefunden, welche Datei du in #9 meinst, wo das
etc/init.d/rc.hwcrypto aufgerufen wird:
etc/boot.d/core/head
Kannst du das bitte in #9 ergänzen?

Was ich damit heraus finden konnte:
Diesen Aufruf in dieser Datei gibt es bei der 7530 auch schon seit genau der 76251.
Die eigentliche Datei fehlt aber noch (Stand 76958).

Diesen Aufruf gibt es aber auch in der 7490, obwohl die IMO keine HW dafür hat und es demzufolge nie kann.

Die 7530 soll es HW-mäßig laut hören-sagen können, aber ob AVM es bei der lowprice Box implementieren wird bleibt wohl die große Frage.

Siehst du das auch so? Oder weißt du genaueres?

 

[PeterPawn]

Leider hast du nicht geantwortet.

Was hätte ich Dir da - einigermaßen plausibel und stimmig - antworten sollen?

Eine Frage, die mit:

Wird das auch für die FB7520/7530 (IPQ) kommen?

beginnt, KANN ich einfach nicht wirklich beantworten.

Ich habe keine "Sonderinformationen" von AVM und ich habe hier auch schon mehrfach "bekanntgemacht", aus welchen Modellen mein Gerätepark besteht und daß sich meine Bestrebungen, die AVM-Firmware zu analysieren, auch auf diese Modelle beschränken. Warum ich dabei dann die 7590 trotzdem angesehen habe, obwohl ich doch gar keine besitze, steht auch weiter vorne ... weil ich versuchen wollte (sofern die Zeit dafür verfügbar ist), die 7590-Firmware auf einer 7580 zu verwenden, weil der wichtigste technische Unterschied (zumindest im Kernel) eigentlich nur darin bestehen sollte, daß die LEDs anders angesteuert werden (die 7580 kann nicht dimmen und hat auch keinen Sensor für die Umgebungshelligkeit).

Warum sollte ich also damit beginnen, mir die Firmware für 7520/7530 oder (IPQ-SoCs im Allgemeinen) näher anzusehen? Ich gebe ganz offen zu, daß mich das gar nicht wirklich interessiert - auch wenn ich das Interesse der Besitzer solcher Boxen natürlich nachvollziehen kann.

Hätte die Frage also u.U. dahingehend gelautet, ob ich jemandem, der bei der eigenen Analyse der Firmware nicht weiter weiß (obwohl er über den Punkt: "Wie geht das eigentlich überhaupt?" schon lange hinaus ist), bei einem konkreten Problem behilflich sein würde, wäre die Antwort vermutlich eine andere gewesen (bzw. es hätte eine gegeben).

Ich kann andererseits überhaupt nicht nachvollziehen, wieso es Dir dann erst "mit Hilfe" gelungen ist, die Stelle zu finden, wo die "rc.hwcrypto" aufgerufen wird, was ich in #9 gezeigt habe. Ein einziges "grep"-Kommando über die entpackte Firmware sollte da bereits ausreichen ... soo zahlreich dürften die Fundstellen nicht sein (in der 77061 gibt es exakt eine einzige davon).

Und ich denke auch nicht, daß ich irgendetwas in früheren Beiträgen ergänzen will ... ich hatte ja meine Gründe, direkt in #1 in diesem Thread meine Position darzulegen:

Etwaige Irrtümer werde ich auch nicht dadurch korrigieren, daß ich einmal Geschriebenes ändere oder lösche ... wenn nötig, kommt da eine Ergänzung mit dem Verweis auf neuere Erkenntnisse hin oder ich gehe sogar davon aus, daß man die Beiträge bis zum Ende liest und spätere Korrekturen auch im "reinen Text" findet und erkennt. Wer das nicht möchte, sollte ggf. gleich in Erwägung ziehen, ab hier nicht weiterzulesen.

Und um den letzten Absatz aus #38 auch noch aufzugreifen (ich bin halt von oben nach unten durchgegangen) ... ich weiß da natürlich nichts Genaueres (meine Kontakte zu AVM sind nicht besser, als die jedes anderen Besitzers einer FRITZ!Box, u.U. sogar schlechter, wobei ich das - mangels Vergleichsmöglichkeiten - natürlich auch nicht definitiv sagen kann) und über die Frage, wie weit AVM jetzt tatsächlich Anstrengungen unternimmt, die Crypto-Hardware der verschiedenen Plattformen (so vorhanden) zu unterstützen, habe ich noch gar nicht gründlich nachgedacht.

Da bisher auch hinsichtlich der Verwendung der Hardware für das VPN und/oder TLS-Verbindungen (die würden davon natürlich auch profitieren können) noch nicht wirklich viel in der Firmware zu sehen war (die letzten Labor-Versionen vom vergangenen Freitag habe ich bisher nur entpackt und noch nicht mal hineingesehen), kann man (ich) auch noch nicht abschätzen, wo AVM da auf eine "Abstraktionsschicht" setzt (also mit der eigenen Software nur auf ein passendes API zugreift, das dann seinerseits wieder auf die konkret vorhandene, durchaus auch mal unterschiedliche Hardware der Plattform zugreifen soll) und wo nicht.

Die erwähnte "hwcrypto" macht ja noch nichts anderes, als den PRNG des Linux-Kernel so zu "seeden" (also mit einem Startwert zu versehen), daß da tatsächlich auch mal zufällige Werte entstehen und damit auch eine "Vielfalt" bei den von der Firmware generierten Schlüsseln einzieht. Denn solche "embedded devices" haben bisher (bzw. "früher") alle dasselbe Problem (gehabt) ... die Quellen, aus denen der Linux-Kernel auf anderen Systemen seine "Entropy" (also genug Chaos, daß Vorgänge nicht mehr "vorhersagbar" bzw. "determiniert" ablaufen) bezieht (das sind z.B. Mausbewegungen, Tastatureingaben, Zugriffzeiten auf HDD-Sektoren (weil die Zeiten, bis ein Sektor unter dem Schreib-/Lesekopf vorbeikommt, variieren), Uhrzeit aus einer (durchlaufenden) RTC (Real Time Clock), usw.), auf einem solchen Gerät gar nicht existieren und es damit nur extrem wenige Variablen gibt, die in die Erzeugung zufälliger Werte durch einen PRNG (das "P" steht für "Pseudo" und bedeutet am Ende, daß der aus demselben "Startwert" (Seed) auch immer denselben Ausgabewert erzeugt, was dann natürlich von echtem Zufall und tatsächlich "random" meilenweit entfernt ist) eingehen können bei diesen Geräten.

Wenn das schon von AVM in einer Art und Weise implementiert wurde, daß es zunächst wohl mal auf allen Boxen versucht wird aufzurufen (und dann halt bei fehlender Hardware nichts machen kann), deutet das zwar darauf hin, daß AVM das irgendwie von der Hardware abstrahieren will ... aber ob das für VPN (oder gar die Crypto-Funktionen im Kernel - wobei da die SoC-Hersteller ja i.d.R. die passenden Patches liefern und AVM diese bisher halt nur nicht genutzt hat) auch gilt und ob sogar Userland-Software von einer Hardware-Unterstützung profitieren würde (trotz ggf. notwendiger Kontextwechsel vom User-Mode in den Kernel-Mode und zurück), kann ich auch nur vermuten und hoffen, daß AVM das schon irgendwie sauber "messen" wird.

Solange man dort für TLS-Verbindungen auf OpenSSL setzt und die dort enthaltene "libssl.so", die ihrerseits die Funktionen aus der "libcrypto.so" für die Kryptographie nutzt, hätte man zwar die Chance dazu, das über eine "einheitliche Schnittstelle" abzuwickeln und diese dann auch - bei den von der Hardware überhaupt unterstützten Funktionen, denn dieser Umfang ist i.d.R. begrenzt ggü. den Software-Implementierungen - über Hardware-Funktionen zu beschleunigen ... sofern der "gain" da nicht vom zusätzlichen "effort" wieder aufgefressen wird durch zusätzlich notwendige Operationen (eben z.B. die angesprochenen Kontextwechsel, die AVM ja mit der eigenen "Yield"-Implementierung versucht nach Kräften zu minimieren).

Ich kann also genauso nur "in die Glaskugel schauen", wie jeder andere IPPF-Leser auch (außer die getarnten AVM-Leute, die hier mit einiger Wahrscheinlichkeit mitlesen, aber sich - bis auf einen Einzigen und der ist mittlerweile wohl auch schon wieder "Geschichte", was eigene Beiträge angeht - nicht zu erkennen geben) und wenn ich dann mal keine Lust dazu habe bzw. es mich nicht wirklich interessiert, dann verzichte ich eben auch nur auf eine Antwort (einige Leute kann ich nicht mal sehen, weil sie inzwischen in meiner "Ignore"-Liste stehen und ich zum Lesen ihrer Beiträge immer noch ein paar Zusatzklicks bräuchte - auch wenn Du da nicht enthalten bist), anstatt mich dem Risiko irgendwelcher anderen "Anfeindungen" auszusetzen, wenn ich das einfach nur feststelle (daß es mich nicht interessiert) und dann irgendjemand auf die Idee kommt, von mir eine Erklärung dafür zu verlangen oder mir gar erneut "verweigerte Hilfestellung" zu attestieren.

Ich weiß also nicht genau, wie der eingangs von mir zitierte Satz am Ende gemeint war ... drückt er tatsächlich nur ein Bedauern aus, habe ich meine Gründe dafür (auch nicht zum ersten Mal) dargelegt. Soll er am Ende eher Vorwurf sein, daß ich meinerseits nicht reagiert habe, wäre er - in meinen Augen - unangemessen ... schon von der Idee her, die dann dahinter "aufscheinen" würde.

 

[eisbaerin]

Danke! Nein, sollte auf keinen Fall ein Vorwurf sein.
Ein kurzes: Weiß ich auch nicht, hätte mir auch schon gereicht.