Jump to content


Photo

Slow zap for CI

plugin

  • Please log in to reply
110 replies to this topic

Re: Slow zap for CI #61 Lost in Space

  • Senior Member
  • 875 posts

+69
Good

Posted 6 January 2016 - 19:10

I'm sorry I was not blaming you personally, as you at least tried and spent some tine on the case, but the whole OT discussion here in this thread started about wrong assumptions and we now try to find out on which side ;)


Edited by gutemine, 6 January 2016 - 19:11.


Re: Slow zap for CI #62 malakudi

  • PLi® Core member
  • 1,447 posts

+66
Good

Posted 6 January 2016 - 19:22

The 'thing' is working as it is since almost 1 year now.

 

When 'they' would revoke a leaked certifficate the original vendor will complain and ask for a new one and the circle would close ...

 

I investigated the process of getting a CI+ certificate for a PC based STB a couple of years ago. In order to get the certificates, the requirements were for a black box implementation (so PC implementation was out of question) and the penalties you agreed if the certificates were leaked were very high. So the original vendor cannot just "complain". Anyway, it is good they got leaked and maybe revocation from CI+ group side is not that easy after all.



Re: Slow zap for CI #63 athoik

  • PLi® Core member
  • 8,295 posts

+310
Excellent

Posted 6 January 2016 - 19:26

Having a look on code regarding "socket" the function responsible to "start the socket" is the following.
 
static bool start_camd_socket(struct ci_module *ci)
The name of the function "camd" is the obvious? Like /tmp/camd.socket..?

Edit1. Something that also might cause problems to non Dreamboxes.

static void camgr_set_demux_data(struct ci_session *session, int demux_idx, const uint8_t *tuner, size_t tuner_len, int enable_ci)
{
        struct camgr_data *d = session->private_data;
        const char demux_dest[] = "/proc/stb/tsmux/input%d";
        const char used_ci[] = "/proc/stb/tsmux/ci%d_input";
        const char buf_devname_old[][3] = { "B1", "B2" };   /* well strange! */
        const char buf_devname_new[][4] = { "CI0", "CI1" }; /* less strange! */
....
        if(stat("/sys/module/si2166b", &sb) == 0 && S_ISDIR(sb.st_mode)) {
                buf_devname[0] = buf_devname_new[0];
                buf_devname[1] = buf_devname_new[1];
        }
        else {
                buf_devname[0] = buf_devname_old[0];
                buf_devname[1] = buf_devname_old[1];
        }
....
We are using CI0 and CI1 only when /sys/module/si2166b directory exists. So better to use the following for testing in non Dreamboxes:

        buf_devname[0] = buf_devname_new[0];
        buf_devname[1] = buf_devname_new[1];
        /*if(stat("/sys/module/si2166b", &sb) == 0 && S_ISDIR(sb.st_mode)) {
                buf_devname[0] = buf_devname_new[0];
                buf_devname[1] = buf_devname_new[1];
        }
        else {
                buf_devname[0] = buf_devname_old[0];
                buf_devname[1] = buf_devname_old[1];
        }*/

Edited by athoik, 6 January 2016 - 19:38.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #64 Lost in Space

  • Senior Member
  • 875 posts

+69
Good

Posted 6 January 2016 - 19:46

You should REALLY start reading your own PLi git: dvbci.cpp

 

All this is already answered there ... sockets, tsmux ...


Edited by gutemine, 6 January 2016 - 19:48.


Re: Slow zap for CI #65 theparasol

  • Senior Member
  • 4,141 posts

+196
Excellent

Posted 6 January 2016 - 20:04

Think I found something!

 

#define CIPLUS_SERVER_SOCKET "/tmp/.listen.ciplus.socket"


Re: Slow zap for CI #66 Dimitrij

  • PLi® Core member
  • 6,918 posts

+230
Excellent

Posted 7 January 2016 - 18:23

root@et8500:~# ls -la /var/tmp/
drwxrwxrwt    3 root     root           220 Jan  7 18:06 .
drwxrwxrwt    7 root     root           140 Jan  1  1970 ..
srwxr-xr-x    1 root     root             0 Jan  7 17:49 .listen.camd.socket
srwxr-xr-x    1 root     root             0 Jan  7 17:49 .listen.ciplus.socket
drwx------    2 root     root            60 Jan  1  1970 .oscam
-rw-r--r--    1 root     root           118 Jan  7 17:50 autotimer.log
srwxrwxrwx    1 root     root             0 Jan  1  1970 camd.socket
srw-rw-rw-    1 root     root             0 Jan  7 17:50 hotplug.socket
srwxr-xr-x    1 root     root             0 Jan  7 17:50 mmi.socket
-rw-r--r--    1 root     root         13199 Jan  7 18:11 oscam.log
-rw-r--r--    1 root     root          1865 Jan  1  1970 smb.log


Lunix3-4K/VU+solo4k(thanks guys to gisclub.tv)


Re: Slow zap for CI #67 theparasol

  • Senior Member
  • 4,141 posts

+196
Excellent

Posted 7 January 2016 - 18:27

Here too, but I dont understand how it (should) work.

 

Radxnl coded it, I know from some years ago he was a regular here, very experienced, but haven't seen him around for quite some time.

On the other hand I see him committing on ATV, did he switch to another imagebuilding team?!



Re: Slow zap for CI #68 athoik

  • PLi® Core member
  • 8,295 posts

+310
Excellent

Posted 10 January 2016 - 09:09

The CI+ Helper for the DMM boxes with Original Images  is 100% Open Source and would work in ALL Images 
and the modification to the existing socket interface to support it would be less then half a page of code 
(only supporting sockets at /run/ca instead of /tmp).

...

And as i said already you need a small patch to your enigma2 to fill the socket these sources get their requests,
without these there is NOTHING to test with PLi, so please first do your reading and understanding before your post nonsense again ...

...

This is a complete CI  handler in a standalone binary fed via a socket, it even works without the cI+ garbage if you want it that way.

...

And I can read the changes you committed to YOUR e2 to support the CI garbage for other boxes which hide the certification part in their drivers. 
A simple compare will tell you the answer ... 


...

PS: You should really try it out first in an Image where it works, before you ask such basic questions ... 
Then you can use the auth files it produces with your test bed ...  but now you got enough help by an incompetent person ...
@gutemine,

Trying an image where it works, a friend installed NN on his dm7020hd, but his CI+ Fransat is not working yet.

Any idea what is wrong? The authentication part? (I see there is no /etc/enigma2/ci_auth_FRANSAT_1.bin created)

....
[2016-01-09 22:59:00] state 1
[2016-01-09 22:59:00] resource_action 0x40472c
[2016-01-09 22:59:00] ccmgr_doAction()
[2016-01-09 22:59:00] -----------------------------------------------------
92 07 00 00 8c 10 01 00 06
[2016-01-09 22:59:00] -----------------------------------------------------
90 02 00 06 9f 90 01 00
[2016-01-09 22:59:00] established state
[2016-01-09 22:59:00] normal state
[2016-01-09 22:59:00] resource receive
[2016-01-09 22:59:00] content_control 9f 90 01
[2016-01-09 22:59:00] cannot open /etc/enigma2/ci_auth_FRANSAT_1.bin
[2016-01-09 22:59:00] -----------------------------------------------------
90 07 00 06 9f 90 02 01 01
....
[2016-01-09 22:59:08] resource receive
[2016-01-09 22:59:08] mmi_receive()
[2016-01-09 22:59:08] >>> 9f 88 09
[2016-01-09 22:59:08] -----------------------------------------------------
02 9f 88 03 13 0b 49 6e 66 6f 72 6d 61 74 69 6f 6e 20 43 49 50 6c .....
Information CIPlus

Pressez sur OK ou Exit pour quitter
Authentification en cours.
Veuillez patienter...
[2016-01-09 22:59:08] >>>> 9f 88 09
.....
With a working CI+ module we will try to (fill the blanks and) make it work on OpenPLi.

You mention several times that we should support the communication socket at /var/run/ca and also
that can work without CI+ "grarbage".

So even without commit: https://github.com/O...a9c78058ef57da4
there is just the socket thing need to be added, right?

Attached Files


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #69 Lost in Space

  • Senior Member
  • 875 posts

+69
Good

Posted 10 January 2016 - 11:52

I already said that based on the reaction I should not offer any support, and I'm not the perfect person either, and as the coders seem to prefere to stay in the dark you probably have to help yourself. The code is readable and documented. Partly the coding is not that bright and a little bit dirty, but who cares if it works.

 

Fransat is NOT a good test case, as even the other boxes have problems authentificating it. The code is not complete in the sense that it handles all prossible answers from all modules. Aagain if you would READ instead of asking you would find a thread in teh NN2 board listing modules that work nicely like Sky, HD+, ORF/AustriaSAT Iredeto, UPC, Conax,..

 

So the easiest testbed for developing and testing would be to get an HD+ Modul with a 1 year subscription card for 79 EUR via Amazon and see what happens when you insert it with a running binary.

 

But this is just the recommendation of a moron :huh:

 

And yes there is NO need for all the helper code, except that you have to feed it properly more like the normal camembert.


Edited by gutemine, 10 January 2016 - 11:56.


Re: Slow zap for CI #70 nikolasi

  • Member
  • 22 posts

+7
Neutral

Posted 23 January 2016 - 14:24

Here too, but I dont understand how it (should) work.

 

Radxnl coded it, I know from some years ago he was a regular here, very experienced, but haven't seen him around for quite some time.

On the other hand I see him committing on ATV, did he switch to another imagebuilding team?!

if you bild the image from the ATV gits ci + does not work does not see modules Thou downloaded the image from the site ready ATV then ci + works



Re: Slow zap for CI #71 athoik

  • PLi® Core member
  • 8,295 posts

+310
Excellent

Posted 28 January 2016 - 10:37

The latest version of ci-plus (ci_2_1_r2.tar) I guess includes a fix for receivers not supporting extended cw.

int descrambler_set_key(int index, int parity, unsigned char *data)
{
+#ifdef OLD
+ struct ca_descr_s d;
+ d.index = index;
+ d.parity = parity;
+ memcpy(d.cw, data + (parity * 8), 8);
+ if (ioctl(desc_fd, CA_SET_DESCR, &d))
+ printf("CA_SET_DESCR\n");
+#else
+
struct ca_descr_data d;

d.index = index;
@@ -48,6 +67,7 @@ int descrambler_set_key(int index, int parity, unsigned char *data)

if (ioctl(desc_fd, CA_SET_DESCR_DATA, &d))
printf("CA_SET_DESCR_DATA\n");
+#endif

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #72 Erik Slagter

  • PLi® Core member
  • 45,926 posts

+513
Excellent

Posted 29 January 2016 - 12:21

I guess we will hear it when it works ;)


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.

Re: Slow zap for CI #73 Lost in Space

  • Senior Member
  • 875 posts

+69
Good

Posted 31 January 2016 - 12:40

I don't think that the real developers like such a lean back approach, but maybe I'm wrong.



Re: Slow zap for CI #74 gorski

  • Senior Member
  • 1,700 posts

+46
Good

Posted 31 January 2016 - 16:59

...laid-back...? :D

 

Not interested, more like... which is legitimate... ;)


<span style='font-family: comic sans ms,cursive'>"Enlightenment is man's emergence from his self-incurred immaturity. Immaturity is the inability to use one's own understanding without the guidance of another. This immaturity is self-incurred if its cause is not lack of understanding, but lack of resolution and courage to use it without the guidance of another. The motto of enlightenment is therefore: Sapere aude! Have courage to use your own understanding!</span><br /> <br /><span style='font-family: comic sans ms,cursive'>Laziness and cowardice are the reasons why such a large proportion of men, even when nature has long emancipated them from alien guidance..." I. Kant, "Political writings" (1784)</span><br /> <br /><span style='font-family: comic sans ms,cursive'><a class='bbc_url' href='<a class='bbc_url' href='http://eserver.org/p...lightenment.txt'>http://eserver.org/p...ent.txt</a>'><a class='bbc_url' href='http://www.english.upenn.edu/~mgamer/Etexts/kant.html</a>'>http://www.english.upenn.edu/~mgamer/Etexts/kant.html</a></a> - the jolly text on Enlightenment, at the basis of Modernity...</span>

Re: Slow zap for CI #75 athoik

  • PLi® Core member
  • 8,295 posts

+310
Excellent

Posted 3 February 2016 - 21:57

@gutemine,

On dm7020hd running strace on enigma (with newnigma) there is nothing like socket connecting under /var/run/ca.
 
# strace -s 1000  /usr/bin/enigma2 2>&1 | grep "/var/run/ca"
open("/var/run/ca", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 42
stat64("/var/run/ca/.", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
stat64("/var/run/ca/..", {st_mode=S_IFDIR|0755, st_size=380, ...}) = 0
stat64("/var/run/ca/dreamciplus1.pid", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
inotify_add_watch(35, "/var/run/ca", IN_CREATE|IN_DELETE) = 2
write(2, "[eFileWatch] Now watching /var/run/ca\n", 38[eFileWatch] Now watching /var/run/ca
...
write(2, "[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been deleted\n", 68[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been deleted
write(2, "[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been created\n", 68[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been created
write(2, "[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been deleted\n", 68[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been deleted
write(2, "[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been created\n", 68[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been created
write(2, "[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been deleted\n", 68[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been deleted
write(2, "[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been created\n", 68[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been created
write(2, "[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been deleted\n", 68[eFileMonitor] File {/var/run/ca/dreamciplus0.pid} has been deleted
If you run the same (strace..) on your receiver with the working HD+ you see something different?

Edited by athoik, 3 February 2016 - 21:58.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #76 Lost in Space

  • Senior Member
  • 875 posts

+69
Good

Posted 4 February 2016 - 19:18

Look, I already said that the connection is established even without a CI in the Modul slot, BUT you have to start the helper binary before enigma2, to allow it to grab the CI Module devices before enigma2 gets them. THEN enigma2 will recognize that it creates sockets and establishes communication. MMI socket will also connect und you have new entries in the menu representing the slots or modules found

 

When you then insert a module the helper will become active and start authentification, and when finished e2 will send all necessary information (like what channel, it shows, what tuner and demux it is going to use, etc ....).

 

If there is nothing to say ... they behave like an old couple - they just watch TV without talking to each other  ... and the man keeps the remote control/device :-)


Edited by gutemine, 4 February 2016 - 19:20.


Re: Slow zap for CI #77 athoik

  • PLi® Core member
  • 8,295 posts

+310
Excellent

Posted 4 February 2016 - 20:02

Hehe, I really like your answer, keep it like this. Instructive but funny too.

 

Actually I've seen that dream_ci_plus starts on enigma2_pre_start, so I leave them out and started ci_plus manually. I had 3 ssh consoles opened, one to run ci_plus, one to run enigma2 with strace and one more for other commands.

 

/usr/bin/enigma2_pre_start_ciplus.sh:/sbin/start-stop-daemon -S -b -n dreamciplus0 -x /usr/bin/dream_ci_plus -- /dev/ci0
/usr/bin/enigma2_pre_start_ciplus.sh:/sbin/start-stop-daemon -S -b -n dreamciplus1 -x /usr/bin/dream_ci_plus -- /dev/ci1

 

So dreamciplus has the control, but I guess since Fransat is not supported (like you said before) the is nothing to say with enigma2. So enigma2 never starts the socket in /var/run/ca/

 

[2016-02-03 21:21:12] open response
[2016-02-03 21:21:12] -----------------------------------------------------
92 07 00 00 8d 10 01 00 05 
[2016-02-03 21:21:12] -----------------------------------------------------
92 07 00 00 8d 10 01 00 05 
[2016-02-03 21:21:12] state 1
[2016-02-03 21:21:12] resource_action 0x4065a0
[2016-02-03 21:21:12] host_lac_doAction()
[2016-02-03 21:21:12] unknown state
[2016-02-03 21:21:12] -----------------------------------------------------
....
92 07 00 00 8c 10 01 00 06 
[2016-02-03 21:21:13] -----------------------------------------------------
90 02 00 06 9f 90 01 00 
[2016-02-03 21:21:13] established state
[2016-02-03 21:21:13] normal state
[2016-02-03 21:21:13] resource receive
[2016-02-03 21:21:13] content_control 9f 90 01
[2016-02-03 21:21:13] cannot open /etc/enigma2/ci_auth_FRANSAT_0.bin
[2016-02-03 21:21:13] -----------------------------------------------------
....
[2016-02-03 21:21:13] rechecking ...
[2016-02-03 21:21:13] HOSTID: 4Exxxxxxxxx
[2016-02-03 21:21:15] req element 13
[2016-02-03 21:21:15] req element 17
[2016-02-03 21:21:15] req element 15
[2016-02-03 21:21:15] req element 7
[2016-02-03 21:21:15] -----------------------------------------------------
....
[2016-02-03 21:28:58] -----------------------------------------------------
9f 88 09 65 02 9f 88 03 06 43 49 50 6c 75 73 9f 88 03 01 20 9f 88 03 18 50 72 65 73 73 20 4f 4b 20 6f 72 20 45 78 69 74 20 74 6f 20 51 75 69 74 9f 88 03 23 41 75 74 68 65 6e 74 69 63 61 74 69 6f 6e 20 70 72 6f 63 65 73 73 20 69 6e 20 70 72 6f 67 72 65 73 73 2e 9f 88 03 0e 50 6c 65 61 73 65 20 77 61 69 74 2e 2e 2e 
[2016-02-03 21:28:58] resource receive
[2016-02-03 21:28:58] mmi_receive()
[2016-02-03 21:28:58] >>> 9f 88 09
[2016-02-03 21:28:58] -----------------------------------------------------
02 9f 88 03 06 43 49 50 6c 75 73 9f 88 03 01 20 9f 88 03 18 50 72 65 73 73 20 4f 4b 20 6f 72 20 45 78 69 74 20 74 6f 20 51 75 69 74 9f 88 03 23 41 75 74 68 65 6e 74 69 63 61 74 69 6f 6e 20 70 72 6f 63 65 73 73 20 69 6e 20 70 72 6f 67 72 65 73 73 2e 9f 88 03 0e 50 6c 65 61 73 65 20 77 61 69 74 2e 2e 2e 
CIPlus
 
Press OK or Exit to Quit
Authentication process in progress.
Please wait...
 

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #78 Lost in Space

  • Senior Member
  • 875 posts

+69
Good

Posted 5 February 2016 - 19:03

You will not get further with that Module, as already pointed out, so it is not a good testbed ...

 

But you don't need to hide the HOSTID - this is a randomly generated number different on every authentification run.



Re: Slow zap for CI #79 athoik

  • PLi® Core member
  • 8,295 posts

+310
Excellent

Posted 5 February 2016 - 20:16

The socket under /var/run/ca I think is used to receive the caPMT.

So if there is a successful authentication then socket also starts to listen for caPMT.

But currently there is nothing that connects under /var/run/ca sockets.

A quick hack might be to symlink the /tmp/camd.socket to /var/run/ca socket and hopefully receive also caPMT.

Or change enigma2 to check of /var/run/ca socket exists and start sending caPMT events.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #80 betacentauri

  • PLi® Core member
  • 6,185 posts

+273
Excellent

Posted 20 February 2016 - 23:35

[2016-02-20 23:32:49] resource receive
[2016-02-20 23:32:49] mmi_receive()
[2016-02-20 23:32:49] >>> 9f 88 0c
[2016-02-20 23:32:49] -----------------------------------------------------
04 9f 88 03 12 05 48 44 2b 20 43 49 20 50 6c 75 73 20 4d 6f 64 75 6c 9f 88 03 01 05 9f 88 03 01 05 9f 88 03 2c 05 49 68 72 20 43 49 2b 20 45 6d 70 66 61 6e 67 73 67 65 72 e4 74 20 77 69 72 64 20 61 75 74 68 65 6e 74 69 66 69 7a 69 65 72 74 2e 9f 88 03 2d 05 44 69 65 73 65 72 20 56 6f 72 67 61 6e 67 20 6b 61 6e 6e 20 6d 65 68 72 65 72 65 20 4d 69 6e 75 74 65 6e 20 64 61 75 65 72 6e 2e 20 9f 88 03 0e 05 28 48 69 6e 77 65 69 73 20 31 39 30 29 9f 88 03 29 05 5b 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 49 20 20 20 20 20 20 20 20 20 20 20 20 20 5d 20 36 30 25 
HD+ CI Plus Modul


Ihr CI+ Empfangsgert wird authentifiziert.
Dieser Vorgang kann mehrere Minuten dauern. 
(Hinweis 190)
[IIIIIIIIIIIIIIIIIIIII             ] 60%
[2016-02-20 23:32:49] >>>> 9f 88 0c
[2016-02-20 23:32:49] -----------------------------------------------------

...
...
...

[2016-02-20 23:33:02] resource receive
[2016-02-20 23:33:02] mmi_receive()
[2016-02-20 23:33:02] >>> 9f 88 0c
[2016-02-20 23:33:02] -----------------------------------------------------
02 9f 88 03 12 05 48 44 2b 20 43 49 20 50 6c 75 73 20 4d 6f 64 75 6c 9f 88 03 01 05 9f 88 03 01 05 9f 88 03 2d 05 41 75 74 68 65 6e 74 69 66 69 7a 69 65 72 75 6e 67 20 64 65 73 20 43 49 2b 20 45 6d 70 66 61 6e 67 73 67 65 72 e4 74 73 20 77 61 72 9f 88 03 0d 05 65 72 66 6f 6c 67 72 65 69 63 68 2e 
HD+ CI Plus Modul


Authentifizierung des CI+ Empfangsgerts war
erfolgreich.
[2016-02-20 23:33:02] >>>> 9f 88 0c
[2016-02-20 23:33:02] -----------------------------------------------------

Or in english "authentification was successful"

 

:D


Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04





3 user(s) are reading this topic

0 members, 3 guests, 0 anonymous users