Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

LB sperrt Kanäle / Server wird nicht weiter geshart

AW: LB sperrt Kanäle / Server wird nicht weiter geshart

Ok ist eingepflegt.
Mal sehen ob sich was bessert. :emoticon-0125-mmm:
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

Aber hoffentlich so: ecmwhitelist = 46,58,90,95 ...
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

Habs so eingepflegt:
ecmwhitelist = 09C4:46,58,90,95

Gerade hat der LB wieder einige Sender gesperrt, doch was diesmal anders war, ist das er diese Sender auch wieder geöffnet hat nach einer Minute.
Merkwürdig das ganze.

Edit: Er hat zugleich aber auch wieder andere Sender rausgekegelt.
Ich guck grad im Debugger doch finde nichts aussagekräftiges.
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

Mach/versuch mal so:
Code: 
[FONT=courier new]lb_reopen_seconds              = 60 [/FONT][FONT=courier new]
lb_retrylimit                  = 2800[/FONT][FONT=courier new] 
lb_retrylimits                 = 09C4:385[/FONT]
... und noch das vllt:
oscam.server für V13
Code: 
[FONT=courier new]ratelimitecm                  = 1
ratelimitseconds              = 10
cooldown                      = 60,60[/FONT]
 
Zuletzt bearbeitet:
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

Settings gesaved, Emu neugestartet und er nahm direkt den Backup-Proxy Server anstatt des Lokalen. :emoticon-0106-cryin
Was ich vergessen hatte, die Stats zu löschen.

Nun ist er erst einmal wieder beim Lokalen.
Mal sehen wie lange das so bleibt. :emoticon-0122-itwas

Ich dank dir aber schon mal für die fach kräftige Hilfe.

Edit:
Ich hab mal, ein für mich, sehr merkwürdigen Teil des Logs ausgeschnitten.

2012/06/25 09:06:15 9DD19B8 r v13 cooldown OFF2012/06/25 09:06:15 B7167C30 c user2 (09C4&000000/0000/EF10/58:4AC8): found (96 ms) by v13 (L/1/1/3)
2012/06/25 09:06:16 B6F23050 c user1 (09C4&000000/0000/EF75/58:6520): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:06:22 B7167C30 c user2 (09C4&000000/0000/EF10/58:2585): found (92 ms) by v13 (L/1/1/3)
2012/06/25 09:06:23 B6F23050 c user1 (09C4&000000/0000/EF75/58:2607): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:06:29 B7167C30 c user2 (09C4&000000/0000/EF10/58:6751): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:06:30 B6F23050 c user1 (09C4&000000/0000/EF75/58:83E4): found (100 ms) by v13 (L/1/1/3)
2012/06/25 09:06:36 B7167C30 c user2 (09C4&000000/0000/EF10/58:5529): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:06:37 B6F23050 c user1 (09C4&000000/0000/EF75/58:3984): found (93 ms) by v13 (L/1/1/3)
2012/06/25 09:06:43 B7167C30 c user2 (09C4&000000/0000/EF10/58F0B): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:06:44 B6F23050 c user1 (09C4&000000/0000/EF75/58770): found (93 ms) by v13 (L/1/1/3)
2012/06/25 09:06:50 B7167C30 c user2 (09C4&000000/0000/EF10/58:06BA): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:06:51 B6F23050 c user1 (09C4&000000/0000/EF75/58:C372): found (95 ms) by v13 (L/1/1/3)
2012/06/25 09:06:57 B7167C30 c user2 (09C4&000000/0000/EF10/58:571B): found (95 ms) by v13 (L/1/1/3)
2012/06/25 09:06:58 B6F23050 c user1 (09C4&000000/0000/EF75/58:7E66): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:07:04 B7167C30 c user2 (09C4&000000/0000/EF10/58:360E): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:07:05 B6F23050 c user1 (09C4&000000/0000/EF75/58:2BEB): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:07:11 B7167C30 c user2 (09C4&000000/0000/EF10/58:763C): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:07:12 B6F23050 c user1 (09C4&000000/0000/EF75/58:194F): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:07:18 9DD19B8 r v13 cooldown ON
2012/06/25 09:07:18 B7167C30 c user2 (09C4&000000/0000/EF10/58:38F1): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:07:19 B6F23050 c user1 (09C4&000000/0000/EF75/58:B139): found (259 ms) by proxy1 (P/1/1/2)
2012/06/25 09:07:25 B7167C30 c user2 (09C4&000000/0000/EF10/58:0EA4): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:07:26 B6F23050 c user1 (09C4&000000/0000/EF75/58:9333): found (255 ms) by proxy1 (P/1/1/2)
2012/06/25 09:07:32 B7167C30 c user2 (09C4&000000/0000/EF10/58:27CF): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:07:33 B6F23050 c user1 (09C4&000000/0000/EF75/58:1369): found (259 ms) by proxy1 (P/1/1/2)
2012/06/25 09:07:39 B7167C30 c user2 (09C4&000000/0000/EF10/58:C33C): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:07:40 B6F23050 c user1 (09C4&000000/0000/EF75/58:3DF4): found (258 ms) by proxy1 (P/1/1/2)
2012/06/25 09:07:46 B7167C30 c user2 (09C4&000000/0000/EF10/58:9868): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:07:47 B6F23050 c user1 (09C4&000000/0000/EF75/58:3331): found (262 ms) by proxy1 (P/1/1/2)
2012/06/25 09:07:53 B7167C30 c user2 (09C4&000000/0000/EF10/58:7FDA): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:07:54 B6F23050 c user1 (09C4&000000/0000/EF75/58:121E): found (256 ms) by proxy1 (P/1/1/2)
2012/06/25 09:08:00 B7167C30 c user2 (09C4&000000/0000/EF10/58:7118): found (100 ms) by v13 (L/1/1/3)
2012/06/25 09:08:01 B6F23050 c user1 (09C4&000000/0000/EF75/58:57A6): found (255 ms) by proxy1 (P/1/1/2)
2012/06/25 09:08:07 B7167C30 c user2 (09C4&000000/0000/EF10/58CC7): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:08:08 B6F23050 c user1 (09C4&000000/0000/EF75/58:1EC2): found (271 ms) by proxy1 (P/1/1/2)
2012/06/25 09:08:14 B7167C30 c user2 (09C4&000000/0000/EF10/58:1976): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:08:15 B6F23050 c user1 (09C4&000000/0000/EF75/58:4701): found (259 ms) by proxy1 (P/1/1/2)


#################### Zugeschnitten ##############################


2012/06/25 09:35:39 9DD19B8 r v13 cooldown OFF
2012/06/25 09:35:39 B7167C30 c user2 (09C4&000000/0000/EF10/58:CA01): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:35:39 B6F23050 c user1 (09C4&000000/0000/EF75/58:B096): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:35:46 B7167C30 c user2 (09C4&000000/0000/EF10/58:89C2): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:35:46 B6F23050 c user1 (09C4&000000/0000/EF75/58:1DF4): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:35:53 B7167C30 c user2 (09C4&000000/0000/EF10/584C4): found (101 ms) by v13 (L/1/1/3)
2012/06/25 09:35:53 B6F23050 c user1 (09C4&000000/0000/EF75/58:7AAF): found (104 ms) by v13 (L/1/1/3)
2012/06/25 09:36:00 B7167C30 c user2 (09C4&000000/0000/EF10/58:2459): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:36:00 B6F23050 c user1 (09C4&000000/0000/EF75/58:197D): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:36:07 B6F23050 c user1 (09C4&000000/0000/EF75/58:F016): found (102 ms) by v13 (L/1/1/3)
2012/06/25 09:36:10 B6F260A0 c encrypted cccam-client 92.224.182.62 rejected (disabled account)
2012/06/25 09:36:10 B6F260A0 c password for 'user2' invalid!
2012/06/25 09:36:10 B6F260A0 c anonymous disconnected from 92.224.182.62
2012/06/25 09:36:10 B6F260A0 c thread B742FB70 ended!
2012/06/25 09:36:14 B6F23050 c user1 (09C4&000000/0000/EF75/58:CF49): found (100 ms) by v13 (L/1/1/3)
2012/06/25 09:36:21 B6F23050 c user1 (09C4&000000/0000/EF75/58:ACB4): found (100 ms) by v13 (L/1/1/3)
2012/06/25 09:36:28 B6F23050 c user1 (09C4&000000/0000/EF75/58:5695): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:36:35 B6F23050 c user1 (09C4&000000/0000/EF75/58:275E): found (100 ms) by v13 (L/1/1/3)
2012/06/25 09:36:42 9DD19B8 r v13 cooldown ON
2012/06/25 09:36:42 B6F23050 c user1 (09C4&000000/0000/EF75/58:85A0): found (100 ms) by v13 (L/1/1/3)
2012/06/25 09:36:49 B6F23050 c user1 (09C4&000000/0000/EF75/58:12F1): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:36:56 B6F23050 c user1 (09C4&000000/0000/EF75/58:A9D2): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:37:03 B6F23050 c user1 (09C4&000000/0000/EF75/58:C0EB): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:37:10 B6F23050 c user1 (09C4&000000/0000/EF75/58:B3BE): found (96 ms) by v13 (L/1/1/3)
2012/06/25 09:37:17 B6F23050 c user1 (09C4&000000/0000/EF75/58:4913): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:37:24 B6F23050 c user1 (09C4&000000/0000/EF75/58:C614): found (98 ms) by v13 (L/1/1/3)
2012/06/25 09:37:31 B6F23050 c user1 (09C4&000000/0000/EF75/58:60CA): found (101 ms) by v13 (L/1/1/3)
2012/06/25 09:37:38 B6F23050 c user1 (09C4&000000/0000/EF75/58128): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:37:45 9DD19B8 r v13 cooldown OFF
2012/06/25 09:37:45 B6F23050 c user1 (09C4&000000/0000/EF75/58:9BCA): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:37:52 B6F23050 c user1 (09C4&000000/0000/EF75/58:6F38): found (96 ms) by v13 (L/1/1/3)
2012/06/25 09:37:59 B6F23050 c user1 (09C4&000000/0000/EF75/58:2266): found (97 ms) by v13 (L/1/1/3)
2012/06/25 09:38:06 B6F23050 c user1 (09C4&000000/0000/EF75/58:417B): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:38:13 B6F23050 c user1 (09C4&000000/0000/EF75/58BD3): found (100 ms) by v13 (L/1/1/3)
2012/06/25 09:38:20 B6F23050 c user1 (09C4&000000/0000/EF75/58:5392): found (101 ms) by v13 (L/1/1/3)
2012/06/25 09:38:27 B6F23050 c user1 (09C4&000000/0000/EF75/58:0462): found (101 ms) by v13 (L/1/1/3)
2012/06/25 09:38:34 B6F23050 c user1 (09C4&000000/0000/EF75/58:93FF): found (99 ms) by v13 (L/1/1/3)
2012/06/25 09:38:41 B6F23050 c user1 (09C4&000000/0000/EF75/58:3BA4): found (104 ms) by v13 (L/1/1/3)

Dort kann man erkennen, das sobald der Cooldown On geht, "user1" nur noch vom Proxy die ECM´s kriegt.
Sobald der Cooldown Off geht, nur von der Lokalen.
Das ganze ging im oberen Teil des Logs so weiter.
Ich hab es mal ein wenig gekürzt.

Das merkwürdige daran ist jetzt allerdings, das wenn ich "user2" deaktiviere, auch wenn der Cooldown Off oder On geht, "user1" nur auf dem Lokalen Reader bleibt.
Wenn der "user1" auch auf einem der vom LB geblockten Programme säße, würde das bei diesem vermutlich im oberen Teil des Logs ähnlich aussehen.

Nur jetzt stellt sich mir die Frage warum der zweite Teil des Logs nun so ausschaut.
Blockiert vlt. user2, mit seiner Anwesenheit, user1 sodass dieser nur vom Proxy beziehen kann?

Kleine Anmerkung:
User1 verbindet sich über ACamd und User2 hat eine Ariva 102e Box.

Woran könnte das ganze liegen?
 
Zuletzt bearbeitet:
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

Hallo zusammen....ich klinke mich mal hier mit ein
Habe mir noch ne 2. D02 mit LB zugelegt und habe wie Ihr auch das gleiche Problem das Sender gesperrt werden. Bin auch noch am basteln jedoch noch ohne
durchschlagenden Erfolg. Ein löschen der Statistiken hilft löst aber nicht das Problem. Meine LB-Settings sind wie folgt.

Gruß

lb_mode = 1
lb_save = 100
lb_min_ecmcount = 5
lb_max_ecmcount = 500
lb_savepath = /var/log/ipc/stat.log
lb_reopen_mode = 1
lb_stat_cleanup = 2
lb_reopen_mode = 0
lb_reopen_seconds = 5
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

ratelimitecm = 1
Bedeutet: Anzahl der ECMs ... hier z.B. 1 (kann jedoch auch mehr sein max. bei NDS vllt. 6)
ratelimitseconds = 10
Bedeutet: Zeit in Sekunden, in der die ECMs angefordert (im Bsp. 1 ECM innerhalb von 10 sec.)
cooldown = 60,60
Bedeutet:
vor dem Komma - Zeit in Sekunden wo Reader/Proxy ganz normal läuft
nach dem Komma - Zeit in Sekunden wo die Werte aus ratelimitecm und ratelimitseconds greifen
... also 60 sec. normal, dann 60 sec. ratelimit. (immer halt im Wechsel)

PS: kannst aber auch mal mit höheren Werten testen.
Code: 
[FONT=courier new]ratelimitecm                  = 4 
[/FONT][FONT=courier new]ratelimitseconds              = 10 
[/FONT][FONT=courier new]cooldown                      = 120,60[/FONT]

... der Andere
Code: 
[FONT=courier new]lb_mode = 1
lb_save = 100
lb_min_ecmcount = 5
lb_max_ecmcount = 500
lb_savepath = /var/log/ipc/stat.log
lb_stat_cleanup = [COLOR=#ff0000]2[/COLOR]
lb_reopen_mode = 1
lb_reopen_seconds = 60[/FONT]
Du hast also 2 identische Karten?
Dann solltest du, weil ja die gleiche CAID, jeden Reader eine separate Gruppe zuweisen.
Dann geht der Loadbalancer besser.
 
Zuletzt bearbeitet:
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

so habe nun ausgiebig getestet...läuft bis jetzt super

habe OSCAM 1.20-unstable_svn build #7069 installiert

meine oscam config

[global]
logfile = stdout
clienttimeout = 10000
fallbacktimeout = 2800
cachedelay = 120
unlockparental = 1
nice = -1
maxlogsize = 128
waitforcards = 0
preferlocalcards = 1
saveinithistory = 1
dropdups = 1
lb_mode = 1
lb_save = 500
lb_max_ecmcount = 250
lb_reopen_seconds = 60
lb_retrylimit = 2800
lb_retrylimits = 1702:2800
lb_savepath = /var/log/ipc/stat
lb_reopen_mode = 1

habe jede karte in einer anderen group, und gebe nur meine lokalen karten weiter...

manche sender werden ab und zu gesperrt, aber sobald ein anderer user auf den sender zappt wieder freigegeben...

gerade heim von spätschicht alles läuft nix gesperrt:emoticon-0157-sun:
 
Zuletzt bearbeitet:
AW: LB sperrt Kanäle / Server wird nicht weiter geshart



Um etwas aussagekräftiges zu sagen, müsste man die anfrage sehen, die dafür verantwortlich ist, dass der LB den kanal dichtmacht.
Bei der D02 (1722) können auch UM Sky Clienten schuld sein.
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

.pix schrieb:
Um etwas aussagekräftiges zu sagen, müsste man die anfrage sehen, die dafür verantwortlich ist, dass der LB den kanal dichtmacht.
Bei der D02 (1722) können auch UM Sky Clienten schuld sein.
Zum Vergrößern anklicken....

Hallo,
ich werde über das Wochenende mal einiges testen. Zuerst werde ich Services anlegen was lt. dem Wiki bei benutzung des Loadbalancers Sinn machen soll. Bis jetzt habe ich das aus "Faulheit" nicht gemacht.
Dann hatte ich noch beiden Karten da gleich die selbe Gruppennummer gegeben. Lt. einigen Posts sollte das eigentlich kein Problem sein. Andere meinen jedoch es ist besser den beiden Karten unterschiedliche Nummern zu geben.
Der Kabelbetreiber ist in meinem Fall KD.
Ich versuche auch einmal im Log zu sehen warum das passiert.

Danke schon einmal an alle die Ideen haben wie das zu fixen ist.......
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

sampler39 schrieb:
Zuerst werde ich Services anlegen was lt. dem Wiki bei benutzung des Loadbalancers Sinn machen soll.
Zum Vergrößern anklicken....
eigentlich genau anders herum. bei benutzung des load balancers machen services keinen sinn da zumindest über positive services vorgeschrieben wird "die karte kann auf jeden fall die und die sid!" der lb es also nicht mehr selber herrausfinden kann.. auch müsste man dann die services immer wieder updaten wenn neue sender dazu kommen also die karte kann bei positiven services nur die sender freischalten aber keine anderen.
also ich bin der meinung das es dann eher sinn machen würde negative (!)services zu nutzen für die caids die sich mit der karte überschneiden oder eben die sender die die karte nicht hell machen kann (zum beispiel einer kd karte die sky sender verbieten und anders herum der sky karte die kd sender verweigern)
dabei muss man aber beachten das unitymedia teilweise sowohl sie selbe caid ident als auch sid nutzt also die kann man leider nicht aussperren

sampler39 schrieb:
Dann hatte ich noch beiden Karten da gleich die selbe Gruppennummer gegeben. Lt. einigen Posts sollte das eigentlich kein Problem sein. Andere meinen jedoch es ist besser den beiden Karten unterschiedliche Nummern zu geben.
Zum Vergrößern anklicken....
kommt darauf an wie deine situation aussieht beziehungsweise du erreichen möchtest. die einzelnen gruppen dienen dazu zugriffs rechte der clients aufteilen zu können also zum beispiel hat der benutzer nur zugriff auf die reader der gruppe 1 aber nicht auf die reader der gruppe 2..
ich hab bei mir alle in einer group (ebenfals anbieter kd)

sampler39 schrieb:
Ich versuche auch einmal im Log zu sehen warum das passiert.
Zum Vergrößern anklicken....
das wäre auf jedenfall sinnvoll denn dafür ist das log gedacht
 
Zuletzt bearbeitet von einem Moderator:
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

Hi,

ich halte positive Services bei lokalen Karten für durchaus sinnvoll.
Bsp.: Ein Client fragt einen Sender mit einer unsauberen Anfrage ab und OScam antwortet z.B. mit einem (d02 irdeto_do_cmd [2] 90 00). Ohne Services ist der Sender danach erst einmal zu. Mit passenden Services hat der LB aber keine Wahl und fragt bei der nächsten Anfrage den Sender wieder ab, da die Services ein Freifahrtschein sind für den LB.
Bei externen Karten lasse ich auch den LB herausfinden was geht und was geht nicht.
Du hast aber Recht aragorn, das bedeute Arbeit am System, aber den Aufwand ist mir ein sauber funktionierendes System Wert.

Grüße

Kermit
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

was genau meinst du mit "unsaubere anfrage" ?

wenn die karte einen sender nicht auf kriegt hat das meisten gute gründe.. das kann von nicht vorhanden sein des senders auf der karte bis hin zu überlastung oder fehlkonfiguration reichen.. und für anfragen wo das ecm/cw nicht in ordnung ist gibts ja die whitelist

der lb macht auch nicht für immer dicht sondern fragt zwischen durch trotzdem den sender noch mal ab zumindest ist das bei mir so
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

Hi,

wenn ich wüßte woran es liegt, würde ich das Problem lösen*g*
Deswegen die Aussage "unsaubere Anfragen". Ich habe pro Tag so 1-2 Anfragen auf meiner S02, bei der die ECM Länge passt und auch sonst alles i.O. (die Anfragen werden nicht von OScam auf Grund der oscam.whitelist ausgefiltert) und trotzdem kommt ein Fehler zustande. Ich vermute im Moment es liegt an den Smargos - werde ich am Wochenende wahrscheinlich mal ersetzen und sehen was passiert.

Richtig der LB macht nicht für immer dicht und über den Parameter lb_reopen_mode kann ja auch gesteuert werden wie schnell.
Über die Services kannst du dies aber aushebeln.

Grüße

Kermit
 
AW: LB sperrt Kanäle / Server wird nicht weiter geshart

wenn man zum beispiel caid 1722 von kd hat aber auch clients die unitymedia abfragen kann man mit services nichts gegen "falsche anfragen" machen da sowohl caid und ident als auch die sid´s leider identisch sind.
gibt man über services also vor das die karte nur sky_film öffnen kann kommen trotzdem anfragen von unitymedia clients bezüglich um_sky_film auf die karte.. das problem hab ich bisher leider auch nicht beheben können da die jeweiligen clients auch kd-sky sender abfragen/bereitstellen
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

L
AU bei ORF und CANAL+ Austria (HD Austria) Parallelbetrieb auf zwei unterschiedlichen Smartcards
Antworten
5
Aufrufe
924
Lars_
L
L
Loadbalancing bei unterschiedlichen Entitlements
Antworten
7
Aufrufe
1K
DarkStarXxX
D
D
oscam server: gleichen Sender auf 2 VDRs gleichzeitig geht nicht - unterschiedliche Sender aber schon
Antworten
0
Aufrufe
844
DocStrange
D
M
Plugins VTi ChannelSwitch via OpenWebIF Streams funktioniert nicht
Antworten
5
Aufrufe
911
Mane1235
M
gelöst OScam Server welcher Proxy-Reader
Antworten
7
Aufrufe
3K
borsel
Menü
Anmelden
Registrieren
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…