[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Eigentlich wollte ich diesen Text hier
Wie geht es mit dem Tool weiter?

posten, aber hier passt er nach Fertigstellung besser

Ich glaube so langsam wird die Menschheit einfach nur "dumm" - entschuldigt, aber wo sind wir hier?


Achja ein einem User helfen User Forum, welches jedem unentgeldlich (sowie auch solche Programme) zur Verfügung stehen.


Für keines der hier angebotetenen Programme (egal wie sie heißen mögen) hält der Author die Hand auf, es wird lediglich verlang, sich vorab mit der Materie sowie dem Vorgehen bei den diversen Unterschieden (in HW und FW) auseinander zu setzen und diese ggf. auf zu frischen.


Würde hinter dem Ganzen Profit stehen, wäre sicherlich auch Geld für eine Person verfügbar, welche zB ein Wiki erstellt und aktuell hält.


Es wird nach kostenloser Hilfe geschrien, ja auch die SW dazu soll am besten OpenSource sein und dann soll das gefälligst auch noch anstandslos und automatisch sämliche technische (physische) Schritte auch direkt noch mit übernehmen?

Und falls das nicht der Fall ist, muss das Programm ja wohl eine Lösung vorschlagen und nicht mit irgendwelchen 'error-codes' in einer hässlichen Console daherkommen?




Langsam wird es echt dreist, immer mehr wollen sich auf Kosten freiwilliger Anderer eine Lenz machen? (Das fängt beim dummen Mod in einem solchen Forum an und hört bei der Elite, der Programmierer/Informatiker, auf)


Wer mit den vorhandenen Infos nichts anfangen kann oder will muss sich nach Alternativen (lol) umsehen und dann eben diese (falls es sie gibt) nutzen.


Ich verstehe auch nicht, dass jmd. der sonst nie etwas mit IT zu tun hat/hatte der Meinung ist, ich grätsch jetzt mal schnell in eine FW und bearbeite/erweitere diese, obwohl ich nicht mal genau weiß für was - aber irgendwo stand irgendwann mal.... desshalb...


Kauft euch doch dementsprechende Geräte, welche euren "Anforderungen" entsprechen.


Die Wenigsten würden ebenso blauäugig die Hand an der Zetralheizung, Strom, KFZ anlegen.


Die Außnahmen bestätigen bekanntlich die Regel, diese zeigen dann mit dem Finger auf eine URL und sagen: "Da habe ich mich 'schlau' gemacht - dort ist der Schuldige für das heruntergebrannte Haus/Auto zu suchen und derjenige muss zur Rechenschaft heragezogen werden!"


Es ist kein Wunder, dass es immer weniger Qualität gibt. Dafür steigt die Quantität ins unermessliche.
 
Es ist ebenso dreist, einen Verbesserungsvorschlag (User hilft User) als "einen Lenz machen" zu bezeichen (wenn ich das richtig gedeutet habe). Ich glaube, alle hier sind @PeterPawn dankbar für seine Entdeckungen. Aber wenn im calllog Mod nichts von telnet steht, dann muss ich das Wissen, dass es einen Zusammenhang mit Telnet gibt, bereits haben, um danach Suchen zu können. Und auf einfachste Weise Telnet aktivieren zu können, ist wohl das Ziel der meisten User. Mir leuchtet einfach nicht ein, warum Peter lieber 10 Usern sagt "Nutze die SuFu", statt 1x zu dokumentieren und dann fragen vielleicht noch 2. Und wenn bei denen dann gar keine Eigenleistung mehr erkennbar ist, dann bleibt die Antwort vielleicht sogar ganz aus.
 
@Chatty:
Laß uns das einfach mal ganz ernsthaft angehen ... bist Du tatsächlich der Ansicht, daß irgendein Benutzer des IPPF eher in einem Shell-Skript im Repository nach Informationen suchen wird, als hier im Board? Warum sollte er das tun bzw. warum sollte er dann solche Suchen auf das GitHub-Repository beschränken und nicht gleich das IPPF auch noch durchsuchen?

Wie sähe denn bitte (aber richtig zeigen und nicht nur umschreiben) nach Deiner Ansicht die richtige Form der Dokumentation für den Umstand aus, daß durch das Aktivieren des "private mode" für den "telefon"-Daemon auch das Ein- und Ausschalten des Telnet-Zugangs weiterhin funktioniert?

Das "mod_enable_calllog" ist eben auch bloß ein einziges Skript, das sich diesen "versteckten Modus" von AVM zunutze macht und hat vordergründig mit "telnet ein/aus" nur sehr wenig zu tun und wenn, dann tatsächlich erst ab Version 07.0x, denn zuvor ging das ja auch ohne diesen "private mode" noch per Telefon - wenn auch mit Einschränkungen. Da hat(te) das also noch gar nichts wirklich mit diesem "private mode" zu tun bzw. es funktionierte auch ohne.

Wo sollte jetzt ein besserer Platz sein als in einem Beitrag im IPPF, um diesen Umstand zu erwähnen?

Wie gesagt ... das ist tatsächlich eine echte Frage meinerseits und ich bin auf die Antwort (und die Überlegungen, welche zusätzlichen Arbeiten sich daraus am Ende ergeben würden, wenn ich das an anderer Stelle mache bzw. wieso das dann besser zu finden wäre - und zwar wieder für die Mehrzahl derjenigen, die nach Informationen auch tatsächlich suchen und nicht nur behaupten, sie hätten das bereits seit Tagen erfolglos getan) durchaus gespannt.

Denn anders als Du sehe ich tatsächlich auch meine Hinweise an andere, daß ich etwas hier irgendwo schon einmal beschrieben habe, durchaus als hilfreich an. Denn schon die Feststellung, daß ich das war, ermöglicht es, die Suche von den knapp 2 Mio. Beiträgen im IPPF auf die knapp 11.000 zu beschränken, die ich verbrochen habe. Das ist per se schon mal nur noch ein halbes Prozent der ansonsten zu durchsuchenden Beiträge und mit passenden Stichworten kann man die Ergebnismenge tatsächlich auch noch deutlich weiter eingrenzen (@MuP hat das weiter vorne für "calllog" ja exemplarisch gezeigt).

Aber das ist eben immer eine Aufgabe, die ich bei demjenigen verorten würde, der auf der Suche nach einer Information ist ... ich habe noch in der Zeit meine Ausbildung gemacht, als es für die Recherche irgendwelcher Quellen in erster Linie die Karteikarten im Katalog der Zentralbibliothek gab (ich weiß nicht wirklich, wieviel Zeit meines Lebens ich in der Berliner Stadtbibliothek in der "Breite Str." verbracht habe, aber es war eine erkleckliche Summe, da bin ich mir sicher) und man sich dann in den dort herausgesuchten Büchern zu einem Thema selbst das notwendige Wissen anlesen mußte.

Da kann ich es tatsächlich nicht verstehen, warum jemand heutzutage aus dem "information at your fingertips" (und das ist ja keine Utopie, sondern gelebte Realität) selbst so wenig macht, daß er mit einer Auskunft, daß es die gesuchte Information tatsächlich gibt und sogar noch, wo sie steht, so gar nichts anzufangen weiß.

Ich stelle mir dann immer unwillkürlich die Frage, wie sich so jemand wohl verhalten würde, wenn es das Internet und die damit verbundene Informationsflut gar nicht gäbe ... würde er dann von seinem Nachbarn oder Arbeitskollegen erwarten, daß diese die "Arbeit" (und eine Recherche nach Infomationen ist durchaus Arbeit und zwar sogar extrem harte, wenn die Infos wirklich schwer zu finden sind) für ihn übernehmen? Wohl eher nicht (bzw. die würden ihm was husten) ... und dann stünde er tatsächlich wieder vor der Entscheidung, auf die Information zu verzichten oder eben selbst zu suchen.

Was will ich damit sagen? Es geht überhaupt nicht, die Informationen mit entsprechend geringem Aufwand so darzustellen, daß damit tatsächlich jeder zufriedengestellt ist - irgendeiner ist am Ende immer unzufrieden. Mögliche "Einwände" von "Lesern" habe ich zuvor schon aufgezählt und es gibt auch einen Grund, warum es neben der iX noch die Computer-Bild gibt - es sind einfach unterschiedliche Zielgruppen und man kann mit derselben Darstellung unterschiedliches Niveau bei den Vorkenntnissen einfach nicht ausgleichen.

Man muß also einen "Kompromiß" finden und das kann und wird halt nur die Form der "Informationsweitergabe" sein, bei der ich mich auch selbst wohlfühle ... deshalb geht es mir auch am Gluteus Maximus vorbei, wenn jemandem meine Beiträge zu lang und ausschweifend oder nicht "laiengerecht" genug oder was auch immer sind - wenn ich das in Buchform herausbringen würde, müßte er sich da auch durchlesen und wer z.B. schon mal das Linux-Buch von Kofler oder das Asterisk-Buch gelesen hat, der weiß wovon ich da rede.

Hier im IPPF hat er tatsächlich noch die Möglichkeit der Nachfrage und einer solchen habe ich mich bisher nur äußerst selten verweigert und meist auch nur dann, wenn ich den Eindruck gewonnen hatte, daß sich jemand weiterhin "einen schlanken Fuß" machen wollte. Es gehört eben auch bei einer Frage bereits dazu, welche Quellen man bisher schon konsumiert hat und was man diesen entnehmen konnte ... bis hin zur Erläuterung, warum einem diese Quellen nun so gar nicht weiterhelfen konnten. Es bringt ja auch nichts (und zwar beiden Seiten nicht), wenn man die Informationen aus genau diesen, bereits "verworfenen" Quellen nun noch einmal "vorbetet" - ein fast unausweichliches Ergebnis, wenn sich eine Seite deutlich zu "schmallippig" zeigt.

In dem Moment, wo es für mich zur "Pflicht" (oder Verpflichtung) wird, das in einer bestimmten Form machen zu sollen (die mir obendrein nicht mal einleuchtend erscheint), verliere ich (mit Ansage) auch die Lust. Und wenn jemand so "busy" ist, daß er zwar die Zeit für (teilweise auch recht unverschämte - nicht persönlich nehmen, meine ich hier alles eher allgemein) Fragen in die Runde hat, aber auf keinen Fall die Zeit hat, selbst nach Informationen zu suchen, der hat bei mir - auch mit Ansage - eben bereits verloren.

Das gibt es bei mir nicht ... wem seine eigene Zeit weitaus kostbarer ist als die all der anderen, denen er mit seiner - sichtlich leicht durch eigene Suche zu beantwortenden - Frage immer auch etwas von der ihren stiehlt, der hat die "Belohnung" in Form von Erfolg für diese Rücksichtslosigkeit (und als solche sehe ich das häufig eben an) auch nicht verdient. Das gilt dann auch für den Notfall-Sanitäter, der gerade vom Rettungseinsatz zurück ist (obwohl er doch so tapfer der Allgemeinheit dient - hatten wir ja auch schon, daß jemand auf den Zug aufspringen wollte), der hat dann nämlich zu diesem Zeitpunkt auch nichts wirklich an der Tastatur verloren, wenn er in Bereitschaft zu sein hat bzw. das IPPF ist wohl kaum der richtige Ort zur Verarbeitung eigener Traumata.

Und meine in diesem Zusammenhang immer wieder gestellte Frage, warum das der Nächste dann anders machen sollte bzw. was den gerade "Betroffenen" so viel besser macht als jeden weiteren Fragesteller, hat mir bisher noch niemand so beantworten können, daß ich die Logik dahinter verstanden hätte, welchen Mehrwert die Allgemeinheit (und nicht nur dieser konkrete Fragesteller) jetzt davon hätte, wenn dieselben Informationen mehrfach vorhanden sind. Redundanz als Vorbeugung gegen Verlustängste kann es hier auch nicht sein, die solches Vorgehen rechtfertigen könnte ...

Ich bin deshalb auch immer so angefressen, wenn man mir diese Haltung vorwirft, weil ich mit ihr niemals hinter dem Berg gehalten habe und meiner Ansicht nach tatsächlich inzwischen schon fast zu oft begründet habe, warum ich das so sehe. Ich möchte es einmal erleben, daß sich tatsächlich jemand mit den von mir in diesem Fällen vorgebrachten Argumenten auseinandersetzt und diese widerlegt oder wenigstens aufgreift und seine Sicht genauso erläutert und begründet, wie ich das in der Regel mache. Und da nutzen mir dann auch "gute Ratschläge" nichts, wie man es besser machen müßte - da gilt dann tatsächlich "nicht reden, sondern zeigen und machen" - wie das in einer idealen Welt alles viel besser ginge, kann ich mir auch mühelos ausmalen. Aber es sind nun mal alle Ressourcen (außer der menschlichen Dummheit - nach A. Einstein) begrenzt und damit kann man nicht dieselben Information fünfmal in verschiedenen "Schwierigkeitsstufen" und "Zusammenhängen" niederschreiben, damit man auch tatsächlich jeder "Zielgruppe" gerecht wird.

Ich bin nun mal nicht AVM - denen erteile ich vielleicht manchmal auch nur "gute Ratschläge", wie man mit Kunden und Lücken und ähnlichem besser umgehen könnte. Aber das ist eben doch noch eine andere Qualität, ob man vom Hersteller von (durchaus hochpreisigen, verglichen mit anderen Produzenten) erworbenen Geräten bestimmte Leistungen "erwartet" oder zumindest mal aufschreibt und begründet, warum diese vielleicht besser wären als der Ist-Zustand oder ob man jemandem, der überwiegend in seiner Freizeit hier versucht anderen zu helfen oder Informationen zu teilen, die diesen vielleicht doch nützlich sein könnten, versucht zu erklären, was er alles falsch macht und wieviel besser man das doch selbst machen würde bzw. daß man selbst es besser fände, wenn er es so oder so und eben nicht so (wie bisher) handhaben würde.

Nicht nur, daß man damit immer aus dem eigenen Blickwinkel abstrahiert und offensichtlich der Ansicht ist, alle anderen würden diese Einschätzung schon entsprechend teilen (und wenn nicht, ist es auch egal, Hauptsache es entspricht den eigenen Vorlieben) - es "entwertet" auch parallel immer das tatsächlich "Angebotene" und die dahinein bereits investierte Arbeit.

Wenn mir jemand auf den Hinweis, daß ich das irgendwo hier im IPPF schon beschrieben habe, einfach nur antwortet, das würde ihm jetzt aber gar nicht weiterhelfen und ich solle das gefälligst so schreiben, daß auch er es verstehen könne, dann stelle ich mir schon die Frage, warum das (a) so ist (war ich tatsächlich so wenig hilfreich oder ist er vielleicht auch nur schlicht zu dumm - oder hat er die falsche Brille auf, um (m)einen Wink mit dem Zaunfeld zu verstehen) oder ob der (b) schlicht nur die falsche "Anspruchshaltung" entwickelt hat und offenbar gar nicht mehr in der Lage ist, den Schuß zu hören und den Unterschied zwischen einem Board wie diesem und dem (bezahlten) Support irgendeines Herstellers zu begreifen.

EDIT:
Ich verstehe auch die "Annahme" nicht, es würde sich irgendetwas ändern (und aus 10 Suchverweigerern würden nur noch zwei), wenn ich das irgendwie anders oder woanders beschreiben würde. Ich kann die Probleme von @Chatty mit der Suche einfach nicht nachvollziehen - eine Haltung "Ich weiß doch gar nicht, wonach ich genau suchen soll, also lasse ich es gleich ganz." leuchtet mir nicht so richtig ein und ich kann mich nicht erinnern, daß ich schon mal jemanden auf die Suche verwiesen hätte, ohne parallel weitere Hinweise zu geben, sofern der tatsächlich noch nicht die richtigen "Stichworte" kannte.

Aber wir hatten eben auch schon den Fall, daß jemand zwar wunderschön seine "Frage" in den Titel eines neuen IPPF-Threads schreiben konnte, aber ganz offensichtlich nicht in der Lage war, genau dieselben Worte in das Suchfeld seiner favorisierten Suchmaschine einzugeben und dann auch noch (kackdreist - um es mal ganz deutlich zu schreiben) das genaue Gegenteil davon behauptet und hinterher rumheult, wie böse man doch zu ihm/ihr wäre, wenn man das einfach mal "beweist".

Um das mal ganz deutlich zu schreiben ... alles, was unterhalb von einer Stunde (ernsthafter) Internet-Recherche gefunden wird, ist für mich "leicht zugänglich". Danach kann man dann gerne mal darüber nachdenken, ob die Frage, wie man nun eine Export-Datei einer FRITZ!Box ändern könnte, tatsächlich einen längeren Recherche-Zeitraum braucht oder ob "der Sucher" vielleicht doch etwas falsch machen könnte.

Aber ein: "Das sind aber so viele Ergebnisse." ist so ziemlich die dämlichste Aussage, die man in diesem Zusammenhang als "Entschuldigung" vorbringen kann ... denn eine weitere Antwort desselben Inhalts macht das eben für andere nicht wirklich besser - höchstens für einen selbst.

Wenn es zuviele Treffer sind, muß man sich eben weiter "herantasten" ... was denken denn manche Leute, wie man so eine Suche tatsächlich (und zwar "fachlich richtig") ausführt? Das sind dann wahrscheinlich diejenigen, die in der Ergebnisseite einer Suchmaschine gleich bei den Werbe-Ergebnissen mit dem Lesen anfangen und alles, was sie in den ersten fünf Beiträgen nicht als Antwort gefunden haben, als "nicht vorhanden" einstufen.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: peterman
Sachlich richtig und mit passender (das meint auch: "nachvollziehbarer") Begründung? Ja. (Beispiel: https://github.com/PeterPawn/YourFritz/pull/13)

Solltest Du das aber in die paar Zeilen quetschen wollen, die für die (einzeilige) Anzeige des Namens eines Patches und (bei Abfrage, ob er angewendet werden soll) die "Zustimmung" durch den Benutzer vorgesehen sind (das muß der dann nämlich innerhalb der Konsolen-Ausgaben von "modfs" zum Fortschritt auch noch erkennen und verstehen können - daher sind hier 3-4 Zeilen für mich auch das Maximum und daran habe ich mich bisher nicht nur deshalb gehalten, weil ich das nicht auch länger hinbekommen hätte - ich habe m.W. kein Skript, was da mehr als zwei Zeilen verwendet), dann wäre es vielleicht schade um die Arbeit, wenn Dir ggf. nicht alle "Sachzwänge" (bzw. "Formerfordernisse") im Zusammenhang mit der Verarbeitung dieser Skript-Dateien durch "modfs" bewußt sind - also bitte vorher klären oder nachlesen.

Wenn Du das in Kommentare am oder nach dem Ende des Headers schreiben möchtest (der Aufbau ist eben "grob" vorgegeben, Informationen dazu gibt es irgendwo in der ganz alten README-Datei, die ich dann rausgeworfen habe, weil mir die Zeit zum Aktualisieren der Infos einfach fehlte - aber in der Historie findet man die garantiert noch im "modfs"-Repo), dann bitte ... aber wie gesagt, sachlich richtig wäre nett.

Und ich habe den Namen dieses Patches nicht umsonst genau so auch gewählt, wie er sich im Moment darstellt ... das ist kein Patch, der einfach nur die Telefoncodes wieder nutzbar macht. Der Knackpunkt (und auch ein potentieller Angriffspunkt, wenn man das "nur" zur Reaktivierung der Telefon-Codes verwendet, die bisher gar nicht notwendig war) ist die Abarbeitung der Befehle in der "/var/flash/calllog" bei jedem eingehenden Anruf ... die weiterhin funktionierenden Telefon-Codes sind nur ein "Nebenkriegsschauplatz" bzw. eine (willkommene oder unwillkommene, das muß jeder selbst entscheiden) Nebenwirkung.

Das kann/darf also auch kein Patch "Telnet wieder über Telefon-Codes ein- und ausschalten" werden, der auf die Nebenwirkungen (der anderen "privaten Funktionen") gar nicht weiter eingeht. Im Gegensatz zum Reaktivieren der Telefon-Codes (die auch nur dann funktionieren, wenn parallel der "telnetd"-Symlink wieder eingerichtet wird - es müssen also zwei Patches "zusammenwirken", damit Telnet darüber ein- und ausgeschaltet werden kann und der Umstand, daß Telnet überhaupt zur Verfügung steht und damit eine Gefahr darstellen kann, ist die direkte Folge des einen Patches und keine unerwünschte/unerwartete Nebenwirkung eines anderen) besteht bei der Datei nämlich eine echte Gefahr, daß sie von jemandem mißbraucht wird, wenn der Benutzer über den Umstand nicht informiert ist, daß damit auch die "calllog" wieder reaktiviert wird.

Daß damit nicht auch andere alte Lücken automatisch (und ohne Ahnung des Benutzers) aufgerissen werden (z.B. die Ausführung von /var/fhemcmd nach Eingabe von #95*1* bzw. #95*2*), hatte ich tatsächlich vorher (im Rahmen meiner Möglichkeiten, die sich in erster Linie auf die Analyse der Zeichenketten in der Binärdatei und darauf aufbauende Tests stützen) schon abgeklärt - sonst hätte ich den Patch (zumindest in dieser Form) nicht ins "Angebot" übernommen.

Was will ich damit sagen? Ich hatte/habe mir tatsächlich etwas dabei gedacht, als ich diesen Patch explizit als "Reaktivieren von "calllog"" beschrieben habe und nicht nur als "Aktivieren der "privaten Funktionen" im "telefon"-Daemon" (wo dann kein Aas weiß, was diese alles umfassen würden). Ich schreibe das hier nur schon vorher auf, damit Du nicht hinterher von diesen Argumenten "überrascht" wirst (bisher gab es keinen Grund, diese Überlegungen zu veröffentlichen) - nur für den Fall, daß Dein Vorschlag am Ende den eigentlichen Inhalt dieses "modscripts" (so, wie er sich aus meinen Absichten ergibt) irgendwie "umdrehen" will ... ich habe eben (fast) keine Idee, wie Du Dir das vorstellst bzw. ich bin auf die Begründung, warum das dann in einem Shell-Skript leichter gefunden werden kann als in einem IPPF-Beitrag, schon sehr gespannt.

Der Patch (bzw. das "modscript" mit diesem Patch) ist ja auch noch ziemlich neu, obwohl die "Entdeckung", daß im "private mode" (der - nur nebenbei - auch bei jeder Inhouse-Version automatisch aktiv ist, das heißt dann im Klartext, daß diese Funktionen dort auch verfügbar sind und nur dadurch habe ich die überhaupt "wiedergefunden" beim Testen) noch einige der alten Funktionen vorhanden sind, ja schon deutlich älter ist (inzwischen über ein halbes Jahr alt, wie man hier: https://www.ip-phone-forum.de/threa...das-lange-leben-der-var-flash-calllog.299002/ nachlesen kann).

Daß diese "privaten Funktionen" inzwischen jetzt auch die (De-)Aktivierung des Telnet-Daemons über Telefon-Codes umfassen und es ohne nicht länger funktioniert, ist ja ebenfalls "neu" ... denn zuvor ging das auch ohne "CONFIG_RELEASE=0" noch einigermaßen reibungslos (wenn ich mich richtig erinnere) - wobei ich zugegebenermaßen schon seit > 1 Jahr selbst fast nur noch mit Firmware mit diesen "privaten Funktionen" arbeite, auch wenn ich keine Inhouse-Versionen verwende und deshalb immer erst gesoindert testen muß, ob das nun an "private" liegt oder nicht, was ich da finde.
 
Zuletzt bearbeitet:
Hallo zusammen,
ich habe versucht bei meiner 7490 von 6.93 auf 7.01 zu gehen.
Das habe ich auch erfolgreich gemacht, aber openVPN crasht und die Box restartet.
Das passiert immer wenn von aussen eine verbindung aufgebaut wird.
Umgeschaltet auf 6.93 und es funktioniert sofort fehlerfrei.
Ich habe auch ein neues openVPN binary mit Freetz erstellt, hilft aber nicht. 6.93 OK, 7.01 restart.

Hat hier jemand eine Idee?
Code:
[  130.520000][0][0]system-load 7 loadavg 2.12 1.6 0.41 - 127 tasks:57 % curr:upnpd(38 %)max:upnpd(38 %, pid:2831) pgstat: sum=63147 free=21453 slab=4943 alloc=78/s fault=30/s (sleep 1)
[  140.650000][0][0]system-load 9 loadavg 2.3 1.7 0.42 - 128 tasks:82 % curr:upnpd(70 %)max:upnpd(70 %, pid:2831) pgstat: sum=63105 free=21322 slab=4962 alloc=97/s fault=105/s ai_sys:1.20/s 0x817ad0e4 mac_hash_func+0x4/0x20 [userman_mod]  (sleep 1)
[  152.620000][0][0]system-load 6 loadavg 1.94 1.9 0.43 - 128 tasks:72 % curr:upnpd(64 %)max:upnpd(64 %, pid:2831) pgstat: sum=63205 free=21442 slab=4952 alloc=50/s fault=23/s ai_sys:0.81/s 0x817ad0e4 mac_hash_func+0x4/0x20 [userman_mod]  (sleep 1)
[  331.430000][0]AVM_WATCHDOG_release(hdl=2 mobiled): success
[  526.400000][0][kernel-trap] pc=0x804eea28(0x804eea28 __netif_receive_skb+0x8/0xa0) addr=0x807e0000 task=openvpn pid=3358 ra=0x804efdbc(0x804efdbc process_backlog+0xbc/0x220)
[  526.400000][0]Code(0x804eea20): 0x00801021 0x8c830010 <0x00030336> 0x3c03809c 0x8c630480
[  526.400000][0]set_reboot_status: Soft-Reboot(KCRASH)  -  KCRASH(1) SUM(1)
[  526.400000][0]BUG_ON((unsigned long)(skb->sk)) at function '__netif_receive_skb' line: 3706 file: net/core/dev.c
[  526.400000][0]Kernel bug detected[#1]:
[  526.400000][0]CPU: 0 PID: 3358 Comm: openvpn Tainted: P           O 3.10.107 #1
[  526.410000][0]task: 8fd7d6d0 ti: 8d8f8000 task.ti: 8d8f8000
[  526.410000][0]$ 0   : 00000000 00000000 8ec73d60 8ecc9e00
[  526.420000][0]$ 4   : 8ec73d60 00000001 8091cae0 5bae5258
[  526.420000][0]$ 8   : ffffffe2 0000000c 000199fe 0200a701
[  526.430000][0]$12   : ffffffff 8a71ca8a 00000000 7069626c
[  526.430000][0]$16   : 81915c58 00000001 81915bf4 81915c54
[  526.440000][0]$20   : 81915c48 00000200 00000100 00000000
[  526.440000][0]$24   : 00000000 004cd8e0                 
[  526.450000][0]$28   : 8d8f8000 8d8fbc20 00005872 804efdbc
[  526.450000][0]Hi    : 00000008
[  526.460000][0]Lo    : cccccccf
[  526.460000][0]ac1Hi: 00000000 ac1Lo: 00000000
[  526.460000][0]ac2Hi: 00000000 ac2Lo: 00000000
[  526.470000][0]ac3Hi: 00000000 ac3Lo: 00000000
[  526.470000][0]dspcontrol: 00000000
[  526.480000][0]Status: 1100ff03    KERNEL EXL IE
[  526.480000][0]Cause : 10800034 exc_code:13
[  526.480000][0]epc   : 804eea28 0x804eea28 __netif_receive_skb+0x8/0xa0
[  526.490000][0]ra    : 804efdbc 0x804efdbc process_backlog+0xbc/0x220
[  526.500000][0]    Tainted: P           O
[  526.500000][0]PrId  : 00019556 (MIPS 34Kc)
[  526.510000][0]Classified pointer on registers:
[  526.510000][0] $ 2 : 8ec73d60 [slab: type:skbuff_head_cache size:448 start:0x8ec73d60+0x0 allocated by:0x804decc0 __alloc_skb+0x60/0x1a0]
[  526.520000][0] $ 3 : 8ecc9e00 [slab: type:kmalloc-512 size:512 start:0x8ecc9e00+0x0 allocated by:0x804d64e8 sk_prot_alloc+0xc8/0x1a0]
[  526.530000][0] $ 4 : 8ec73d60 [slab: type:skbuff_head_cache size:448 start:0x8ec73d60+0x0 allocated by:0x804decc0 __alloc_skb+0x60/0x1a0]
[  526.550000][0] $ 6 : 8091cae0 irq_stat+0x0/0x40
[  526.550000][0] $13 : 8a71ca8a [slab: type:kmalloc-512 size:512 start:0x8a71ca00+0x8a allocated by:0x804debd8 __kmalloc_reserve.isra.3+0x38/0xc0]
[  526.560000][0] $16 : 81915c58 [page: type:reserved]
[  526.570000][0] $18 : 81915bf4 [page: type:reserved]
[  526.570000][0] $19 : 81915c54 [page: type:reserved]
[  526.580000][0] $20 : 81915c48 [page: type:reserved]
[  526.580000][0] $28 : 8d8f8000 [threadinfo(openvpn): 8d8f8000+0x0]
[  526.590000][0] $29 : 8d8fbc20 [stack(openvpn): 8d8f8000+0x3c20]
[  526.600000][0] $31 : 804efdbc process_backlog+0xbc/0x220
[  526.600000][0]Modules linked in: ifx_ppa_mini_qos(P) ifx_ppa_mini_sessions ifxmips_ppa_hal_vr9_e5 ltq_eth_oam_handler krtp(PO) userman_mod(PO) sch_fq_codel sch_llq sch_tbf kdsldmod(PO) cprocfsmod(PO) dect_io(P) avm_dect(P) capi_codec(P) isdn_fbox_fon5(P) pcmlink(P) usb_storage sd_mod scsi_mod ifxmips_ppa_datapath_vr9_e5 dsl_vr9(O) mei_vr9(O) avm_fiber_if(PO) xhci_hcd usbcore usb_common Piglet_noemif(P) rtc_avm led_modul_Fritz_Box_HW185(PO)
[  526.640000][0]Process openvpn (pid: 3358, threadinfo=8d8f8000, task=8fd7d6d0, tls=77005460)
[  526.650000][0]Stack : 00000001 804decc0 808f9588 809b0000 00000000 81915c58 81915be0 807a3200
[  526.650000][0]      808a0000 807e0000 00000040 81915be8 0000012c 804efc30 8fc08140 8ec73d60
[  526.650000][0]      8d8fbca8 000004d0 8fd172c0 804debd8 807e5f4c 807d8640 808f9404 00000100
[  526.650000][0]      0000000c 809b2e40 00000003 00000000 807d864c 800539e4 00000077 80557a14
[  526.650000][0]      8a5d2b00 8d8fbd00 8d8fbe88 8a58e420 808f9588 809b0000 00000000 8091cae0
[  526.650000][0]      ...
[  526.680000][0]Classified pointer on stack:
[  526.690000][0]804decc0 __alloc_skb+0x60/0x1a0
[  526.690000][0]808f9588 kstat+0x0/0x30
[  526.700000][0]809b0000 avm_memory_statistic+0x2b30/0x4058
[  526.700000][0]81915c58 [page: type:reserved]
[  526.710000][0]81915be0 [page: type:reserved]
[  526.710000][0]807a3200 __func__.4157+0x125410/0x132950
[  526.710000][0]808a0000 descriptor.22867+0x0/0x18
[  526.720000][0]807e0000 crc32ctable_le+0x6c0/0x2000
[  526.720000][0]81915be8 [page: type:reserved]
[  526.730000][0]804efc30 net_rx_action+0x190/0x260
[  526.730000][0]8fc08140 [slab: type:kmalloc-256 size:256 start:0x8fc08140+0x0]
[  526.740000][0]8ec73d60 [slab: type:skbuff_head_cache size:448 start:0x8ec73d60+0x0 allocated by:0x804decc0 __alloc_skb+0x60/0x1a0]
[  526.750000][0]8d8fbca8 [stack(openvpn): 8d8f8000+0x3ca8]
[  526.760000][0]8fd172c0 [slab: type:kmem_cache size:128 start:0x8fd172c0+0x0]
[  526.760000][0]804debd8 __kmalloc_reserve.isra.3+0x38/0xc0
[  526.770000][0]807e5f4c __per_cpu_offset+0x0/0x8
[  526.770000][0]807d8640 softirq_vec+0x0/0x40
[  526.780000][0]808f9404 actual_skb_cache+0x0/0x4
[  526.780000][0]809b2e40 simple_profiling+0x0/0x20
[  526.790000][0]807d864c softirq_vec+0xc/0x40
[  526.790000][0]800539e4 __do_softirq+0x184/0x300
[  526.800000][0]80557a14 tcp_recvmsg+0x3d4/0xba0
[  526.800000][0]8a5d2b00 [slab: type:TCP size:1216 start:0x8a5d2b00+0x0 allocated by:0x804d6468 sk_prot_alloc+0x48/0x1a0]
[  526.810000][0]8d8fbd00 [stack(openvpn): 8d8f8000+0x3d00]
[  526.820000][0]8d8fbe88 [stack(openvpn): 8d8f8000+0x3e88]
[  526.820000][0]8a58e420 [slab: type:kmalloc-8192 size:8192 start:0x8a58e000+0x420 allocated by:0x804eff8c alloc_netdev_mqs+0x6c/0x380]
[  526.830000][0][0]system-load 3 loadavg 1.9 1.6 0.64 - 123 tasks:2 % curr:openvpn(0 %)max:upnpd(0 %, pid:2831) pgstat: sum=63196 free=21561 slab=4882 alloc=17/s fault=18/s ai_sys:30.32/min 0x817ad0e4 mac_hash_func+0x4/0x20 [userman_mo ai_user:0.64/min 0x00428734 multid (sleep 1)
[  526.860000][0]8091cae0 irq_stat+0x0/0x40
[  526.860000][0]Call Trace:
[  526.860000][0]3c20: [<804eea28>] 0x804eea28 __netif_receive_skb+0x8/0xa0
[  526.870000][0]3c20: [<804efdbc>] 0x804efdbc process_backlog+0xbc/0x220
[  526.880000][0]3c58: [<804efc30>] 0x804efc30 net_rx_action+0x190/0x260
[  526.880000][0]3c98: [<800539e4>] 0x800539e4 __do_softirq+0x184/0x300
[  526.890000][0]3cf8: [<80053c68>] 0x80053c68 do_softirq.part.1+0x68/0xa0
[  526.900000][0]3d10: [<804ee8d4>] 0x804ee8d4 netif_rx_ni+0x34/0x60
[  526.900000][0]3d30: [<8047077c>] 0x8047077c tun_get_user+0x8fc/0xce0
[  526.910000][0]3de8: [<80471130>] 0x80471130 tun_chr_aio_write+0x70/0xa0
[  526.920000][0]3e10: [<80123568>] 0x80123568 do_sync_write+0x88/0x100
[  526.920000][0]3ea8: [<80124200>] 0x80124200 vfs_write+0xc0/0x280
[  526.930000][0]3ed8: [<80124ad8>] 0x80124ad8 SyS_write+0x58/0x100
[  526.930000][0]3f10: [<800048b0>] 0x800048b0 stack_done+0x20/0x40
[  526.940000][0]
[  526.940000][0]
[  526.940000][0]Code: 00000000  00801021  8c830010 <00030336> 3c03809c  8c630480  5460000a  8c830084  00002821
[  526.950000][0]CPU_ID=1 TC1 ----- (LINUX)
[  526.960000][0]Status:  1100c700 KERNEL
[  526.960000][0]current: swapper/1 (pid: 0, threadinfo=8fc84000, task=8fc60000, sp=8fc87ec8 tls=0x00000000)
[  526.970000][0]Call Trace:
[  526.970000][0]3ec8: [<8001edc0>] 0x8001edc0 r4k_wait_irqoff+0x20/0x34
[  526.980000][0]3ee0: [<80094060>] 0x80094060 cpu_startup_entry+0x180/0x1e0
[  526.980000][0]3f10: [<80090260>] 0x80090260 dequeue_rt_stack+0x2a0/0x4c0
[  526.990000][0]
[  526.990000][0]YIELD-TC2 -----
[  527.000000][0]current: CPU1YTC2 (pid: 0, threadinfo=8fcc4000, task=8fcc0018, sp=8fcc7ec8 tls=0x00000000)
[  527.010000][0]Call Trace:
[  527.010000][0]3ec8: [<80028e08>] 0x80028e08 yield_context_thread+0x1c8/0x380
[  527.020000][0]3f10: [<800290dc>] 0x800290dc proc_tc_prio_write+0xfc/0x200
[  527.020000][0]
[  527.020000][0]YIELD-TC3 -----
[  527.030000][0]current: CPU0YTC3 (pid: 0, threadinfo=8fcd4000, task=8fcd0018, sp=8fcd7ec8 tls=0x00000000)
[  527.040000][0]Call Trace:
[  527.040000][0]3ec8: [<80028e08>] 0x80028e08 yield_context_thread+0x1c8/0x380
[  527.050000][0]3f10: [<800290dc>] 0x800290dc proc_tc_prio_write+0xfc/0x200
[  527.050000][0]
[  527.050000][0]---[ end trace b14c1d1a065a9c04 ]---

Gruß Remoter3406
 
Ist ein bekanntes Problem mit dem tun Modul. Es gibt mehrere Beiträge hier im Forum zu diesem Thema oder dieses Ticket: 2979
 
Die Beiträge hier im Forum habe ich nicht gefunden.
Vielen Danke für die Info.
 
Ich habe eine Weile gezögert, ob ich die VPN-Anzeige für die 07.0x-Versionen noch anpasse oder nicht ... nachdem ich dann aber so etwas gesehen hatte:
Screenshot_2018-10-01 FB7490.png
, war die Entscheidung klar.

Ich habe also das Skript "mod_show_vpn_on_overview" noch einmal an die 07.0x angepaßt und dabei gleich die komplette "Integration" von "patch" auf "sed" geändert.

Es gibt noch kein neues tar-File auf yourfritz.de - aber einen korrespondierenden Patch "mod_remove_avm_vpn_from_overview" im Repository, mit dem man die AVM-Einträge entfernen kann.

Ich hatte damals ja extra etwas mehr an Code investiert, um die Anzeige nicht zu lang werden zu lassen ... schon eine vierköpfige Familie mit je einem Smartphone und einem Tablet mit eigener VPN-Verbindung bringt da acht Verbindungen in die Anzeige ein - aufs Scrollen habe ich in der Übersicht aber keine Lust und Zoomen hilft hier (dank "responsive design") auch nicht weiter.

Ich will die Ausgabe noch als Alternative in Englisch anbieten, daher ändert sich das Skript auch noch einmal ... mal sehen, ob ich morgen dazu komme.
 
Es wäre schön wenn nur die gerade aktiven VPN Verbindungen auf der Übersichtsseite angezeigt werden würden und eine Möglichkeit für gar keine Anzeige.
 
Gar keine Anzeige (allerdings nicht "dynamisch", also nach Lust und Laune des Benutzers, sondern tatsächlich dauerhaft entsorgt) kriegt man mit dem Patch zum Entfernen der AVM-Anzeige (mod_remove_avm_...irgendwas).

Meine "Zusammenfassung" zeigt hingegen tatsächlich verbundene VPN-Clients einzeln (mit Namen) an und ansonsten eben nur die entsprechende Anzahl von Verbindungen im jeweiligen Status (de-/aktiviert), damit die Liste nicht so "ausfranst".

Die Notwendigkeit, die AVM-Anzeige (die alle aktivierten Verbindungen berücksichtigt und jeweils per "LED" anzeigt, ob die verbunden sind oder nicht) auf die tatsächlich aktiven zu beschränken (anstelle meiner Zusammenfassung, die ja auch schon für Versionen funktioniert, wo AVM das nicht mit angezeigt hat - eben vor 07.0x), sehe ich nicht so richtig ... meine Version zeigt eine graue LED, solange keine Verbindung besteht (und dann eben auch keine Namen für die verbundenen Clients - das ist der einzige Unterschied, den ich sehe, aber der wäre bei "gerade nicht aktive Verbindungen nicht anzeigen" ja auch vorhanden) und sowie mind. ein Client verbunden ist, eine grüne ... zusammen mit den Namen der verbundenen Clients - halt nicht jeder Client mit einer eigenen "LED".

Wer will, könnte auch die AVM-Version und meine parallel betreiben (der Namenskonflikt hinsichtlich "vpn" war die eigentliche Ursache dafür, daß der Patch nicht mehr funktionierte ab Labor 06.98 - ich bin jetzt auf "vpnconn" ausgewichen) ... ob das aber Sinn macht, weiß ich nicht so genau.

EDIT:
Noch mal zur Erinnerung, welchen "Status" so eine Verbindung bei mir annehmen kann:
  • deaktiviert: Verbindung ist vorhanden, aber die Checkbox ist in der Liste der VPN-Verbindungen nicht selektiert und die Verbindung kann nicht aufgebaut werden
  • aktiviert: Verbindung ist vorhanden, Checkbox ist selektiert, Verbindung ist aber nicht aufgebaut
  • aktiv/verbunden: der Tunnel zur Gegenseite ist aufgebaut
 
Danke für die Info.
Habe mich falsch ausgedrückt. Ich meinte natürlich verbunden.
Wenn das so funktioniert wie oben beschrieben ist es doch super.
Ist die VPN Modifikation noch in Bearbeitung oder fertig? Ich warte sonst noch.
Danke für ihre tolle Arbeit.
 
Kleinen Moment würde ich noch warten ... eine neue Version (nach wie vor als Beta) kommt innerhalb der nächsten Stunde. Im Moment klappt die (automatische) Auswahl von zusätzlich in das "wrapper"-Verzeichnis zu kopierenden Dateien anhand der Kernel-Version des Zielsystems(!) noch nicht - aber das dauert nicht mehr lange.

Die nächste Änderung wird dann die Umstellung auf die neue Version des Boot-Managers sein ... der harrt ja auch schon mehr als 7 Monate seiner Integration und bisher war noch nicht so richtig klar, wie ich die Unterscheidung zwischen Boxen machen sollte, bei denen das Branding sich ändern läßt und denen, wo das nicht (mehr) geht - aber da habe ich (dank eines Dumps eines neuen Bootloaders, der mir inzwischen zur Verfügung steht) zumindest mal eine Idee, die halt jetzt noch getestet werden muß.

Da ich mir heute explizit Zeit für "modfs" genommen habe, könnte das vielleicht noch etwas werden ... wer also den neueren Boot-Manager verwenden will (bei Freetz ist diese Version inzwischen dabei - sie erkennt nicht nur das zur Änderung der Firmware verwendete Framework, sie soll auch die Option zum Ändern des Brandings bei den Boxen ausblenden, wo das ohnehin nicht klappt), der sollte noch abwarten.


Ich habe jetzt (nochmals, die erste gab es schon heute nachmittag) eine neue Version auf yourfritz.de ablegt.

Diese enthält drei neue Modifikationen:
  • mod_no_tainted_message - entfernt die Anzeige von "Vom Hersteller nicht unterstützte Änderungen" von der Übersichtsseite, das eigentliche Flag, in dem diese Änderung vermerkt wurde, wird davon aber nicht zurückgesetzt
  • mod_fixed_branding_avm - stellt fest das "export OEM=avm" in der "rc.conf" ein, womit man auch bei Boxen, wo der Bootloader die Änderung von "firmware_version" ignoriert, auf das "avm"-Branding umstellen kann, wenn die Box eigentlich ein anderes hätte
  • mod_multi_annex - entfernt die Einstellung "CONFIG_DSL_MULTI_ANNEX=n", die normalerweise in der deutschen Firmware gesetzt wird und die Auswahlmöglichkeit für die DSL-Variante in den Einstellungen ausblendet ... mit dem Patch sieht das dann so aus:
select_annex.PNG

Jetzt kommt aber wirklich vor dem Boot-Manager nichts weiteres mehr (das wird vielleicht doch eher Wochenende, bevor es fertig und getestet ist) ... ich brauchte bloß das "mod_fixed_branding_avm" noch, um auch in diesem Falle den Wechsel des Brandings beim Boot-Manager zu unterdrücken.
 
@PeterPawn
Habe gerade die 0.5Beta heruntergeladen, es kommt folgende Fehlermeldung beim Start auf einer 7490:
# ./modfs update

./modfs: line 2701: /var/media/ftp/mod/bin/185/busybox: not found

respawn script with custom BusyBox shell, SHLVL=4

/var/media/ftp/mod/bin/185/busybox sh ./modfs update

./modfs: line 2701: /var/media/ftp/mod/bin/185/busybox: not found
 
Keine Ahnung, was da passiert ist ... ich habe das gerade zur Kontrolle vom Server geladen und nach /var/mod auf einer 7490 entpackt.

Danach sieht das so aus:
Code:
root@FB7490:/var $ ls -la /var/mod/bin/185/
drwxr-xr-x    2 1000     1001           220 Oct  4 17:21 .
drwxrwxr-x    9 1000     1001           440 Oct  4 17:21 ..
lrwxrwxrwx    1 root     root            30 Oct  4 17:21 busybox -> ../common/busybox.34kc.3.10.73
lrwxrwxrwx    1 root     root            37 Oct  4 17:21 busybox.config -> ../common/busybox.config.34kc.3.10.73
lrwxrwxrwx    1 root     root            29 Oct  4 17:21 e2fsck -> ../common/e2fsck.34kc.3.10.73
lrwxrwxrwx    1 root     root            29 Oct  4 17:21 mke2fs -> ../common/mke2fs.34kc.3.10.73
lrwxrwxrwx    1 root     root            34 Oct  4 17:21 mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.73
lrwxrwxrwx    1 root     root            34 Oct  4 17:21 mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.73
lrwxrwxrwx    1 root     root            30 Oct  4 17:21 openssl -> ../common/openssl.34kc.3.10.73
lrwxrwxrwx    1 root     root            33 Oct  4 17:21 unsquashfs3 -> ../common/unsquashfs.34kc.3.10.73
lrwxrwxrwx    1 root     root            33 Oct  4 17:21 unsquashfs4 -> ../common/unsquashfs.34kc.3.10.73
root@FB7490:/var $
und die verlinkten Binärdateien existieren auch in der Verzeichnisstruktur, hier der Aufruf der Busybox:
Code:
root@FB7490:/var $ /var/mod/bin/185/busybox
BusyBox v1.27.2 multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

  BusyBox is a multi-call binary that combines many common Unix
  utilities into a single executable.  The shell in this build
  is configured to run built-in utilities without $PATH search.
  You don't need to install a link to busybox for each utility.
  To run external program, use full path (/sbin/ip instead of ip).

Currently defined functions:
  [, [[, addgroup, adduser, arp, arping, ash, awk, base64, basename, bbconfig, blkid, blockdev, brctl, bunzip2, bzcat, bzip2, cat, chat, chgrp, chmod, chown, chpst, chroot, cksum, clear, cmp, comm, conspy, cp, cpio, crond,
  crontab, cryptpw, cut, date, dd, delgroup, deluser, depmod, devmem, df, dhcprelay, diff, dirname, dmesg, dnsd, dnsdomainname, dos2unix, dpkg, dpkg-deb, du, dumpleases, echo, egrep, env, envdir, envuidgid, ether-wake, expand,
  expr, factor, fallocate, false, fatattr, fdisk, fgconsole, fgrep, find, findfs, flash_eraseall, flash_lock, flash_unlock, flashcp, flock, fold, free, freeramdisk, fsck, fsync, ftpd, ftpget, ftpput, fuser, getopt, grep, groups,
  gunzip, gzip, halt, hd, hdparm, head, hexdump, hostid, hostname, httpd, i2cdetect, i2cdump, i2cget, i2cset, id, ifconfig, ifdown, ifenslave, ifplugd, ifup, inetd, init, inotifyd, insmod, install, iostat, ip, ipaddr, ipcalc,
  ipcrm, ipcs, iplink, ipneigh, iproute, iprule, iptunnel, kill, killall, killall5, klogd, less, ln, logger, login, logname, logread, losetup, ls, lsmod, lsof, lspci, lsusb, lzma, makedevs, makemime, md5sum, microcom, mkdir,
  mkdosfs, mkfifo, mkfs.vfat, mknod, mkpasswd, mkswap, mktemp, modinfo, modprobe, more, mount, mountpoint, mpstat, mv, nanddump, nandwrite, nbd-client, nc, netstat, nice, nl, nmeter, nohup, nproc, nslookup, ntpd, od, openvt,
  partprobe, passwd, paste, patch, pgrep, pidof, ping, ping6, pipe_progress, pivot_root, pkill, pmap, poweroff, printenv, printf, ps, pscan, pstree, pwd, pwdx, rdate, rdev, readlink, realpath, reboot, reformime, renice, reset,
  rev, rm, rmdir, rmmod, route, rpm, rpm2cpio, run-parts, runsv, runsvdir, rx, sed, sendmail, seq, setconsole, setlogcons, setpriv, setserial, setsid, setuidgid, sh, sha1sum, sha256sum, sha3sum, sha512sum, shuf, slattach, sleep,
  smemcap, softlimit, sort, split, ssl_client, start-stop-daemon, stat, strings, stty, stun-ip, sum, sv, svc, svlogd, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd,
  test, tftp, tftpd, time, timeout, top, touch, tr, traceroute, traceroute6, true, truncate, tty, tunctl, tune2fs, ubiattach, ubidetach, ubimkvol, ubirename, ubirmvol, ubirsvol, ubiupdatevol, udhcpc, udhcpc6, udhcpd, udpsvd,
  uevent, umount, uname, unexpand, uniq, unix2dos, unlink, unlzma, unshare, unxz, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, watch, watchdog, wc, wget, which, whois, xargs, xxd, xzcat, yes, zcat, zcip
root@FB7490:/var $
Ich würde also erst einmal behaupten, daß das Archiv in Ordnung ist ... da mußt Du halt mal direkt nachsehen, warum die Datei bei Dir nicht gefunden wird. Ein denkbarer Tipp wäre zu wenig Platz am Ort des Auspackens (und eine nicht richtig beachtete Fehlermeldung, denn die sollte eigentlich dann erscheinen) ... durch die Dateien für die neue Kernel-Version sind das jetzt fast 12 MB entpackt.
 
@PeterPawn
Gerade nochmal geladen, entpackt, und geht jetzt einwandfrei.
Seltsam...
Danke dir auch ganz herzlich für deine Entwicklungsarbeit, und die prompte Antwort
 
Doch noch eine neuere Zwischenversion mit folgenden Änderungen (genaueres halt im Repo in den Commits nachzulesen):
  • Anpassung der Protokollierung an das neue Ringbuffer-Format bei AVM - damit sollten die "Bus error"-Meldungen, die vom "showshringbuf" ausgingen, Geschichte sein (die waren der eigentliche Anlaß für die zusätzliche Version)
  • "mod_fixed_branding" sucht sich jetzt das passende "avm(e)"-Branding für das Zielsystem selbst (d.h., wenn das ein internationales Image ist als Vorlage, wird "export OEM=avme" gesetzt) - wer das überschreiben will und ein anderes "forcieren" möchte, der kann die Variable MOD_FIXED_BRANDING_VALUE passend setzen (eine Kontrolle, ob das Branding auch im Image ist, findet nicht statt)
  • die Anzeige wurde etwas überarbeitet und mit ein paar mehr Hervorhebungen versehen, außerdem werden jetzt die Nachrichten aus den "modscripts" auch angezeigt
  • bei optionalen Änderungen (wo "modfs" zuerst mal nachfragt) wird jetzt zunächst mal geprüft, ob das Skript überhaupt sinnvoll ist für das Zielsystem, ansonsten wird auch die Abfrage gleich übersprungen
yourfritz.de ist geändert, wer von 07.0x aus sein System modifiziert, sollte in jedem Falle die letzte Beta benutzen, damit die Debug-Protokollierung wieder funktioniert - hier hat AVM das Dateiformat geändert und das Anlegen einer (großen) Datei muß etwas anders ablaufen, damit "showshringbuf" sich nicht (dauerhaft) aufhängt.
 
Neue Beta-Version mit der neueren Bootmanager-Version, die schon seit Februar darauf wartet, auch mal in "modfs" Einzug zu halten. Die alte (v0.4) ist noch im Archiv, aber deaktiviert ... wer mit einer eigenen "custom_modscripts" arbeitet, muß entsprechend aufpassen. Änderungen/Korrekturen finden nur noch für die neuere Version statt ... die ist dann (als Nebeneffekt des "Neuschreibens") auch gleich noch weitgehend POSIX-kompatibel - von der verwendeten Syntax her sowieso und auch bei den eingesetzten Kommandos sollte es nichts wirklich Exotisches oder gar "nicht POSIX-kompatibles" geben und diese Bootmanager-Version sollte auch mit der originalen AVM-BusyBox problemlos arbeiten können.

Das Skript im Hintergrund kann jetzt (auch wenn es hier keine Rolle spielt, weil "modfs" sich auf VR9 und AR10 beschränkt) mit VR9, AR10, GRX5 und Puma6 umgehen und dort die Daten zu den Systemen in den beiden Partition-Sets sammeln.

Die Umschaltung des Brandings wird bei den GRX5-Boxen komplett verhindert (auch wenn es ein paar frühe Modelle der 7560 und 7580 geben mag, was das funktioniert) ... wer aber sein System mit dem "fixed branding"-Patch versehen hat (die aktuelle Version erkennt ja auch selbst, ob das "avm" oder "avme" sein sollte für das gerade zu installierende System), der kriegt auch noch das im GUI angezeigt.

Die neue Bootmanager-Version erkennt auch das Framework, das zum Modifizieren des installierten Systems verwendet wurde (YourFritz (kommt später), "modfs" oder Freetz) und zeigt das entsprechend an (eine ältere Implementierung dieser Datei wird in Freetz derzeit auch angeboten zur Integration in das eigene Image) ... aus irgendeinem Grund funktioniert das im Moment aber nicht für ein "festes Branding" über das "export OEM=<value>" in einem Freetz-Image (schaue ich mir bei Gelegenheit noch mal an).

Die Erkennung, welcher Bootloader bei der 7490 (Berichte zu anderen VR9-Boxen mit "nicht änderbarem Branding" habe ich noch nicht gelesen) gerade installiert ist und ob der eine Änderung des Brandings über das Urlader-Environment zuläßt oder nicht, habe ich noch mal verschoben (die fehlt dem Skript ja schon seit Februar und war der eigentliche Grund für die lange Verzögerung) ... ich baue erst mal einen weiteren Patch, der eine Seite zur Anzeige der Daten aus der Finalisierung nachrüstet und dabei auch Angaben zu seiner "Annahme" macht, ob das ein Bootloader mit "festem Branding" ist oder nicht. Erst die Auswertung der Daten aus dieser Seite (von ein paar Nutzern) wird es möglich machen, die Unterscheidung auch wirklich sicher zu treffen.

Im eigentlichen "modfs"-Skript gibt es auch noch eine Änderung, die man kennen sollte ... wenn bei der Frage vor dem Packen mit einem großen "Q" anstelle des kleinen "q" geantwortet wird, dann bleibt das Verzeichnis mit dem modifizierten "rootfs" stehen und wird in "$volume_with_working_directory/modfs_rootdir" umbenannt, wobei das "$volume_with_working_directory" halt das Volume mit dem ausgewählten Arbeitsverzeichnis ist (eigentlich wählt man ja auch das Volume aus und "modfs" erzeugt dann das Verzeichnis mit der Timestamp im Namen).

Will man die Daten später wieder entfernt haben, muß man das selbst tun (mit "rm -r" geht es am besten) - allerdings wird ein bereits vorhandenes Verzeichnis dieses Namens auch gelöscht, bevor das aktuelle Verzeichnis gesichert (bzw. "umbenannt") wird. Eingebaut habe ich das, damit man sich auch hinterher noch direkt vom Inhalt des modifizierten Verzeichnisses überzeugen kann und weil es sich so deutlich besser testen läßt, als wenn man das Skript bei der Frage "dumm rumstehen" lassen muß, während man sich das Ergebnis der Modifikationen anschaut. Jetzt fehlt nur noch die Environment-Variable für ein automatisches "Q", damit man Tests auch wirklich automatisiert ablaufen lassen kann.

Die inaktiven "modscripts" haben jetzt ihr eigenes Unterverzeichnis erhalten (passenderweise heißt das halt auch "inactive") ... wer eines dieser Skript benutzen will, muß es halt vorher in das darüberliegende Verzeichnis kopieren und die Berechtigungen passend setzen - noch mal zur Erinnerung: das x-Flag für die Gruppe besagt, daß es eine Abfrage geben soll, ob die Modifikation gewünscht ist und das x-Flag für "others" bewirkt die automatische Ausführung dieses Patches; die eigene "Auswahl" kann man in einer Datei "custom_modscripts" vorhalten, deren Format hier irgendwo beschrieben ist.

Für das "contrib"-Verzeichnis habe ich auch noch etwas geändert ... dort werden jetzt alle Unterverzeichnisse der ersten Ebene noch nach einem "modscripts"-Verzeichnis durchsucht, in dem sich dann weitere Skript-Dateien befinden können. Damit habe ich dann meine "persönlichen" Skript-Dateien auch durch diesen Mechanismus "aus dem Weg geräumt" und mir ein eigenes Verzeichnis dafür unterhalb von "contrib" angelegt. Wer also ebenfalls "private Patches" hat, kann das genauso machen, so er will.
 
Guten Tag!

Ich habe nun die Beiträge seit dem 15.09.2018 schon mehrfach gelesen und bin trotzdem verwirrt.
Vielleicht mag sich jemand erbarmen und mich in die richtige Richtung schicken, damit ich etwas mehr Erfolg habe als am gestrigen Tag.

Was ist meine Ausganglage?
Firtz Box 7490 - FRITZ!OS 6.93 mit modfs.
Was ist die wichtigste Funktion die ich benötige?
Telnet muss funktionieren. Warum? Ansteuerung und Verwaltung von frewe zum Auslesen der Daten meiner Wetterstation (über USB mit der Fritz Box verbunden) und hochladen der Wetterdaten auf meinen Webserver im Internet.
Bisher war das kein Problem: #96*7* für enable und #97*8* für disable genutzt.

Nach den gestrigen Update-Versuchen (neue modfs.tgz geladen - 06.10.2018 um 07:21 und versucht neu geladenes FRITZ.Box_7490.113.07.01.image von 07:28 Uhr für das Update zu nutzen):
Telnet gestartet... angemeldet... dann:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
und
./modfs update /var/media/ftp/FRITZ.Box_7490.113.07.01.image
funktioniert das Update zwar (dauert ewig - ca. 90 Minuten - aber gut) - und die Box kommt mit 7.01 hoch, aber ich habe keinen Zugriff mehr auf Telnet oder habe hier nicht den richtigen Punkt gefunden es wieder zu aktivieren.

PeterPawn hatte mit #1500 am 22.09.2018 etwas geschrieben von: #97*3* enable und #97*2* diable [weil AVM den nomalen Zugriff nicht mehr unterstützen will - zumindest nicht das "enable" mit #96*7*] aber mit allen Versuchen habe ich bisher keinen Erfolg gehabt wieder auf die Box per Telnet zu kommen.
Hier ist auch meine Verwirrung recht groß - denn danach gab es mehrere Ansätze von PeterPawn immer wieder darauf hinzuweisen, dass der Zugriff auf Telnet nun wieder möglich ist und man wohl nichts weiter mehr machen muss (also keine extra Änderungen an den Skripten oder Einbindungen kurz vor der Implementierung/Anwendung des neu zusammengestellten Image machen muss).
Nur: Wie?

Könnt ihr mir bitte helfen.

Danke!
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,004
Beiträge
2,244,320
Mitglieder
373,392
Neuestes Mitglied
lukaskr07
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.