Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Oscam Versuch V13/NDS

    Nobody is reading this thread right now.
AW: Oscam Versuch V13/NDS

in einem ersten Schritt mach ich erstmal eine Quick&Dirty Umsetzung eines cardclients auf PC-Basis/FTDI-Usb-Serial (wg.76800 b/s)/Season-Interface im Unicam, als proof-of-concept ob das kritische Timing überhaupt machbar ist. Erst wenn das sauber läuft, werd ich mich an die Oscam-Integration ranmachen.
BTW, hast du irgendwelche Infos zu dem SOC der auf dem MAtrix-Einschub vebaut ist-es geht mir um die Möglichkeiten der integrierten Uarts...
 
AW: Oscam Versuch V13/NDS

Hi,

eine Beobachtung "Verhalten Diablo>Oscam mit Gbox Protocoll" möchte ich euch noch mitteilen,
Diablo 1.3 kann der Delayer bei NDS gegen null gesetzt und die bekannten Störungen treten nicht auf.
Der MCA Test steht noch aus "oscam>oscam mit Gbox".


mfg
60plus
 
AW: Oscam Versuch V13/NDS

@KixKa
Könnte man nicht gleich auf Raspberry mit Season-Interface ein eigenes System aufbauen?
Wäre dann zu allen TV's kompatibel.
 
AW: Oscam Versuch V13/NDS

@60plus : Kannst Du das mal etwas elaborieren was Du meinst ?

P.S.: Entsprechende Configs zum vergleich hier posten bitte, ich habe alle Karten, und Module, so dass ich corosstesten kann.
 
AW: Oscam Versuch V13/NDS

Ich quote mal aus dem Anderen Beitrag der hier oberhalb verlinkt is, weil es ja hierher gehoert :

etwa 400ms-500ms zwischen CW-schreiben im Oscam und write auf /proc/mio. Da dürfte eines der Probleme liegen-wenn der vorrausgehende Datenverkehr über /proc/mio nicht zwingend notwendig sein sollte (da ich keinerlei Kenntnisse vom Potokoll habe)

Ja den MCAM task haben wir schon lange im Verdacht. Deswegen auch die Intention es ohne den zu versuchen, allerdings ist die Frage, das kann auch vom Handschaeke des CAMs selber herruehren, oder eben auch von schlechter Programmierung, die a apparent ist. Jedenfalls sind 500ms wenn man alle anderen delays dazurechnet eindeutig zu viel, es gibt ja einiges an latency im path, 180 ~300 ms auf dem OSCAM Server, Network latency mit Handshakes, OSCAM auf dem MCA (auch nochmal gut und gerne und vor allem variable 100~400 ms), ab ca. 1200 ms delay kommt es auch bei allen anderen Systemen (also z.B. ProgDVB + Acamd + selber OSCAM Server) zu den Freezern...

/Gompf
 
AW: Oscam Versuch V13/NDS

Die Aussetzer haben nichts mit dem verwendeten Protokoll zu tun.


Ganz so ist es nun aber doch nicht, auch wenn es sicherlich nicht die root cause des Problems ist, denn die unterschiedlichen Protokolle haben durchaus auch selbst eine verschiedene Latenz. Sprich was 60Plus ueber das Diablo sagt kann schon stimmen, deswegen interessiere ich mich auch fuer die Konfigs, denn mit meinem Setup kann man das genau vermessen und dann sehen um wieviel Zeit es sich eigentlich dreht (also ich meine eine Vergleichsmessung mit dem Diablo)

/Gompf
 
AW: Oscam Versuch V13/NDS

Für geringe Latenz würde ich dir das Camd35 (UDP) -Protokoll empfehlen ;-) damit klappt V13 sogar übers Inet...
 
Zuletzt bearbeitet von einem Moderator:
AW: Oscam Versuch V13/NDS

Ja den MCAM task haben wir schon lange im Verdacht. Deswegen auch die Intention es ohne den zu versuchen, allerdings ist die Frage, das kann auch vom Handschaeke des CAMs selber herruehren, oder eben auch von schlechter Programmierung, die a apparent ist.
Völlig außer acht gelassen sind bisher die Latenzen in der Senderichtung, sprich inwieweit bereits der ECM-Empfang vom CAM-Modul schon verzögert ist. Wenn da nochmal 300-400 ms durch die grottige Programmierung dazukommen, kann das prinzipiell nie richtig funktionieren. Eine weitere Möglichkeit besteht in der verwendeten Protokollart zwischen CAM und MCA, wenn dass ein simples Polling-Protokoll ist, kommen da noch weitere Seiteneffekte dazu...
 
AW: Oscam Versuch V13/NDS

@KixKa
Könnte man nicht gleich auf Raspberry mit Season-Interface ein eigenes System aufbauen?
Wäre dann zu allen TV's kompatibel.
Darauf wirds wohl hinauslaufen. Ich für meinen Teil hab mich vom MCA selbst bereits wieder verabschiedet, da sind mir zuviele Unzulänglichkeiten drin. u.a. Probleme mit Erkennung im TV (CI-Interface)usw. Als reines Wifi-Cardeinschub ist mir das Ding zu wenig dokumentiert. Da sind mir RPI mit Wlan-USB-Stick und Season viel angenehmer. Ob der Client überhaupt was wird, steht noch in den Sternen. Nach Sichtung des Codes sind mir da einige Probleme aufgefallen, die nicht so einfach zu bewältigen sind:
-> die verschlüsselung allgemein ist eher verwirrend. jede Menge Bitschiebereien, Byte-Nibble Tauschereinen suw.
-Camcrypt-Aushandlung über InsBC/BE: Das steckt ein lonmult/partialmod drin, das sieht nach asymetrischer Verschlüsselung aus (ähnlich RSA), d.h. mangels Kentniss des Verschlüsselungskeys keine Chance auf echte Nachbildung. Abhilfe: immer mit festen Keys arbeiten und eine geloggtes Antwort BC/BE nutzen, dann sind die (AES-)Keys bekannt (das erinnert mich irgendwie an Irdeto/BC 0384 ... ;-) )
-Laufende ECMs:
-> Verschlüsselung scheint eine Mischung aus AES, Hash-Tabelle und Bitschieberei zu sein, mit zusätzlichem Störfaktor eines fortlaufenden Wertes. Augenscheinlich ist das Verfahren symetrisch aufgebaut (damit auch in Verschlüsselungsrichtung nachbildbar)-muss noch getestet werden.
-> CW-Postprocessing: Diese Art Zusatzverschlüsselung wird über den ECM-Header aktiviert-den ich an der Kartenschnittstelle nicht zur Verfügung habe. Postprocessing wird dann also nie durchgeführt und ich schicke die Antwort nativ an mein CAM (wo dann das Postprocessing gemacht wird, da mein CAM den echten ECM ja kennt...). Sollte so kein Problem sein, könnte aber zu Problemen mit dem Cache im Cardserver führen
-> bei NDS stecken in den ECMs wohl keine CW-Paare, sondern nur einzelne CWs, Die Zuordnung Even/Odd geschieht über den ECM-Header (80/81), das gerade nicht aktive CW scheint immer genullt zu sein. Daraus ergibt sich eine Art ECM-"Guessing", das erst beim nächsten Durchlauf greift, Außerdem muss ich die Manipulationen durch den Cardserver (Vertausch Even/Odd) für dem Versenden der INs54-Antwort wieder rückgängig machen (sollte aber dank der Nullung des gerade nicht aktiven CWs möglich sein). Was noch zu testen ist: Das Verhalten des ECM/CW-Caches im Cardserver, wenn in der ECM-Anfrage nur konstante SID-Pids und ECM-Pids enthalten sind (das könnte man aber durch nen Patch/Zusatzfunktion im Oscam in den Griff bekommen) Da steckt ein Denkfehler drin, muss nochmal drüber nachdenken...evt. gehts gar nicht...
 
Zuletzt bearbeitet:
AW: Oscam Versuch V13/NDS

@KixKa : Wenn dass kann man wohl nur miteinem orginal Matrix und einem Season Interface testen, wenn das geht liegt es in der grottingen Programmierung des MCA. Aber selbst wenn es 400 ms sind , geht das noch wenn alles ander zusammen mit dem in unter 1 Sec geht.

Das Problem is das ich es bis heute nicht geschafft habe ein accurates, syncrones Timing auf dem MCA hinbekommen habe um das wirklich genau vermessen zu koennen, aber ich habe das selbe Programm (einmal mit MCA und einmal mit ACAMd/ProgDVB) , beide ueber V13 dekodiert auf den selben OSCAM server gefahren, was belegte das das MCA definitiv langsamer ist, da es alle CWs immer aus dem cache bekam.


/Gompf

P.S.: das NDS decoding geht schon, das passt schon...
 
Zuletzt bearbeitet:
AW: Oscam Versuch V13/NDS

@Gompf
oscam server:

[reader]
label = Diabloalt_gbox
protocol = gbox
device = ip vom Diablo,8025
user = gbox_user
password = 12345678
gbox_max_distance = 7
gbox_max_ecm_send = 5
gbox_reshare = 7
group = 1
auprovid = 0009C4

oscam user:

[account]
user = gbox_user
caid = 1830,1702,1833,0648,09C4,0D05,0500 l
group = 1,2

oscam config:

[gbox]
hostname = ip vom oscam server
port = 8020
my_password = 87654321



cwshare.cfg Diablo kommt mit inden gbox ordner

# allow maximum 06 share level for recieved card data
#I: { 06 }

# 01 repeat EMM's
# 00 consider every EMM only once
# 01 restart pid on overflow
# 1* reset ENX on every channel change
# *1 check/reset ENX freezes on FTA
# *2 check/reset ENX freezes on PayTV
# *3 check/reset ENX freezes on FTA and PayTV
# 00 write nothing in atack.txt
# 01 write into atack.txt: password is wrong
# 02 write into atack.txt: ID unknown
# 04 write into atack.txt: IP is wrong
# 08 write into atack.txt: port is worng
# 10 write into atack.txt: share.stat
# 20 create online.log for online/offline logging
# 3F write everything. (combine bits for other combinations)
# 4000 send ecm again after 4 Seconds if no reply.
# 6000 resync decode after 6 Seconds if net decode failed
#N: { 00 01 03 1F 4000 6000 }

# Send ECM's at maximum 5 cards (please use this as default)
X: { 05 }

# Send ECM's in any case to these card ID's, even they are more then X:
# some examples ...
#G: { 17020000 1234 }
#G: { 18330000 1234 }
#G: { 18300000 1234 }
#G: { 09c4A000 1234 }


# For W: please read the cwshare.txt, here only some examples
# use card 1 only for the following pids
#W: { 01 02 02 } 1022 100A 100B 102B 1009 101D 1029 1014 1011 101B
# don't use card 2 for the following pids
#W: { 02 03 03 } 1008 1016

# S: is the same as W:, just using the SID instead of the ECMPID

# cwshare.cfg --- dbox1 --- Internet und Lokales Netzt
#
# password
#M: { mydbox2.homeip.net { AA242456 }}

# Internet Friends port range password cod
#D: { friend1.homeip.net { 8010 8010 { B142AB11 { 5 5 }}}}
#D: { friend2.homelinux.net { 8010 8010 { 81BFF901 { 5 5 }}}}

# other local boxes
#D: { 192.168.0.51 { 8020 8020 { AB333441 { 5 5 }}}}
#D: { 192.168.0.52 { 8020 8020 { BA334B24 { 5 5 }}}}

M: { IP Diablo { 12345678 }}
D: { IP oscam server { 8025 8020 { 87654321 { A3 A3 }}}}

Die Passwörter sind Beispiele


mfg
60plus
 
Zurück
Oben