TFFS sichern, provider additive box recovern und ggf. zurückbasteln

RAMler · 11 Jul 2015

Da ich Peters Thread nicht mit OT zulabern möchte, lagere ich das ganze mal hier hin aus und fasse kurz zusammen, was ich gerne tun würde.

- Ich habe eine Providerbox (7490 Hw185 Rev 5) hier, die schon mit der letzten Labor versehen wurde. Nun reizt es mich die Kiste komplett zu recovern, aber ich weiß nicht, ob dies die Möglichkeit der Provisionierung durch den ACS komplett abschießt.

Gründe wieso ich davor Angst habe:

- Die damalige 7390 provisionierte nicht mehr und trotz backup der provideradditive.tar und Eintragung aller Daten rückte der ACS nicht mehr mit User/PW heraus. Eingeloggt hat sich die Kiste aber auf dem ACS - mehr aber auch nicht.

- Die 7490 kam mit (werksseitig) 6.20 vom Provider und ich machte zuerst einen downgrade über die GUI, in der Hoffnung die Kiste würde sich dann die 6.20 wieder vom ACS holen (und ich mir den DL Pfad aus der tr069.cfg, damit ich ein Backup der Provider FW habe).

Das war schon ein klassischen Eigentor, denn danach war die Provisionierung kaputt. Wie mit der 7390 logte sich die Kiste auf dem ACS ein, bekam aber keine Daten mehr. Auch ein erneutes Aufspielen der AVM 6.20 oder 6.24 half nicht. Mit den letzten 2 Labors wurde mein IPS dann auch in die AVM Firmware fest eingepflegt (6.29 / 6.35) und damit ging die Provisionierung wieder.

Was ich nur durch das umflashen der Firmware zerlegte, also wieso der ACS keine Daten mehr gab mit vorherigen Versionen, keine Ahnung.

Für Peter:

Problematisch für mich ist ehrlich gesagt, dass vieles etwas zerstreut ist und ich quasi bei 0 anfange. Bei vielen Postings fehlen mir die "Zwischenschritte für dummies" mit den jeweiligen Befehlen.
Dann muss ich, wegen für euch einfachsten Dingen, mitunter viel lesen und noch mehr suchen. Soll keine Kritik sein, nicht missverstehen, ist halt für mich nur dann sehr aufwendig, erzeugt parallele Baustellen und mitunter fehlen mir aktuell die Nerven dazu.

Beispiel:
Ich weiß, dass das recover beide tffs partitionen überschreibt und zwangsläufig auch, sofern dort vorhanden, von meinem Provider Kram killen wird.
Das man die Partitionen sichern und wiederherstellen kann, weiß ich auch, beim "wie genau" scheitere ich.

Auf Dauer ziemlich frustrierend, wenn einen die eigenen Wissenslücken so sehr bremsen und ich aktuell nicht wirklich viele Nerven dafür übrig habe, aber es natürlich trotzdem reizt, zu basteln. Kollidiert natürlich miteinander ... und man muss sich bremsen nicht einfach frei Schnauze das Recover drüber zu ballern um zu sehen was passiert. :-X :mrgreen:

Mitunter hänge ich an einfachsten Dingen, z.B. wie ich sehen kann, wie EVA auf die Partitionen schaut und das System. Letzteres kann ich mit einem $ cat /proc/mtd ja einfach sehen. Da das recover aber MTD 3/4 als TFFS sieht, muss EVA ja komplett anders adressieren. MTD0 bis 5 sehe ich im environment, klar, nur was nun was ist, keine Ahnung. Sieht EVA hier auch die reserved kernel/fs?

dev: size erasesize name
mtd0: 00400000 00020000 "kernel"
mtd1: 03000000 00020000 "filesystem"
mtd2: 00400000 00020000 "reserved-kernel"
mtd3: 03000000 00020000 "reserved-filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 01600000 00020000 "nand-filesystem"
mtd6: 00020000 00001000 "urlader"
mtd7: 00010000 00001000 "tffs (1)"
mtd8: 00010000 00001000 "tffs (2)"

Geplanter Ablauf war eigentlich:
- tffs sichern
- provider im env entfernen (wie weiß ich)
- recover drüber ziehen
- Provisionierung testen mit aktueller Labor - wenns geht, super - alles wie es soll.
- Wenn es nicht geht, tffs wieder rein und die Provisionierung wieder ans Laufen bekommen.

Was ich nun nicht weiß:
Reicht das tffs backup? Muss ich ggf. noch an anderen Stellen etwas sichern? Wie genau sichere und spiele ich das tffs über EVA (sofern möglich) wieder ein?
Für Telnet müsste ich erst downgraden, was ja (welch Ironie) ohne recover gar nicht geht.
Alternativ könnte ich die vorherige FW über linux_fs_start booten und Werkseinstellungen laden und dort telnet aktivieren (noch vorhanden), sofern ich das richtig verstanden habe. Dort liegt ja noch das vorherige OS.

Wenn ich Denkfehler drin haben sollte, wäre ein Hinweis nett.

PeterPawn · 11 Jul 2015

RAMler schrieb:
Sieht EVA hier auch die reserved kernel/fs?

Nein, sieht sie (meines Wissens, ich kenne keine Quellen von AVM) nicht. Deshalb auch der Flash-Vorgang, so wie er im Moment abläuft.

Das Problem dürfte sein, daß NOR-Flash "bus-adressiert" arbeiten kann und damit direkt in den Hauptspeicher eingeblendet werden kann (also ein Zugriff darauf sich auf den Zugriff auf eine bestimmte Stelle im Speicher reduziert). Bei NAND-Flash ist das hingegen ein I/O-Vorgang, d.h. die Daten werden erst "vom NAND abgeholt" und im Hauptspeicher abgelegt.

Als Analogie beim PC kann man sich das so vorstellen, wie den Unterschied zwischen BIOS und HDD. Der BIOS-Code wird direkt in den Adressraum eingeblendet, von der HDD muß erst ein Lesebefehl erfolgreich abgeschlossen werden, bevor die Daten übertragen wurden und nun genutzt werden können.

Der Bootloader müßte also eine vollkommen neue Verwaltung für den Flash beinhalten (die Einstellungen und der Bootloader selbst sind vom NAND getrennt) und das ist - m.W., ich betone das extra noch einmal - nicht der Fall.

Ich kann mir bei der 7490 nicht so richtig vorstellen, was da seitens Inexio angepaßt wurde ... die Möglichkeiten sind nicht so groß.

Wenn das bei Dir schon lange/länger liegt, hat es sicherlich auch noch etwas Zeit ... ich klinke mich für heute praktisch aus dem IPPF aus und schreibe weiter am mksquashfs für die 06.35, sonst werde ich nie fertig.

koyaanisqatsi · 11 Jul 2015

Moins

Naja, das Rumfummeln im Environment und das Abfangen einer Box beim Start, um ins Eva/ADAM2 zu kommen, sollte schon reichlich vorher überlegt sein.
Um nicht sogar zu Sagen: Eine Strategie

1. Nötige Notfalldaten bereithalten: Backups, Recovery, Firmware
2. So doof wie es sich liest, aber Menschen vergessen: Ein Notizzettel der gemachten Änderungen
3. Dann noch: Wissen ist begrenzt, aber wissen wo es steht schadet nicht. Nur um das Verstehen kommste nicht rum

So.

Ein Backup der Firmware eines "Zwangsrouters" geht nur über Eva/ADAM2.
Ein "provider additive" kann später, wenn alles schick ist, auch wieder gesetzt werden.
...das gilt auch für das Branding.

Und bei solchen Spielchen eine...
:doktor:

Ich habe eine Providerbox (7490 Hw185 Rev 5) hier, die schon mit der letzten Labor versehen wurde.

...BETA zu nehmen, ja was soll ich da schreiben?

Mit der kennt sich ja PeterPawn kaum aus, die hat einen 3er Kernel, neues Webinterface und URLs.
Sozusagen bist du in dieser Hinsicht ein: Pionier

koyaanisqatsi · 11 Jul 2015

Nichtsdestotrotz ist eine BETA, so wie ich AVM kenne*, nicht für Produktiveinsatz vorgesehen.
Sondern nur für interessierte Betatester.

* Absichtliche Bugs, wie die vermeintliche Fehlanzeige des Trafficmonitors

PeterPawn · 11 Jul 2015

koyaanisqatsi schrieb:
Ein Backup der Firmware eines "Zwangsrouters" geht nur über Eva/ADAM2.

Das will ich nur noch kurz verneinen ... ich kann nicht über meinen Schatten springen (und doch will ich endlich mit dem SquashFS der 06.35 weiterkommen :-().

Ein Backup der Firmware ist nicht möglich ... nicht einmal das Auslesen des Inhalts von MTD3/MTD4, soweit ich weiß. Nur über das Auslesen des Urlader-Environments läßt EVA mit sich reden ... das AVM-Recovery baut mit diesen Informationen dann ein leeres TFFS-Image für das Überschreiben von MTD3/MTD4 (ruKernelTool schreibt da nur eine 0-Byte-Datei hinein).

Vielleicht spielen auch Sicherheitsüberlegungen eine Rolle beim weggefallenen "GET" für MTD0 und MTD1 ... aber ich finde die Erklärung mit dem fehlenden Zugriff für EVA auf den NAND-Flash logischer. Wenn EVA da nicht schreiben kann, dann (vermutlich) auch nicht "richtig lesen". Eine Schleife zum Schreiben von NAND-Inhalten in den Hauptspeicher wird sicherlich vorhanden sein (irgendwie müssen die Daten aus den NAND ja mal gelesen werden), das ist aber noch einiges von einer richtigen Verwaltung (insb. auch mit "defect management" und "wear leveling" beim NAND) entfernt.

RAMler · 11 Jul 2015

@Peter:
Die 7490 ist erst seit kurzem hier, die 7390 dafür eben wieder weg. Juckt halt in den Fingern.

Hallo koyaanisqatsi,

du musst das mit der BETA nur im richtigen Kontext sehen. Die 7490 bekam ich wegen einer Linecard Inkompatibilität und erst seit 6.29 und 6.35 synct die im upstream halbwegs vernünftig.

Deshalb bügelte ich auch in meiner Verzweiflung dann recht flott die aktuellste FW drauf.
Das erste was ich nach Erhalt eigentlich wollte, war die Provider FW zu sichern - aber denkste (siehe weiter unten).

Ein Backup der Firmware eines "Zwangsrouters" geht nur über Eva/ADAM2.

Schön wärs - "get mtd1" und co geht nicht (mehr) mit der 7490. get env geht, aber hat Peter ja bereits geschrieben.
Wenn get/put so noch klappen würde, wäre das alles herrlich gewesen.

Ich hatte vor kurzem mal ein kernel.image wie folgt angelegt:
cat /dev/mtdblock0 > /var/flash/media/ftp/blablameinusbstick/7490/kernel.image
Das ging/geht problemlos. Blöd nur das ich nun kein Telnet mehr habe mit der 6.35. Selbst wenn, kann ich so das fs und tffs sichern bzw. viel wichtiger, kann ich es dann auch wieder verwenden/einspielen? Wenn ja, wie genau (Befehle, Ablauf)?

Ein "provider additive" kann später, wenn alles schick ist, auch wieder gesetzt werden.
...das gilt auch für das Branding.

Weiß ich und es gibt bei meiner Box kein Branding im Sinne von "1&1" o.Ä.

Die Kiste steht als "branding" auf avm, hat aber vom Provider Anpassungen erhalten. Wo genau die alle liegen, weiß ich aber nicht. Ein reines FW Update über die GUI reicht(e) bereits aus, dass der ACS keine User/PW Daten mehr herausgab (ich aber bei ihm eingeloggt war und eine IPv4 & Ipv6 von ihm bekam, ohne eben Zugangsdaten fürs Netz zu erhalten oder surfen zu können).
Ich dachte damals bei der 7390, dass die Anpassung "nur" die provideradditive.tar wäre, dem war aber - wie ich ja schmerzlich festestellen musste - nicht so.

Wie gesagt, die Provisionierung geht mit den krach neuen Labors wieder und das wohl, weil mein Provider nun fest in die AVM FW eingepflegt wurde. Deshalb _vermute_ ich auch, dass nach einem recover die Provisionierung mit eben jenen FWs auch klappen würde. Die tr069 serial/passphrase steht ja nach wie vor im environment

Wer weiß schon genau, was er mit der "letzten Labor" überhaupt meint? Die von letztens oder die von gestern?

Die Versionen stehen im Text, wenn auch nicht der genaue build.

Genau gesagt: Aktuell drauf 06.35-30804
Vorher drauf 6.29-30480 (sollte ja dann noch in der inaktiven reserved Partitionen schlummern)

Mit der kennt sich ja PeterPawn kaum aus, die hat einen 3er Kernel, neues Webinterface und URLs.
Sozusagen bist du in dieser Hinsicht ein: Pionier

Ändert sich der flash über EVA denn durch die neue Version überhaupt?

Dazu ein paar kurze Fragen:
Kann ich per pseudoimage irgendwie auf das andere System switchen?

Würde folgender Weg gehen?
Eva einloggen
get env, schauen ob 0/1 gesetzt ist und mit quote SETENV linux_fs_start 0/1 eben ändern, reboot, werkseinstellungen laden? Dann hätte ich auch einen Telnet Zugang und da wären wir dann bei der Frage:

Wie sicherere ich die beiden TFFS Partitionen und wie schreibe ich sie im Falle des Falles zurück?

Um konkreter zu werden:

Könnte ich folgende Sicherungen:
cat /dev/mtdblock7 > /var/flash/media/ftp/blablameinusbstick/7490/tffs1
cat /dev/mtdblock8 > /var/flash/media/ftp/blablameinusbstick/7490/tffs2

später über EVA einspielen?

Ob da ein put mtd3/4 noch geht, echt keine Ahnung.

koyaanisqatsi · 11 Jul 2015

Kann ich per pseudoimage irgendwie auf das andere System switchen?

Ja, aber nur, wenn AVM den echo Befehl nicht aus der busybox schmeisst.

Mit einem Pseudofirmwareflash sollte auch der AVM busybox telnetd wieder zu starten sein.
PeterPawn hat dazu mal ein Beispiel der Verrenkung mit mount und ln gebracht.
Der Inhalt von /usr/sbin wird nach/var/tmp/usersbin kopiert und dann wird /usr/sbin mit /var/tmp/usersbin übermountet.
mount -o bind /var/tmp/usersbin /usr/sbin
Dann noch den Softlink in /usr/sbin/telnetd auf /bin/busybox setzen...
rm /usr/sbin/telnetd ; ln -sf /bin/busybox /usr/sbin/telnetd
Telnetd starten: /usr/sbin/telnetd -l /sbin/ar7login
Das muss nur entsprechend in die /var/install der Pseudofirmware eingetragen werden.

Wenn du damit* auf die Box kommst, kann das Environment ganz simpel bearbeitet werden...

Anzeigen: cat /proc/sys/urlader/environment

Ändern:

Beispiel: provider löschen

Code:

echo "provider" > /proc/sys/urlader/environment

Beispiel: my_ipaddress ändern

Code:

echo "my_ipaddress 169.254.1.1" > /proc/sys/urlader/environment

* Ob Pseudofirmware und die echo Anweisungen oder mit aktivierten telnetd ist dabei egal.

RAMler · 11 Jul 2015

Vielen Dank.

Korrekto? Lieber einmal zuviel fragen, als Mist bauen.

Code:

#! /bin/sh

mkdir /var/tmp/usersbin
cp -a /usr/sbin/* /var/tmp/usersbin
mount -o bind /usr/sbin /var/tmp/usersbin
rm /usr/sbin/telnetd ; ln -sf /bin/busybox /usr/sbin/telnetd
/usr/sbin/telnetd -l /sbin/ar7login
killall firmwarecfg
update_led_off #[COLOR="#B22222"]blinken die sonst dauerhaft?[/COLOR]
exit 0

~~Wie kann und sollte ich den reboot noch unterbrechen/abwürgen am Ende des Pseudoimages?~~
killall firmwarecfg -> korrekt?

Wieso eigentlich das umkopieren nach /var/tmp und übermounten und wozu wird /usr/sbin/telnetd gelöscht? :gruebel:

Zwecks Provider:
Danke, das wusste ich - zur Not hätte ich das auch ja auch über EVA mit quote UNSETENV provider machen können. Machte ich ja schon öfters. Bei mir ist das Wissen etwas böh ungleich verteilt. Bootloader auslesen, MAC Adressen ändern, neu flashen - ja, weil schon gemacht.

Nun so etwas grundlegendes wie nur telnet wieder aktivieren ....

Aber mit der Zeit wirds besser.

koyaanisqatsi · 11 Jul 2015

Versuch es mal so...

Code:

cp -R /usr/sbin /var/tmp/usersbin
mount -o bind /var/tmp/usersbin /usr/sbin
rm /var/tmp/usersbin/telnetd
ln -sf /bin/busybox /usr/sbin/telnetd
/usr/sbin/telnetd -l /sbin/ar7login
killall firmwarecfg # verhindert Neustart
update_led_off #[COLOR=#B22222]F: blinken die sonst dauerhaft?[/COLOR]A: Ja
exit 0

Achte auf das mount, habs erst falsch gepostet (aus der Erinnerung) und etwas später korrigiert.

Es wird umkopiert damit es denselben Inhalt hat wie das Original.
Nicht das noch irgendein AVM Prozess sein Programm nicht findet.
Aber eigentlich müssten alle Links in /var/tmp/usersbin repariert werden.

Das rm ist nur zur Sicherheit, ist man sich sicher lässt man es weg.
...auf meinem System gibt es den Link, deswegen erstmal weg damit.

RAMler · 11 Jul 2015

Habs so versucht und wie folgt:

#! /bin/sh

mkdir /var/tmp/usrsbin
cp -a /usr/sbin/* /var/tmp/usrsbin/
ln -s /bin/busybox /var/tmp/usrsbin/telnetd
mount -o bind /var/tmp/usrsbin /usr/sbin
/usr/sbin/telnetd -l /sbin/ar7login
killall firmwarecfg
update_led_off
exit 0

Fazit nicht näher spezifizierter Fehler (227). Danach Netz, Telefonie und co tot und ich musste rebooten.

RAMler · 11 Jul 2015

Ich habe nun nur ein

#! /bin/sh

echo clear_id 87 > /proc/tffs
exit 0

hochgeladen, was funktionierte. Das Problem liegt an killall firmwarecfg oder update_led_off. Lasse ich beides weg, kann ich auch telnet aktivieren. Dann ist der dsld ect (Netz und co.) halt schon tot und die Kiste hängt ja kurz vorm reboot. Wie kann ich das dann einfach per telnet korrigieren?

PeterPawn · 11 Jul 2015

@RAMler:
Suche mal noch etwas und lies einiges zu den "Pseudo-Updates". Die sind nur in sehr begrenzten Fällen hilfreich, da vor dem Entpacken des Images auf der Box ein partieller Shutdown stattfindet ... daher ist es kein Wunder, daß da kein Internet, keine Telefonie und auch kein USB-Speicher mehr geht.

Das ist wirklich nur etwas zum Ausführen von (einzelnen) Kommandos/Aktionen, wenn alle notwendigen Bestandteile lokal (und das meint auch nicht auf dem USB-Stick, sondern mindestens im NAND) vorliegen. Eine solchermaßen teilweise heruntergefahrene Box läßt sich auch nicht in allen Aspekten wieder in den "Normalzustand" bringen, ohne den eigentlich geplanten Restart nach dem Dateiupload für das Image auszuführen.

Joe_57 · 11 Jul 2015

Kann es sein, daß die Leerzeichen im Shebang nix verloren haben und deine Scripte deshalb nicht funktionieren? :noidea:

Joe

RAMler · 11 Jul 2015

... daher ist es kein Wunder, daß das kein Internet, keine Telefonie und auch kein USB-Speicher mehr geht.

Hat sich gerade mit meinem edit überschnitten. Auch Telnet ging nicht, wie gesagt, es kam nicht "kein Fehler" sondern "nicht näher spezifizierter Fehler 227".

Die Box schoss es da z.T. richtig weg.

Eine solchermaßen teilweise heruntergefahrene Box läßt sich auch nicht in allen Aspekten wieder in den "Normalzustand" bringen, ohne den eigentlich geplanten Restart nach dem Dateiupload für das Image auszuführen.

Danke für die Info. Das heißt ohne modfs + debug.cfg kann ich telnet eh nicht wirklich auf einer "aktiven" Box nutzen?

---
Überlegungen wie folgt:

Kann ich zumindest den USB Part über Telnet wieder kurzfristig aktivieren, wenn die Box vorab teilruntergefahren wurde?

Dann könnte ich die beiden tffs partitionen, kernel und fs sichern.

Danach geplant, dazu müsste ich den dsld wieder anbekommen, wäre:

- modfs drauf
- telnet damit wieder in "Altzustand" versetzen
- rebooten

Dann mal weitersehen. Erst mal lesen und schauen wie ich dann kernel/fs/tffs im Zweifelsfalle neu schreiben könnte. Kann ich dazu mittels
cat /dev/mtdblockx > /var/flash/media/ftp/blablameinusbstick/7490/xxxxx.image
erzeugte images auch später wieder nutzen? Oder scheitert das schon im Voraus, weil (?)....

koyaanisqatsi · 11 Jul 2015

Die Fehlermeldung 227 ist typisch für eine Textdatei im Windows Format.
Benutz doch mal einen Editor, der, sagen wir mal, UTF-8 ohne BOM und das Zeilenende im Unix Format abspeichern kann.
...ist übrigens ein typischer Anfängerfehler und auch typisch für Copy'n'Paste und ab dafür.

Aber, wie heisst es doch so schön: Man kann ja nicht an Alles denken

Grad gestestet, funzt auch soweit...

/var/install

Code:

#!/bin/sh
# start ctlmgr if stopped
$(ps |  grep -v grep | grep -q ctlmgr) ||  ctlmgr 

# activating telnetd on F!OS 6.25 and higher?
# based on code by PeterPawn www.ip-phone-forum.de
# ...first thing is to extending the PATH so the telnet login can use it
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
cd /var/tmp
cp -R /usr/sbin /var/tmp/usersbin
mount -o bind /var/tmp/usersbin /usr/sbin
ln -sf /bin/busybox /usr/sbin/telnetd
/usr/sbin/telnetd -l /sbin/ar7login -p 23

# starting usb and dsld and phonebook and faxd and voipd
#sh /etc/init.d/rc.usbhost start
#/sbin/udevadm trigger
#sh /etc/init.d/rc.net
#/usr/bin/pbd
#/usr/bin/faxd -a
#/bin/voipd

update_led_off
# kill firmwarecfg or box will reboot after about one minute 
killall firmwarecfg
exit 0

Format: Ansi as UTF-8, Zeilenende: Unix

RAMler · 11 Jul 2015

Ich hatte extra Notepad++ genutzt. Nun erst mal in die Falle, rest dann morgen.

Danke für eure Hilfe.

koyaanisqatsi · 11 Jul 2015

Erstellt Notepad++ automatisch eine Linuxtextdatei wenn auf Windows gespeichert wird (Neue Datei) ?

Notepad++

Schau mal: Bearbeiten --> Zeilenende --> Konvertiere zu UNIX (LF)
...und...
Kodierung:

UTF-8 ohne BOM

RAMler · 11 Jul 2015

Neue File ist wirklich DOS\WIndows UTF8 w/o BOM, wobei ich eine schon vorhandene bearbeitete. Aber dann hats sicherlich trotzdem daran gelegen und mir fiel es nicht auf.

Nun denn, gute Nacht.

koyaanisqatsi · 11 Jul 2015

USB Geräte zu reaktivieren ist ein bischen tricky.
Einmal hab ich das geschafft, als zusätzlich zu meinen 8GB ein USB Tethering Gerät eingesteckt war.
...aber das krieg ich auch noch raus.

Bis dahin sollte sich nach einen anderen lokalen/www Netzwerkspeicher oder FTP Server umgesehen werden.

Beispiele wie was gestartet werden kann hab ich in der install aus Post 15 einkommentiert.
...so nach Reihenfolge, denn voipd macht erst richtig Sinn wenn dsld gestartet wurde.

PeterPawn · 11 Jul 2015

koyaanisqatsi schrieb:
USB Geräte zu reaktivieren ist ein bischen tricky.

Ich weiß nicht, wie das auf der 7360SL ist, aber "/etc/init.d/rc.usbhost start" und "udevadm trigger" helfen auf der 7490 - aber auch das ist nur eine "Krücke". Einige andere Sachen (wie Watchdogs usw.) kannst Du aber nicht ohne weiteres wieder reaktivieren.

TFFS sichern, provider additive box recovern und ggf. zurückbasteln

Mitglied

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

Mitglied

IPPF-Urgestein

IPPF-Promi

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

IPPF-Urgestein

Statistik des Forums