[Sammlung] Fragen, Probleme, Lösungen zum Thema "modfs-Starter"

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,138
Punkte für Reaktionen
1,703
Punkte
113
Dieser Thread möge bitte genutzt werden für die Kommunikation bei Nachfragen oder Fehlermeldungen zu dem in diesem Thread beschriebenen "Firmware-Update", mit dem eine ShellInABox-Instanz dauerhaft in einer VR9-Box verankert werden kann.

In dem anderen Thread reagiere ich nicht auf Fragen, jedenfalls nicht mit themenbezogenen Antworten ... höchstens mit Verweisen auf diesen Thread und der Bitte um Löschung von Beiträgen in diesem anderen Thread.
 
Moins


Ich finde das Klasse.
RESPEKT
...auch wenn ich keine NAND habe, kann ich es aber kaum erwarten eine in die Finger zu kriegen. :rock:

...abonniert.
 
Ich finde das auch klasse, funktioniert nur irgendwie leider bei mir nicht.
Ich habe eine 7490 mit 6.50 und habe die sqfs4 eingespielt, nur leider kommt bei mir auf Port 8010 nix bzw. Die Seite kann nicht angezeigt werden.
Habe auch mal direkt HTTPS davor gestellt, da kam einmalig ein Zertifikatsfehler und den habe ich bestätigt aber dann meldet er wieder Seite kann nicht angezeigt werden.
In der Box sollte es eigentlich sein da die FritzBox "Vom Hersteller nicht unterstützte Änderungen" anzeigt.
Habe auch von Anmeldung nur mit Kennwort mal auf Benutzername und Kennwort umgestellt, leider keine Änderung :-(.
Und ich wollte doch so gerne Darkstat zum laufen bekommen
 
@coolrunning:
Support-Daten? Prozess-Liste? Ist /var/custom gemountet? Gibt es eine /var/tmp/rc.custom.log?

Ist der Port nach innen offen bei einem Scan? Wenn ja, könnte man annehmen, daß es nur beim Start der Sitzung ein Problem gibt - das kann u.a. daran liegen, daß er das Zertifikat nicht öffnen kann. Aber alles eben reine Hypothesen ... wer möchte, kann mir gerne die kompletten Support-Daten an die Mailadresse "modfs" AT "yourfritz" DOT "de" schicken ... ich schaue rein, ob ich etwas sehe und werfe sie dann auch weg.

Mir fehlt gerade die Phantasie, woran es scheitern soll ... es sind einfach zu viele denkbare Fehlerquellen.

Ich habe das mit 06.30 und früheren Versionen schon sehr lange so am Laufen und für 06.50 die Version mit Schreiben nach /dev und "ordentlichem Protokollieren" nachgerüstet, weil es da schon ein beschreibbares Verzeichnis gibt, dank des "bind"-Mount für /dev.

Wenn ich jetzt nicht irgendwelchen Quatsch beim Kopieren auf den Server verzapft habe (ich würde schwören, den letzten Test mit direkter Eingabe der URL im "File Open"-Dialog gemacht zu haben), sollte es eigentlich klappen. Allerdings habe ich auch für die 7362SL und ihre Labor-Version schon eine negative Rückmeldung erhalten - vielleicht baue ich ja doch lieber noch eine analoge Version zur 06.30 ohne dynamisch erzeugtes Start-Skript.

Ansonsten kann man natürlich auch mit installiertem ShellInABox noch ein Pseudo-Update zum Start eines Telnet-Daemons machen, damit man an die Protokoll-Datei in /dev kommt bzw. überhaupt nachsehen kann (/dev ist m.W. nicht in den Supportdaten gelistet), ob da irgendwelche Dateien mit Namen "delayed_start.*" existieren.
 
Zuletzt bearbeitet:
Bin da ganz neu in der Materie.
Wie und wo sehe ich das? "Support-Daten? Prozess-Liste? Ist /var/custom gemountet? Gibt es eine /var/tmp/rc.custom.log?
"
:-(
 
Port 8010 ist offen.

Konnte gerade meinen Beitrag irgendwie nicht Editieren
 
Ok, die Support-Daten erhältst Du als Download, wenn Du den Link "http://fritz.box?lp=support" aufrufst (nach der Anmeldung, die Du wiederholen mußt, wenn die URL keine "sid" enthält) und dort den Button "Support-Daten erstellen" benutzt. In den Support-Daten sind einige sehr nützliche Angaben versammelt, u.a. eine Prozessliste (ps) und eine Liste der gemounteten Dateisysteme (mount). Da könnte man sehen, ob überhaupt etwas gemountet und ggf. noch gestartet wurde ... der Rest müßte dann iterativ erkundet werden, ich will Dich jetzt nicht mit zu vielen "Forderungen" überfahren und jede Menge "wenn, dann"-Dinge aufzählen. Bitte aber die Support-Daten nicht hier veröffentlichen ... da sind zu viele Daten drin, die nicht dauerhaft veröffentlicht (und ggf. sogar noch von Suchmaschinen indiziert) werden müssen.
 
Erweiterte oder Normale erstellen?

EDIT: Habe dir jetzt dir Normale per Mail geschickt.
 
Zuletzt bearbeitet:
Normale ... sonst: http://www.ip-phone-forum.de/showthread.php?t=282785&p=2132534&viewfull=1#post2132534

Ich würde es mir auch immer mehr als einmal überlegen, ob ich AVM die erweiterten Support-Daten überlasse oder nicht bzw. dann im Nachgang sofort alle dort enthaltenen Kennwörter ändern (und natürlich nicht nur in der FRITZ!Box, sondern an ihrem Ursprung). Selbst wenn man AVM ggü. nicht mißtrauisch ist, werden doch die meisten keine verschlüsselten E-Mails versenden (das sagt jedenfalls die bisherige Erfahrung) und wenn dann solche Dateien im "Gesendet"-Ordner bei irgendeinem Mail-Provider herumliegen, sind sie auch ein dankbares Ziel für Hacker.
 
Evtl. noch etwas wichtiges.
Ich benutze nicht die Standard IP der Fritz Box sondern 192.168.30.250 und der DHCP an der Fritz ist aus.
Den DHCP übernimmt bei mir ein SBS2011 was auch teilweise etwas Lustige bzw. Unlustige Ergebnisse in der Fritz Netzwerkliste und Priorisierung anstellt.
Da haut die Fritz gerne die IP-Adressen und Clients durcheinander.
 
Oh man, jetzt wird es peinlich.
Habe es die ganze Zeit mit dem IE11 probiert.
Jetzt mal mit dem IPhone und da ging die Shell auf, anschließend auf dem PC mit Chrome und die Shell geht auch.
Weiß aber nicht was da jetzt beim IE querschießt, ist mir aber auch egal da ich jetzt weiß wie es geht.
 
Ok, dann ist das schon mal geklärt ... bleibt die Frage, warum ShellInABox nicht mit dem IE11 funktioniert, aber das ist ein anderes Thema.

Deine Support-Daten sahen jedenfalls ohnehin richtig aus (siehe E-Mail) ... bleibt noch eine offene Baustelle bei Wäldler und der Labor-Version der 7362SL - für die 06.30 hatte ich von ihm eine positive Rückmeldung und da wird er ja wohl kaum einmal den IE11 und einmal einen anderen Browser verwendet haben.

Ich habe zwischendrin schon überlegt, eine Version von shellinaboxd mit statisch gelinkter libprivatekeypassword.so zu bauen ... aber wenn der Service läuft (das sieht jeder sofort in der Prozessliste in den Support-Daten), dann konnte das boxinterne Kennwort für den "private key" für TLS-Verbindungen auch ermittelt werden, denn das passiert direkt beim Start und beendet den Daemon, wenn es fehlschlagen sollte (glaube ich mich zu erinnern, aber auch dieser Patch ist ja fast 1 Jahr alt).

Vielleicht wäre noch eine konservativere Version für einen 3.10.73-Kernel denkbar, die ebenso wie die Version für frühere Kernel auf das dynamische Erstellen der Skript-Datei in /dev verzichtet (und auf das Protokollieren nach /dev/delayed_start.log) ... aber zumindest in der Außenansicht wird auch bei der 7362SL mit Kernel 3.10.73 das devtmpfs vor "init" gemountet und im Rahmen von "init" dann per bind-Mount in das richtige root-FS gespiegelt - das sieht 1:1 so aus wie bei der 7490 und sollte auch genauso funktionieren.
 
Kannst du mir evtl noch einen Tipp geben wie ich Darkstat zum laufen bekomme?

Ich habe das darkstat_v3.0.717.mips und darkstat.sh auf den usb stick Kopiert und folgendes eingegeben:

HDD='UT165-USBFlashDisk-00'
HDD_ABSOLUT='/var/media/ftp/'$HDD

TEMP=/var/tmp

while ! [ -d $HDD_ABSOLUT ] ; do sleep 5; done

cd $TEMP
cp $HDD_ABSOLUT/darkstat/darkstat $TEMP
cp $HDD_ABSOLUT/darkstat/darkstat.sh $TEMP
chmod +x darkstat
chmod +x darkstat.sh

$TEMP/darkstat.sh start

Der HDD Pfad ist angepasst.

Aber dann schmiert mir die FritzBox weg.

Es kommt ein Fehler beim Touch, wenn du es genauer brauchst mache ich es gerne noch mal.

Wenn das hier total falsch ist schreib mir bitte wo ich es besser schreiben soll.
 
So, ich habe mal ein wenig WireShark und den IE11 malträtiert ... ShellInABox funktioniert mit dem IE11 ebenfalls, aber nur im "compatibility mode" (sonst kommt der IE mit dem XHTML von ShellInABox nicht klar). Man muß also die Adresse/den Namen seiner FRITZ!Box in die Ausnahmeliste aufnehmen und dann klappt's auch mit dem Nachbarn.

Darkstat kenne ich für die FRITZ!Box nur dem Namen nach ... ich bin mir nicht einmal sicher, daß es auf einer FRITZ!Box bei aktiviertem PA korrekte Daten anzeigen kann - ist nicht mein Tisch. Irgendwo wirst Du die Binaries dafür ja her haben, ich tippe mal auf die Seite von r@d. Dann solltest Du auch dort um Hilfe nachsuchen ... allerdings kann ich irgendwie nicht so richtig glauben, daß ein "touch /var/tmp/statistik.db" zu einem Problem wird und so sollte das Kommando am Ende aussehen, wenn Du keine Fehler bei einer Änderung der darkstat.sh gemacht hast. Warum da die FRITZ!Box "wegschmieren" soll (was heißt das eigentlich genau, startet sie neu?), weiß ich auch nicht ... ich tippe am ehesten darauf, daß es auf einer 7490 mit 06.50 generell nicht funktioniert, schon bei einer Vorgängerversion fände ich das merkwürdig ... der Syntax nach zu urteilen, kommt da irgendwo die (statisch gelinkte) libpcap zum Einsatz und das wäre das erste libpcap-basierte Programm, was bei aktivem "packet accelerator" noch sinnvolle Daten liefert - jedenfalls soweit ich das weiß.
 
Vielen Dank für deine Tests.
Ja den Kompatibilitätsmodus vom IE vergesse ich irgendwie immer wieder.

Ich habe gar keine Änderungen an der darkstat.sh gemacht und die einfach so wie sie sind von der fritzmod Seite übernommen.
"Wegschmieren" bedeutet in meinem Fall das die Fritz komplett nicht mehr reagiert hat bzw. sie war nicht mehr im Netz und WLAN erreichbar und ließ sich nur durch Strom Trennen wieder zum Arbeiten zu bewegen.
War jetzt auch nur noch der Vollständigkeit halber was ich gerade geschrieben habe.
Da es so gar nicht deine Baustelle ist werde ich mich mal umschauen wer mir weiterhelfen kann.

Danke
 
Doch noch was Vergessen.
Wenn ich denn darkstat oder so was in der Art zum laufen bekomme, wo pack ich das script denn bei der aktuellen Firmware hin da die debug.cfg ja nicht mehr funktioniert.
 
Moins

der Syntax nach zu urteilen, kommt da irgendwo die (statisch gelinkte) libpcap zum Einsatz und das wäre das erste libpcap-basierte Programm, was bei aktivem "packet accelerator" noch sinnvolle Daten liefert - jedenfalls soweit ich das weiß.
Ach das ist der Grund, warum die Grafik plausibel aussieht, aber die Statistik und aktuelle Übertragungsrate so gar nicht dazu passen will.
Die Daten die zu gebrauchen sind stehen jeweils unter "Hosts" und dem Gerät (bzw. IP) mit In/Out/Total/Last seen, gepaart mit der sortierten Anzeige.

Mit meinem selbsgebasteltete rc.darkstat sieht ein sauberer Start auf einer MIPS Box übrigens so aus...
Code:
rc.darkstat start
...starting darkstat
darkstat (24322): max 600 hosts, cutting down to 100 when exceeded
darkstat (24322): max 60 ports per host, cutting down to 20 when exceeded
darkstat (24322): starting up
darkstat (24322): daemonizing to run in the background!
darkstat (24322): parent waiting
darkstat (24323): I am the main process
darkstat (24323): DNS child has PID 24324
darkstat (24323): capturing on interface 'dsl' with no filter
darkstat (24324): set uid/gid to 0/0
darkstat (24323): linktype is 113
darkstat (24323): calculated snaplen minimum 76
darkstat (24323): using snaplen 96
darkstat (24323): capturing in promiscuous mode
darkstat (24323): all capture interfaces prepared
darkstat (24323): listening on http://[::]:82/
darkstat (24323): listening on http://0.0.0.0:82/
darkstat (24323): loaded 35 protos
darkstat (24323): loaded 0 tcp and 0 udp servs, from total 0
darkstat (24323): chrooted into: /var/media/NEW_LINK/mips
darkstat (24323): set uid/gid to 0/0
darkstat (24323): today is 1450610073, tomorrow is 1450652400
darkstat (24323): entering main loop
darkstat (24322): parent done reading, calling waitpid
darkstat (24322): waitpid ret 0, status is 2144626412
...starting darkstat done
Hier wird einfach mal darkstat als root ( 0/0 ) gestartet.
...muss nicht unbedingt nobody sein.
Die Argumente, die im Skript für darkstat angegeben sind:
"-i dsl -p 82 --ports-max 60 --ports-keep 20 --hosts-max 600 --hosts-keep 100 --highest-port 65535 --chroot /var/media/NEW_LINK/mips --verbose --user root --daylog daily"
...für den DSL Verkehr.
Für ein einzelnes Interface -i ändern bspw: -i eth0
 
Zuletzt bearbeitet:
Ich weiß es gehört hier eigentlich nicht rein, ist aber für mich jetzt wichtig um das Thema endgültig abzuschließen.

Darkstat läuft auf meiner 7490 mit FW 6.50 und Shell in a Box.
Ich weiß nicht warum das Teil gestern abgeschmiert ist, hat sie heute nicht mehr gemacht.
Habe aber einige Stunden Darkstat immer wieder probiert zum laufen zu bekommen, und habe so viel gemacht und so oft gestartet das ich leider den Lösungsweg nicht mehr nachvollziehen kann.
Es sind immer wieder irgendwelche Fehler aufgeschlagen und plötzlich ist es gelaufen.
Die Daten wo da rauskommen langen mir als Schätz Eisen vollkommen da ich ja nur wissen mag welche IP gerade welchen Traffic erzeugt und um die max Traffic IPs rauszubekommen langt es.
Ob die Zahlen jetzt 100% Stimmen oder nicht ist in meinem Fall egal.
Also nochmal, grundsätzlich läuft darkstat_v3.0.717 MIPS auf dieser Box.

Dafür ist das Thema für mich jetzt hier abgeschlossen.
Die einzig offene Baustelle ist noch Darkstat automatisch mit der Fritz zu Starten, aber das bekomme ich denk ich auch noch dank der guten Dokumentation von PeterPawn zu seinem Shell in a Box hin.
 
Moins

Du brauchst Routine unter Linux.
Nicht nur für: Wie Programme/Skripte gestartet werden
...sondern auch: Wie laufende Dämonen beendet oder überwacht werden
Für Letzteres brauchst du mindestens: netstat ps kill

@PeterPawn, coolrunning: Entweder einigen wir uns aufs runterlöschen (#4), oder verschieben* in einen passenden Thread.
...dann bleibts hier übersichtlicher.


* Zum Beispiel nach hierhin: darkstat static binary (IP Traffic Bandwidth Monitor) by djtm
 
Zuletzt bearbeitet:
@koy:
Ich schreibe absichtlich nichts weiter zu darkstat hier ... der eine Absatz in #14 war die berühmte Ausnahme von der Regel. Wenn wirklich der darkstat-Teil gelöscht wird, nehme ich aber den Absatz auch raus ... andererseits ist das hier tatsächlich "nur" als Diskussion gedacht und der Thread, den ich gerne sauberhalten würde (und auch nachpflege, wenn sich aus diesem hier Erkenntnisse ergeben), ist der andere mit den Beschreibungen - damit kann jemand, der neu in der Thematik ist, sich auf diesen Thread beschränken und muß nicht jede Menge andere Beiträge lesen, bevor er es anwenden kann.

@coolrunning:
Du brauchst Dir ja nur ein eigenes passendes SquashFS-File zusammenstellen, dabei kannst Du auch gleich die passenden Binärdateien für die Zusatzsoftware dort mit aufnehmen. Darin dann noch die Datei "etc/init.d/rc.custom" so abändern, daß sie auch die Zusatzsoftware startet und dieses SquashFS-Image anstelle von "filesystem.image" in das tar-Archiv einbauen - oder natürlich gleich die Datei "filesystem_custom.squashfs" unterhalb von /wrapper gegen die eigene austauschen. Das ist über ShellInABox aber nicht ganz so einfach, weil die alte Datei dabei natürlich in Benutzung ist, da braucht man also noch ein ziemlich ausgefeiltes Skript, das zeitverzögert den ShellInABox-Service beendet, das "dismount" ausführt und dann erst die Datei unterhalb von /wrapper ersetzt.

Von der (dauerhaften) Benutzung von /var/media/ftp und darunter liegenden Verzeichnissen für den Start von Software auf der FRITZ!Box kann man unter Sicherheitsaspekten auch nur abraten, weil diese Verzeichnisse eben über verschiedene NAS-Dienste zugänglich sind und wenn es einem Angreifer gelingt, dort abgelegte Software gegen eigene auszutauschen, ist der schneller in der FRITZ!Box, als einem lieb ist.

Zum Testen ist das sicherlich ein gangbarer Weg ... aber wer dort (ohne Not) komplette Pakete ablegt und regulär von dort startet, der sollte schon noch einige zusätzliche Vorkehrungen zum Zugriffsschutz auf diese Verzeichnisse treffen und das meint nicht nur die Verwendung von "Benutzerberechtigungen" für den Zugriff auf diese Verzeichnisse - auch diese Verwaltung könnte ja einmal löcherig sein, sondern tatsächlich das Abschalten von Diensten.

Eine Lösung dort (die gegen extern "eingeschleuste" Änderungen hilft) wäre es, die eigenen Pakete mit boxspezifischen Daten für den Key zu verschlüsseln und sie dann vor ihrer Benutzung ins tmpfs zu kopieren und dabei zu entschlüsseln. Das vermeidet zumindest generische Angriffe durch den Austausch eines kompletten Pakets (über NAS-Zugriffe), weil das genau für die vorliegende Box verschlüsselt werden müßte. Leider baut AVM trotz der Benutzung von OpenSSL in Bibliotheksform nur zwei spezialisierte CLI-Programme in die eigene Firmware ein (eines zum Generieren eines Schlüsselpaars und eines zum Signieren als "self-signed") und man muß ein/das generische(s) CLI-Programm aus dem OpenSSL-Paket erst einmal selbst nachrüsten.

EDIT: Das bringt mich dann auch gleich noch darauf, daß ich im anderen Thread besser noch den Hinweis aufnehme, daß bei einer zweimaligen Anwendung desselben Prinzips auf einer Box ohne zwischenzeitliche Deinstallation das Austauschen der Image-Datei selten von Erfolg gekrönt sein wird, weil die gemountete Image-Datei normalerweise nicht überschrieben werden kann und man dann entweder ein "umount" machen muß (dann darf da auch kein Dienst mehr laufen, damit das klappt) oder mit Umbenennen der alten Datei und Speichern der neuen dann den doppelten Platzbedarf hat und sich auch überlegen sollte, wie man das alte (nun ja umbenannte) Image irgendwann wieder los wird.
 
Zuletzt bearbeitet:
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.