Freezer durch Cache2 bei Oscam !

[Dr.Dish]

Hallo Gemeinde!
Vieleicht kann mir jemand weiterhelfen. Habe seit geraumer Zeit folgendes Problem. Zu unregelmäßigen Zeiten gibt es einen freezer. Habe jetzt durch den Log herausgefunden, was dazu führt, finde jedoch keine Lösung den Fehler auf dem Server zu beheben.

Logfile:
XXXX/XX/27 21:05:01 008XXXCC c
(ecm) XXXX (1722@000000/0000/0083/93:XXXXXXXXXXXXXXXXXXXXXXXC1FXX9): found (571 ms) by sky_d02(btun 1834) - Sky Cinema HD

XXXX/XX/27 21:05:01 008XXXCC c
(ecm) XXXX (1722@000000/0000/0083/93:XXXXXXXXXXXXXXXXXXXXXXXC1FXX9): cache2 (572 ms) by sky_d02(btun 1834) - Sky Cinema HD

Niemand anderes ist zu dieser Zeit auf diesem Sender. Diese Verdoppelung des ecm führt zu einem freezer.

Meine Configs lauten:

Spoiler: oscam.conf

[global]
disablelog = 1
logfile = /var/log/oscam/oscam.log
fallbacktimeout = 2600
nice = -1
maxlogsize = 2480
dropdups = 1
lb_mode = 1
lb_save = 100
lb_savepath = /var/log/loadbalancer/stat.log
failbantime = 60
failbancount = 3

[cccam]
port = XXXX
nodeid = DC77D80710CE1544
version = 2.1.4
reshare = 1

Spoiler: oscam.user

[account]
user = XXXX
pwd = XXXX
suppresscmd08 = 1
allowedprotocols = cccam
betatunnel = 1834.FFFF:1722
group = 1,2
cccmaxhops = 4
cccreshare = 0

Spoiler: oscam.server

[reader]
label = sky_d02
protocol = mouse
device = /dev/KDcard
autospeed = 0
caid = 1722
boxkey = 1122334455667788
ins7e11 = 15
fix07 = 0
readtiers = 0
detect = cd
mhz = 800
cardmhz = 600
ident = 1722:000000
group = 1
emmcache = 1,3,2,0
blockemm-unknown = 1

[reader]
label = G09_1
enable = 0
protocol = mouse
device = /dev/kd1
caid = 09C7
boxid = 12345678
boxkey = 6660A9AE55A4847B
ins7e11 = 15
detect = cd
ident = 09C7:000000
group = 2
emmcache = 1,1,2,0
blockemm-unknown = 1

 

[Tec-Hi]

Hi

kann keine Cache2 hier erkennen,
Cache2 wurde so aussehen:

Spoiler

User1 (099A&/0081/9D:A52AA688): found (77 ms) by XX 12 (P/1/2/2) - Sky Sport HD Germany
User2 (099A&/0081/9D:A52AA688): cache2 (48 ms) by XX 12 - Sky Sport HD Germany

die doppel Anfrage kommt, vermutlich von einem Billig Reci ?

HF

 

[Dr.Dish]

Denke nicht das es sich bei einer originalen Vu+duo2 um einen billig Receiver handelt. Vielleicht was mit Cache Delay in der oscam. Conf probieren?

 

[Tec-Hi]

Hi

gut dass, plötzlich Dein Logfile : cache2, auf weist, hast aber vergessen die Zeit runter zu edieren.

HF

 

[Bodo-1]

Ist der Client Receiver per LAN Kabel angebunden oder nutzt der evtl WLAN oder Dlan ?

gesendet von meinem Oneplus2

 

[janni1]

Hi.
ich denke @Bodo-1 ist auf der richtigen Spur
Cache2-Hits von ein und dem selben User mit dem selben ECM-Hash (Doppelanfragen), deuten auf Netzwerkprobleme hin.

 

[Dr.Dish]

Alles verkabelt ....

 

[janni1]

Hi,
und ist es denn im obigen Beispiel ein und derselbe User?
Wenn es so wäre, würde ich mal einen Ping von diesem parallel zum Server laufen lassen und bei einem Cache2-Hit auf packet loss oä. überprüfen

Beim nächste Log evtl. Username und ECM-Hash nicht xxxen.

 

[Dr.Dish]

Sry. Ja, ist der ein und selbe User. Dies ist ja das seltsame. Und es kommt bei mehreren Usern vor.

 

[janni1]

Hi,
also wie bereits erwähnt, deuten solche Cache2-Hits als Doppelanfrage meist auf Netzwerkprobleme hin.
Interessant wäre ein Log mit den Anfragen vor und nach dieser Doppelanfrage, dann würde man sehen, ob diese in den Zyklus (meist 7 oder 10sec.) passen.

 

[Dr.Dish]

Ca. Alle zehn Minuten taucht es auf. Versuche jetzt mal alle Switches pp. Zum testen abzubauen.

 

[lullu08]

Vielleicht gibt ein Client die Karte weiter und verwendet unterschiedlich Gruppen, an denen er weiter gibt. Ganz davon ab ist cache2 schon mal möglich, das der Wert höher ist, sollte jedoch zu keinem Fehler führen.

 

[Mick2009]

Häää ? Was soll das bitteschön für eine Aussage sein ??? Sorry aber Du solltest Dich mal mit Oscam auseinandersetzen und nicht immer Dinge raushauen die vorn und hinten nicht passen.

 

[lullu08]

Was von den 2 Sätzen hast denn nicht verstanden? Mir sieht der Post oben nicht nach einer Verdoppelung der ECM Zeit aus. Erstens ist es eine Nagra Karte, die eben mit ca 500ms arbeitet, zweitens bekommt der Daten aus Cache2. Cache1 währe der niedergelegte CW, daher ist es wohl eine wiederholte Abfrage, ich gehe aber eher von einer Gruppen-Splittung aus. Klar ist auch ein EMU Nachbau möglich, welches nicht sauber arbeitet.

Netzwerkfehler sind möglich, jedoch eher bei TCP so gut wie unmöglich, das diese Daten beschädigt angenommen werden. Zu alt (7 Sekunden+) können die Daten jedoch sein, Grund dafür können zum Beispiel Paket-returen oder fehlende Airtime (WLAN -DLAN usw) sein.

GGF mal Cyclecheck aktivieren und Cycle Check Caids: 1722 eintragen. Das lernt dann wie beim Tennis wer dran sein sollte.

 

[janni1]

Hi,
jetzt wird es dann doch etwas verworren hier!

Der CycleCheck prüft CWs in erster Linie auf Plausibilität (Wechsel von even und odd) und nicht auf ihr exaktes zeitliches Intervall, da dieses von Caid zu Caid unterschiedlich ist.
Selbst die Sids einer Caid, haben stellenweise unterschiedliche ECM-Intervalle.
Außerdem ist bei einem Cache2-Hit das CW noch nicht bekannt.

Bei so einer zeitgleiche Doppelanfrage eines Clienten mit selber ECM, ist die Anfrage meist irgenwo "hängen geblieben" und wurde vom Clienten erneut gestellt.
Beide ECM sind nach der "Blockade" dann fast gleichzeitig beim Server eingetroffen. Die schnellere ECM wurde zur Karte gelassen, die andere wurde ein "Cache2" (diese ECM ist bereits unterwegs).
Das CW wurde nach 571ms von der Karte geliefert und an den Client zurückgeschickt. Für die "langsamere" ECM 1ms später.
Da das Ganze durch die Verzögerung außerhalb des Timing liegt, kam es zu einem Freezer.

Aufschluss würde ein Log geben, bei welchem einige Anfragen des Users vor dem Cache2 mit dabei wären.

Da das hier beim TE bei mehrerer seiner Clienten auftritt, wird es vermutlich am eigenen Netz oder ggf. seiner Inet-Anbindung liegen.

Ein Gruppensplitting halte ich für unwahrscheinlich, weil es hier mehrere Clienten betrifft und weil es in hiesigen Fall Freezer auslöst,
die es sonst bei normalen Cache2-Hits beim Clienten nicht gäbe.
Außerdem würde die Anfrage schon beim Clienten selber als Cache2 beantwortet werden.

Ebenfalls halte ich einen EMU-Nachbau bei einer "Vu+duo2" für eher unwahrscheinlich.