7270 54.04.97-13286: fz-trunk 2936:AVM Plugin's werden nicht nachgeladen

[olistudent]

Im Prinzip ist die AVM Pluginfunktionalität mit der von External + Downloader vergleichbar. Unterschied ist, dass AVM die Plugins als Squashfs-Datei anbietet, die nach /var/plugins (oder so ähnlich) gemountet wird.

MfG Oliver

 

[cando]

#! /bin/sh
echo "install plugins ..."
mkdir /var/plugins
PLUGINS=`ls /var/packet/var/plugin-*`
echo PLUGINS=${PLUGINS}
for i in $PLUGINS ; do
    mv ${i} /var/plugins
done
exit 0

und so sieht das instal script aus, das im plugin tar enthalten ist. es packt einfach alles was mit plugin- anfängt nach /var/plugins. anschliessend wird alles, was mit plugin- anfängt über eine weitere schleife mit tr069install registriert.

momentan gibt es 4 stück:

plugin-mediaserv.img
plugin-mini.img
plugin-ntfs.img
plugin-samba.img

 

[iphektor]

Hallo,

weiß nicht ob das Problem jetzt schon gelöst ist, bin gestern auch darüber gestolpert obwohl mir gar nicht bewusst ist welche Tollen Plugins mir da überhaupt abgehen.

Ich habe mich einfach nur gewundert weshalb die FB da nach hause telefoniert.

url="http://boxplugin.avm.de./cgi-bin/boxplugin?name=FRITZ!Box+Fon+WLAN+7270&revision=13053&version=54.04.67&subversion=&hw=139&OEM=avm"

Mir fällt an dieser URL auf, dass zwischen dem symbolischen Namen 'boxplugin.avm.de' und dem Slash noch ein punkt kommt, der gehört da nicht hin. D.h. anstelle von ....avm.de./cgi.... müsste es ....avm.de/cgi.... heißen.

Bei meiner aktuellen Spielbox (7270 hinter einem bestehenden Router) ist das auch so.

Scheint wohl doch an der Internetoption "Internetzugang über LAN 1" zu liegen,
obwohl DNS-Auflösung und wget aus der Telnetkonsole funktioniert...?

Wie schon angedeutet, das liegt nicht an der falschen Auflösung sondern an der falschen URL, weshalb die URL falsch ist habe ich aber keine Ahnung.

Tschüss Jo

 

[zirkon]

Der Punkt ist egal. Versuche es doch mal selbst via wget und dieser URL - dann wirst du es selbst beobachten können

LAN1 hört sich da schon verdächtiger an...

 

[hermann72pb]

Hallo cando,
danke für Infos.

-> Wieso sollten die archiviert werden?

Hat Oliver schon beantwortet. Es sollte archiviert werden.

-> Die box basiert auf einem linux system, normale bootfunktionalität.

Solche Trivialitäten sind mir schon klar. Nur mit dem Unterschied, dass bei der Box keine Linux-übliche Bootfunktionalität mit start/stop-Levels realisiert ist. Daher war die Frage, wo genau an welcher Stelle greifen sie zu.

-> Es wird eine fest verdrahtete datei auf einer avm url, die die boxversion + firmware nr. im pfad hat heruntergeladen und entweder im ram oder wenn ein usb medium angesteckt ist, dort gespeichert und ausgepackt. diese datei enthält auch ein shell script, dass dann die enthaltenen plugins in mit tr069install in den speicher lädt / an der box registriert.

ok, die genaue Reihenfolge versuche ich noch weiter unten zu erläutern, wie ich es verstanden habe.

tr069install wird für die registrierung der plugins aus dem script aufgerufen. wenn der fehlt, geht es nicht

Das ist die entscheidene Frage, die Stelle zu finden, woher tr069install aufgerufen wird.

nach dem booten der box und dem verbindungsaufbau über dsl wird ein loop - timer aktiviert....

ok, genau wie bei mir haben sie es gemacht. Bei meinem Downloader kann man wenigstens die Abstände und die Anzahl der Versuche definieren. Und den Server festlegen auch...


Ich versuche es nun zusammenzufassen, wie ich es verstanden habe:

1. Aus einem der Bootskripte (rc.S, oder ähnliches) wird tr069install aufgerufen.
2. tr069install ist eine Binärdatei, deren Quelltext wir leider nie zu Gesicht bekommen. tr069install "telefoniert" nach Hause (wo wird die Adresse gespeichert? Nicht doch etwa in der Datei selbst?) und lädt tar-Datei, samt eigentliche plugins, die als squash-fs-images vorliegen + install-Skript.
3. Install-Skript aus tar-Datei ist ein Workarround, weil jemand bei AVM gepennt hat und die Dateien einfach ein Paar Ebenen höher verschoben werden müssen (warum auch immer)
4. Danach übernimmt tr069install weiter die Regie (das ist zwar für mich ein Rätsel, wofür dieses hin- und her zwischen den Skripten sein sollte, aber egal) und mounted die plugin-Images, sodass sie nicht als Images, sondern als Dateisystem zu sehen sind. Dies würde mich näher interessieren, wie das gemacht ist. Also, ist es "mount -o bind" oder doch nicht?
5. Und erst jetzt darf es weiter gestartet werden: tr069install übergibt die Regie an rc.S (oder Ähnliches).


Hab ich es richtig beschrieben?


Was mich etwas stützig macht: Es findet gar keine Verschlüsselung statt. D.h. wenn es einem Angreifer gelingen sollte, die DNS-Anfragen von AVM auf seinen eigenen Server umzubiegen, hätte er theoretisch ganz viele Boxen verseuchen können. Oder versehen sie ihre Images mit eindeutigen Zertifikaten, die nicht zu fälschen sind?

MfG

 

[ralfjani]

Was mich etwas stützig macht: Es findet gar keine Verschlüsselung statt. D.h. wenn es einem Angreifer gelingen sollte, die DNS-Anfragen von AVM auf seinen eigenen Server umzubiegen, hätte er theoretisch ganz viele Boxen verseuchen können. Oder versehen sie ihre Images mit eindeutigen Zertifikaten, die nicht zu fälschen sind?

An meiner Box hing ein USB-Stick dran, als die Plugins geladen wurden. Dort wurde unter ./uStor01/FRITZ/plugins die Datei plugins.update abgelegt (tar-file)
Nach dem Entpacken lagen dort neben dem install-script und den vier plugin-xxx.images die angehängte signature Datei.
Mit dem Inhalt der Datei kann ich aber nix anfangen ggf. steckt da aber auch ein Zertifikat oder ähnliches drin. ... vielleicht hilft euch das.


[Edit:] Anhang wieder entfernt ...

 

[hermann72pb]

@ralfjani: Nimm am besten die Signatur aus deinem Anhang weg. Nicht, dass wir mit AVM deswegen rechtliche Probleme kriegen. Sie können ja behaupten, das in dieser Signatur so viel Gehirnschmalz drin steckt usw.

Appropos digitale Signierung. Alexander wenn du hier noch mitliest, kannst du dir bitte diese Signierung anschauen? Du kennst dich doch mit AVM-Kryptologie aus
Ich kommentiere einfach nicht weiter die Sinnhaftigkeit dieser Signatur, wenn die Datei schon sowieso auf der Box ist. Überlassen wir es AVM. Ich war übrigens schon so neugierig, dass ich diese 13053-Plugin-Sammlung mir per Browser runtergeladen hatte und entpackt hatte. Die images-Dateien sind wirklich drin und diese Signatur-Datei und install-Script.

Nun habe ich es für mich durch Kommentare oben auch noch etwas weiter verstanden. Und zwar, wofür diesen Versionsstring gebraucht wird und warum es fehl schlägt, wenn FREETZ-Sachen drinne stehen.

AVM wagt also die Versionsverwaltung der ganzen Plugins per "boxplugin"-Skript auf deren Server durchzuführen. Was man mit diesem "boxplugin"-Skript noch weiter veranstalten kann, dazu etwas später. Zunächst mal zum puren Mechanismus. Die Box meldet sich also beim AVM-Plugin-Server mit seiner vollen Kennung und enthält darauf eine Antwort:

URL="http://boxplugin.avm.de/boxplugin/139/54.04.67/13053..avm.plugin"

wo sie sich also die passende tar-Datei (die von AVM in hau-mich-tot.plugin umgetauft wurde) holt.
Mann, warum macht man es nicht einfach, wenn es komplizierter geht... Jeder normaler Mensch mit einem gesunden Verstand würde Ordner wie etwa /7270/54.04.67/ anlegen und dort eine vernünftige Dateistruktur schaffen: alle.plugin, samba.plugin, ntfs.plugin und gut isses. Die Box würde sich schon was passendes finden, ohne es sich vom AVM-Server vorsagen zu lassen.

Ich sag euch, was in Wirklichkeit dahinter steckt. Mit diesem boxplugin-Skript auf AVM-Seite lassen sich die Anmeldeversuche hervorragend loggen, vorfiltern und für spätere Analyse vorbereiten. Wir werden nun also nicht nur von unseren ISP, sondern von der alten lieben AVM noch bespitzelt. Oh, Mann... Man stelle sich nur die Anzahl der AVM-Boxen in deutschen Haushalten. Ich hoffe nur, AVM hat gute Anwälte und hat sich diese Schritte gut überlegt, denn es verstößt meiner Meinung nach gegen alle möglichen Regeln.

MfG

 

[cuma]

Das is ja klar dass die das mitloggen können, mit SVN-Revision usw. Die machen das aber bestimmt nicht weil es nicht mit dem geltenden Gesetz vereinbar ist. Zum glück reicht es hierfür "boxplugin.avm.de" zu sperren.
Hast du dir eigentlich mal angeschaut wie die Meldung "Neue Firmwareversion verfügbar" ins Webinterface kommt???

 

[hermann72pb]

nein, aber wo du es sagst: Vermutlich ähnlich.

MfG

 

[cando]

... der tr069 ansatz geht da noch weiter. neben den goodies, dass der provider die netzwerkgeräte / dsl router "fernwarten" kann, ist ja vorgesehen, auch die netze dahinter zu "bedienen" (z.b. ip-tv boxen im privaten LAN segment etc.).

so zu sagen von haus aus ein big brother zugang. Wen es interessiert, einfach mal danach googeln / dokumente lesen und die schöne neue welt bestaunen...

das thema ipv6 und die tunnelung über ipv4 ist auch so eine sache. teredo & co ist ja gemacht um "alte" nat firewalls zu überwinden und den armen anwendern die bunte "chat" und instant messaging welt mit "presece" zu erleichtern, mit eindeutigen zuordenbaren ip adressen.

was soviel bedeutet big brother weiss auch immer wann dein rechner an ist, und da ipv6 getunnelt wird, merkt die gute alte firewall nichts davon.

ausserdem geht das auch noch alles über einen proxy, der alle daten zentral sammelt. super idee. da ist google mit seinen "google statistik" modulen, die man sich freiwillig in die web-seiten integrieren kann um ein paar nette auswertungen zu bekommen, und dabei die bespitzelung seiner kunden zulässt, ja noch ein waisenknabe dagegen. wie gesagt, der isp ist noch das geringste übel, weil unvermeidlich. ach ja, vorratsdatenspeicherung, doublecklick&co etc.. lauschen ja auch noch mit.

und da gibt es auch noch das tor netzwerk, bei dem man gefiltert nur die "bösen buben", die sich sorgen um ihre privacy machen, schon mal vorverdichtet findet.

dann gibts da noch die sicheren seiten, die mit ssl verschlüsselt sind. bei jedem zugriff, baut natürlich der browser eine verbindung zur root authority auf um die crl zu prüfen. was glaubt ihr, was die "trusted" root authorities wie verisign & co für super statistiken zu den business sites und deren kundenverhalten haben.

 

[frank_m24]

Hallo,

Kinder bitte. Hier geht es um technische Belange. Für Verschwörungstheorien haben wir schon Threads. Sollte die Diskussion hier abdriften, sehe ich mich gezwungen, die abzutrennen und in einen eigenen Thread auszulagern.

 

[hermann72pb]

genau, bin auch der Meinung...
Und zurück zum Thema. Ich hatte gestern vergeblich versucht die xx.image-Dateien als squashfs auf der Box zu mounten. Entweder hatte ich was grundsätzlich falsch verstanden, oder die Box kann nicht squashfs mounten (was ich ehrlich gesagt nicht glaube).

Die Vorgehensweise war in etwa Folgende:
1. Datei plugin-samba.image ins /var/plugins kopieren
2. Ein Ordner namens /var/plugins/samba anlegen
3. Die besagte Datei auf diesen Ordner mounten:

/var/plugins # ls
plugin-mediasrv.image  plugin-mini.image      plugin-ntfs.image      plugin-samba.image     samba
/var/plugins # mount -t squashfs /var/plugins/plugin-samba.image /var/plugins/samba -o loop
mount: cannot setup loop device: No such file or directory

Was mache ich falsch?

MfG

 

[cuma]

Steht fast da. "mount -o loop irgendwas.image verzeichnis"

 

[hermann72pb]

/var/plugins # mount -o loop /var/plugins/plugin-samba.image /var/plugins/samba
mount: cannot setup loop device: No such file or directory

Nee, so einfach ist es wiederum nicht, cuma. Entweder geht es nicht mit der 59-Firmware oder man muss ein loop-Device separat anlegen (eine Andeutung darauf habe ich gefunden).
Angeblich gibt es bei 67-Firmware ein Skript, wo sowas stehen sollte. Bin gerade am schauen.

MfG

 

[cuma]

Bei mir gehts so einfach
Man muss das loop-Modul natürlich im Image haben. Außerdem hab ich in Erinnrung dass die Anzahl der /dev/loop's aus diesm grund in Freetz erhöht wurde

# tar xvf ../plugins.update
./var/
./var/plugin-samba.image
./var/plugin-mediasrv.image
./var/plugin-ntfs.image
./var/install
./var/plugin-mini.image
./var/signature

# mount -o loop var/plugin-samba.image y

# find y/
y/
y/control
y/sbin
y/sbin/smbd

 

[hermann72pb]

Ich hab mir nun doch /sbin/startplugin.sh aus 67-Firmware für 7270 angeschaut. Komischerweise finde ich die Datei nicht bei 67-Firmware zu 7170. Wurde es dort anders gelöst?
Und loop-Modul wird dringend benötigt. Bei 7270 zu finden:

/lib/modules/2.6.19.2/kernel/drivers/block/loop.ko

Bei 67-Firmware zu 7170 finde ich auch keinen loop-Modul. Oder habe ich da was falsch gemacht beim "make". Irgendwie finde ich im build-original-Verzeichnis zu 67-Firmware für 7170 nur "2.6.13.1-ohio"-Kernel, bei 7270 dagegen "2.6.19.2". Ist es korrekt? Kann 7170 überhaupt Plugins?

MfG

 

[Silent-Tears]

Läd die 7170 überhaupt plugins nach? Ich dachte, den Spass hat man für die 7270 vorbehalten?

 

[hermann72pb]

Die Firmwares heißen aber beide 67, sodass ich nach der alten AVM-Logik fest davon ausgegangen bin, dass 7170 und 7270 wenigstens die gleichen Kernels haben werden...

MfG

 

[cuma]

Nein, der Kernel der 7270 ist neuer. Deshalb gibts teilweise weniger Probleme (conntrack) oder mehr (Syslog) usw...

 

[hermann72pb]

alles klar. Dann war ich auf dem falschen Weg. Ich dachte nämlich, 7170 mit 67-Firmware nütze die plugins. Dem ist es wahsrcheinlich aber nicht so.

Übrigens, irgendwo in den Tiefen des 13-Kernels hatte ich ebenfalls eine loop.ko gefunden. Also, theoretisch wäre es möglich auch dort loop.ko einzubinden. Dann würden wenigstens die mounts klappen. Dass die plugins gegen 19-Kernel kompiliert sind, ist mir schon klar. Es ginge mir lediglich nur ums Prinzip und um eine eventuelle Erweiterung des Downloaders. Da AVM aber so ein undurchsichtiges und viel zu kompliziertes Konzept sich bei diesen Plugins ausgedacht hat, lasse ich es lieber.

Dass AVM für die 7170 immer noch den 13-Kernel pflegt und somit bewußt mehrgleisig fährt ist für mich ehrlich gesagt ein Rätsel. Aber lassen wir es so im Raum stehen.

MfG