Skip to contentSkip to conversation

ngene CI problems

DISCUSSION Martin Vidovic 4 participants 18 messages Mar 7, 2011 – May 22, 2011 Media (V4L/DVB)

lore
Share & tools
lore

Martin Vidovic

author
#0 lore raw

Hi all!

I'm trying to make the DVB_DEVICE_SEC approach work, however I'm experiencing certain problems with the following setup:

Software:
Linux 2.6.34.8 (vanilla)
drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/

Hardware:
Digital Devices CineS2 + CI Module

Problems:

- Packets get lost in SEC device:

I write complete TS to SEC, but when reading from SEC there are discontinuities on the CC.

- SEC device generates NULL packets (ad infinitum):

When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready.

- SEC device blocks on CAM re-insertion:

When CAM is removed from the slot and inserted again, all read() operations just hang. Rebooting resolves the problem.

- SEC device does not respect O_NONBLOCK:

In connection to the previous problem, SEC device blocks even if opened with O_NONBLOCK.

Best regards,
Martin Vidovic

#1 lore raw
Quoted 30 lines

Hi all!

I'm trying to make the DVB_DEVICE_SEC approach work, however I'm experiencing certain problems with the following setup:

Software:
Linux 2.6.34.8 (vanilla)
drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/ <http://linuxtv.org/hg/%7Eendriss/v4l-dvb/>

Hardware:
Digital Devices CineS2 + CI Module

Problems:

- Packets get lost in SEC device:

I write complete TS to SEC, but when reading from SEC there are discontinuities on the CC.

- SEC device generates NULL packets (ad infinitum):

When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready.

- SEC device blocks on CAM re-insertion:

When CAM is removed from the slot and inserted again, all read() operations just hang. Rebooting resolves the problem.

Quoted 7 lines

- SEC device does not respect O_NONBLOCK:

In connection to the previous problem, SEC device blocks even if opened with O_NONBLOCK.

Best regards,
Martin Vidovic

Hi,

Running a bunch of test with gnutv and a DuoFLEX S2.

I saw the same problem concerning the decryption with a CAM.

I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO.

I would run gnutv like 'gnutv -out stdout channelname > /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -' Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over.

Anyone using ngene based card with a CAM running successfully ?

--
Issa

#2 lore raw
Quoted 47 lines · Issa Gorissen
Quoted 30 lines

Hi all!

I'm trying to make the DVB_DEVICE_SEC approach work, however I'm experiencing certain problems with the following setup:

Software:
Linux 2.6.34.8 (vanilla)
drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/ <http://linuxtv.org/hg/%7Eendriss/v4l-dvb/>

Hardware:
Digital Devices CineS2 + CI Module

Problems:

- Packets get lost in SEC device:

I write complete TS to SEC, but when reading from SEC there are discontinuities on the CC.

- SEC device generates NULL packets (ad infinitum):

When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready.

- SEC device blocks on CAM re-insertion:

When CAM is removed from the slot and inserted again, all read() operations just hang. Rebooting resolves the problem.

Quoted 7 lines

- SEC device does not respect O_NONBLOCK:

In connection to the previous problem, SEC device blocks even if opened with O_NONBLOCK.

Best regards,
Martin Vidovic

Hi,

Running a bunch of test with gnutv and a DuoFLEX S2.

I saw the same problem concerning the decryption with a CAM.

I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO.

Quoted 6 lines

I would run gnutv like 'gnutv -out stdout channelname > /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -' Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over.

Anyone using ngene based card with a CAM running successfully ?

Hi Ralph,

Could you enlighten us on the following matter please ?

I took a look inside cxd2099.c and I found that the method I suspect to read/write data from/to the CAM are not activated.

static struct dvb_ca_en50221 en_templ = {
.read_attribute_mem = read_attribute_mem,
.write_attribute_mem = write_attribute_mem,
.read_cam_control = read_cam_control,
.write_cam_control = write_cam_control,
.slot_reset = slot_reset,
.slot_shutdown = slot_shutdown,
.slot_ts_enable = slot_ts_enable,
.poll_slot_status = poll_slot_status,
#ifdef BUFFER_MODE
.read_data = read_data,
.write_data = write_data,
#endif

};

Methods read_data and write_data are both enclosed inside the BUFFER_MODE test. Also, current version of struct dvb_ca_en50221 does not provide for read_data/write_data methods, right ?

If I recall right, you once told that you manage to test the CAM
<http://www.mail-archive.com/[email protected]/msg22196.html>,
how did you do ?

Thx
--
Issa

author
#4 lore raw
In reply to Issa Gorissen

Hi Issa,

Quoted 2 lines

Running a bunch of test with gnutv and a DuoFLEX S2.

I have a DuoFlex S2 running with CI, but not nGene based (it's attached to Octopus card - ddbridge module).

Quoted 5 lines

I would run gnutv like 'gnutv -out stdout channelname > /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -' Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over.

I suspect the problem is that reads/writes are not aligned to 188 bytes with such invocation of commands. Maybe if you tried replacing 'cat' and '>' with 'dd' (bs=188). Other important thing seems to be, to read from the caio0 fast enough or real data is overwritten with null packets (haven't proved it, but it looks this way on nGene).

Hope this helps.

Best regards,
Martin Vidovic

#5 lore raw
Quoted 19 lines · Martin Vidovic

Hi Issa,

Quoted 2 lines

Running a bunch of test with gnutv and a DuoFLEX S2.

I have a DuoFlex S2 running with CI, but not nGene based (it's attached to Octopus card - ddbridge module).

Quoted 7 lines

I would run gnutv like 'gnutv -out stdout channelname > /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -'
Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over.

I suspect the problem is that reads/writes are not aligned to 188 bytes with such invocation of commands. Maybe if you tried replacing 'cat' and '>' with 'dd' (bs=188). Other important thing seems to be, to read from the caio0 fast enough or real data is overwritten with null packets (haven't proved it, but it looks this way on nGene).

Quoted 4 lines

Hope this helps.

Best regards,
Martin Vidovic

Okay, but have you managed to decode any channel yet ?

I find some code odd, maybe you can take a look as well...

init_channel in ngene-core.c creates the device sec0/caio0 with the struct ngene_dvbdev_ci. In ngene-dvb.c you can see that this struct declares the methods ts_read/ts_write to handle r/w operations on the device sec0/caio0.

Now take a look at those methods (ts_read/ts_write). I don't see how they 'connect' to the file cxd2099.c which contains the methods handling the i/o to the cam.

--
Issa

author
#6 lore raw

Hi,

Quoted 2 lines

Okay, but have you managed to decode any channel yet ?

Yes, I managed to descramble programmes without any problem.

Quoted 10 lines

I find some code odd, maybe you can take a look as well...

init_channel in ngene-core.c creates the device sec0/caio0 with the struct ngene_dvbdev_ci. In ngene-dvb.c you can see that this struct declares the methods ts_read/ts_write to handle r/w operations on the device sec0/caio0.

Now take a look at those methods (ts_read/ts_write). I don't see how they 'connect' to the file cxd2099.c which contains the methods handling the i/o to the cam

They don't connect explicitly. Transfers are done implicitly through nGene ring-buffers. See demux_tasklet(). CXD code seems to be used only for CAM commands and setup (only) of data transfers.

Unfortunately, I don't have nGene (and CXD) chip documentation, so I stopped solving the problem myself. I don't want to write software by guessing how HW works.

Best regards,
Martin Vidovic

#7 lore raw
Quoted 11 lines · Martin Vidovic

Hi,

Quoted 2 lines

Okay, but have you managed to decode any channel yet ?

Yes, I managed to descramble programmes without any problem.

Quoted 7 lines

I find some code odd, maybe you can take a look as well...

init_channel in ngene-core.c creates the device sec0/caio0 with the struct ngene_dvbdev_ci. In ngene-dvb.c you can see that this struct declares the methods ts_read/ts_write to handle r/w operations on the device sec0/caio0.

Quoted 7 lines
Quoted 3 lines

Now take a look at those methods (ts_read/ts_write). I don't see how they 'connect' to the file cxd2099.c which contains the methods handling the i/o to the cam

They don't connect explicitly. Transfers are done implicitly through nGene ring-buffers. See demux_tasklet(). CXD code seems to be used only for CAM commands and setup (only) of data transfers.

I have taken a look into the ddbrigde module code from
<http://linuxtv.org/hg/~endriss/ngene-octopus-test/rev/6b400d63c481>

The ts_read/ts_write methods are different from the ngene module's. So I guess were are having entirely different problems.

#8 lore raw
In reply to Issa Gorissen
Quoted 6 lines · On Saturday 23 April 2011 00:16:56 Issa Gorissen wrote:

Running a bunch of test with gnutv and a DuoFLEX S2.

I saw the same problem concerning the decryption with a CAM.

I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO.

If you are running 2.6.39rc4, you must apply patch
http://www.mail-archive.com/[email protected]/msg29870.html
Otherwise the data will be garbled.

CU
Oliver

Signature · 5 lines
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------
#9 lore raw
Quoted 10 lines · Oliver Endriss
Quoted 6 lines · On Saturday 23 April 2011 00:16:56 Issa Gorissen wrote:

Running a bunch of test with gnutv and a DuoFLEX S2.

I saw the same problem concerning the decryption with a CAM.

I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO.

If you are running 2.6.39rc4, you must apply patch
http://www.mail-archive.com/[email protected]/msg29870.html
Otherwise the data will be garbled.

Oliver, this patch was applied already. I'm hacking the ts_read/ts_write method, but so far, haven't manage to get it work.

#10 lore raw
Quoted 6 lines · On Saturday 23 April 2011 20:56:47 Issa Gorissen wrote:
Quoted 5 lines · Oliver Endriss
Quoted 4 lines · On Saturday 23 April 2011 00:16:56 Issa Gorissen wrote:

Running a bunch of test with gnutv and a DuoFLEX S2.

I saw the same problem concerning the decryption with a CAM.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO.

If you are running 2.6.39rc4, you must apply patch
http://www.mail-archive.com/[email protected]/msg29870.html
Otherwise the data will be garbled.

Oliver, this patch was applied already. I'm hacking the ts_read/ts_write method, but so far, haven't manage to get it work.

Basically you should not have to hack anything.

- Setup the CI as with any conventional device.
- Write the encrypted stream into sec0.
- Read the decrypted stream from sec0.

This should work. (Please note that I could do some loopback tests only, as I am not watching paytv.)

CU
Oliver

Signature · 5 lines
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------
#11 lore raw
Quoted 5 lines · Oliver Endriss
Quoted 5 lines
Quoted 3 lines

If you are running 2.6.39rc4, you must apply patch
http://www.mail-archive.com/[email protected]/msg29870.html
Otherwise the data will be garbled.

Oliver, this patch was applied already. I'm hacking the ts_read/ts_write method, but so far, haven't manage to get it work.

Quoted 8 lines

Basically you should not have to hack anything.

- Setup the CI as with any conventional device.
- Write the encrypted stream into sec0.
- Read the decrypted stream from sec0.

This should work. (Please note that I could do some loopback tests only, as I am not watching paytv.)

Oliver,

Is there a preferred way to do this (read/write from sec0) ? I mean, does a

'gnutv -channels file -out stdout channelname > sec0'

and

'cat sec0 | mplayer -'

should work according to your tests ?

#12 lore raw
In reply to Oliver Endriss
Quoted 11 lines · Oliver Endriss

Basically you should not have to hack anything.
- Setup the CI as with any conventional device.
- Write the encrypted stream into sec0.
- Read the decrypted stream from sec0.

This should work. (Please note that I could do some loopback tests only, as I am not watching paytv.)

CU
Oliver

Oliver,

This does not work.

I have launch gnutv like this: 'gnutv -adapter 0 -channels hb.conf -out dvr -timeout 30 TF1'

Then on dd

tv@tv:~> dd if=188 if=/dev/dvb/adapter0/dvr0 of=/dev/dvb/adapter0/caio0 ^C36071+1 records in
36071+0 records out
18468352 bytes (18 MB) copied, 76.4947 s, 241 kB/s

And another dd

tv@tv:~> dd bs=188 if=/dev/dvb/adapter0/caio0 of=test.mpeg ^Cdd: reading `/dev/dvb/adapter0/caio0': Resource temporarily unavailable 1338880+0 records in
1338880+0 records out
251709440 bytes (252 MB) copied, 34.3276 s, 7.3 MB/s
dd: closing input file `/dev/dvb/adapter0/caio0': Bad file descriptor

The first dd reports a more/less correct size for 30sec of encrypted tv ~ 18MB.
But the 2nd dd shows a big generated file out of the device. Plus it mostly contains the following pattern : lots of FF separated by 47 1F FF 10.

I hope you can guide me to solve this - it is getting painful. Can we review the code together ? The starting point should be the ts_write/read methods.
--
Issa

#3 lore raw
In reply to Issa Gorissen
Quoted 66 lines

-----Original Message-----
From: [email protected] [mailto:linux-media- [email protected]] On Behalf Of Issa Gorissen
Sent: samedi 23 avril 2011 12:20
To: Ralph Metzler
Cc: [email protected]; [email protected]
Subject: Re: ngene CI problems

Quoted 43 lines · Issa Gorissen
Quoted 31 lines

Hi all!

I'm trying to make the DVB_DEVICE_SEC approach work, however I'm experiencing certain problems with the following setup:

Software:
Linux 2.6.34.8 (vanilla)
drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/
<http://linuxtv.org/hg/%7Eendriss/v4l-dvb/>

Hardware:
Digital Devices CineS2 + CI Module

Problems:

- Packets get lost in SEC device:

I write complete TS to SEC, but when reading from SEC there are discontinuities on the CC.

- SEC device generates NULL packets (ad infinitum):

When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready.

- SEC device blocks on CAM re-insertion:

When CAM is removed from the slot and inserted again, all read() operations just hang. Rebooting resolves the problem.

Quoted 7 lines

- SEC device does not respect O_NONBLOCK:

In connection to the previous problem, SEC device blocks even if opened with O_NONBLOCK.

Best regards,
Martin Vidovic

Hi,

Running a bunch of test with gnutv and a DuoFLEX S2.

Quoted 7 lines

I saw the same problem concerning the decryption with a CAM.

I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO.

I would run gnutv like 'gnutv -out stdout channelname > /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 |

mplayer -'

Quoted 2 lines

Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and

over.

Quoted 1 line
Quoted 9 lines
Quoted 1 line

Anyone using ngene based card with a CAM running successfully ?

Hi Ralph,

Could you enlighten us on the following matter please ?

I took a look inside cxd2099.c and I found that the method I suspect to read/write data from/to the CAM are not activated.

These methods dont't seem to be needed, except by the "BUFFER_MODE" (no doc about what it is).

Usually, the CA device is only used to dialog with the CAM through 4 specials functions (x_attribute_mem and x_cam_control)
The TS stream to be decoded and the decoded TS stream don't go through this CA device but through the SEC device.
The SEC device is associated to one serial TS out pin and one serial in pin of the Micronas nGene bridge.
The CI device seems to be hardcoded to work at 62mbps, that means you will always read at 62mbps from SEC and you will not be able to write at more than 62mbps on SEC. When there is not enough TS packets to decode, the CI device will send padding TS packets (the one with PID=0x1FFF and full of 0xFF data) to keep the output bandwidth at 62mbps.

This is my current understanding of this (un)famous CI interface, hope it may help. By the way, I wasn't yet able to decode any channel with this card.

Does someone here manage to decode a channel and kind provide a setup?

Quoted 31 lines

static struct dvb_ca_en50221 en_templ = {
.read_attribute_mem = read_attribute_mem,
.write_attribute_mem = write_attribute_mem,
.read_cam_control = read_cam_control,
.write_cam_control = write_cam_control,
.slot_reset = slot_reset,
.slot_shutdown = slot_shutdown,
.slot_ts_enable = slot_ts_enable,
.poll_slot_status = poll_slot_status,
#ifdef BUFFER_MODE
.read_data = read_data,
.write_data = write_data,
#endif

};

Methods read_data and write_data are both enclosed inside the BUFFER_MODE test. Also, current version of struct dvb_ca_en50221 does not provide for read_data/write_data methods, right ?

If I recall right, you once told that you manage to test the CAM
<http://www.mail-archive.com/[email protected]/msg22196.html>,
how did you do ?

Thx
--
Issa
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#13 lore raw
In reply to Martin Vidovic
Quoted 7 lines · On Monday 07 March 2011 14:50:02 Martin Vidovic wrote:

...
- SEC device generates NULL packets (ad infinitum):

When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready.
...

I reworked the driver to strip those null packets. Please try
http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08

CU
Oliver

Signature · 5 lines
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------
#16 lore raw
Quoted 7 lines · On Thursday 12 May 2011 22:28:52 Issa Gorissen wrote:
Quoted 3 lines · Oliver Endriss

I reworked the driver to strip those null packets. Please try
http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08

Tried your patch, but FFs have been replaced by 6Fs in null packets. Other than that, no improvement for me.

Please double check that the patch applied cleanly. The 0x6F NULL packets should never be passed to userspace.

CU
Oliver

Signature · 5 lines
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------
author
#17 lore raw
In reply to Oliver Endriss

Hello Oliver,

Quoted 4 lines · Oliver Endriss
Quoted 3 lines · On Monday 07 March 2011 14:50:02 Martin Vidovic wrote:

...
- SEC device generates NULL packets (ad infinitum):

Quoted 8 lines
Quoted 4 lines

When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready.
...

I reworked the driver to strip those null packets. Please try
http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08

a) Tested without CAM, it works OK.
b) Tested with Viaccess Pocket dTV, there are some problems:

Sometimes filtering works, sometimes it doesn't. This summarises the observed behaviour:

(1) When I read 188 bytes from SEC, I notice first byte isn't 0x47. So, I count how many bytes need to be skipped to get to the 0x47 byte. For illustration, let's say 8 bytes need to be skipped.

(2) Now I do CA_RESET ioctl on matching CA device and wait 3 seconds.

(3) Repeat step (1) but now I count 4 bytes need to be skipped.

(4) Do CA_RESET.

(5) NULL packets can't be read now.

(6) Do CA_RESET.

(7) Repeat step (1) and now 184 bytes need to be skipped.

(8) and so on...

Here is the code I used for testing:

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <pthread.h>

#include <linux/dvb/ca.h>

#include <stdio.h>

#define NUM_PKT 672
#define BUF_SIZE (NUM_PKT * 188)

int fd_ca = -1;
int fd_sec = -1;

unsigned char *buf_in = NULL;

pthread_t read_thread;

int err(const char *msg) {
	printf("ERROR: %s (%m).\n", msg);
	return 1;
}
void *read_thread_main(void *tparm) {
	ssize_t n_read = 0;
	size_t prev_sync_off = 0;
	size_t prev_sync_diff = 0;
	size_t i = 0;

	while (1) {
		n_read = read(fd_sec, buf_in, BUF_SIZE);
		if (n_read > 0) {
			printf("[%zd b]: ", n_read);

			prev_sync_off = 0;
			for (i = 1; i < n_read; i++) {
				if (buf_in[i] == 0x47) {

					/* measure distance between two sync bytes */
					if ((i - prev_sync_off) != prev_sync_diff) {
						prev_sync_diff = (i - prev_sync_off);
						printf("%zu @ %zu; ", prev_sync_diff, i);
					}

					prev_sync_off = i;
				}
			}

			printf("\n");
		} else if (n_read < 0) {
			printf("SEC read error '%m'.\n");
			break;
		}
	}

	return NULL;
}
int main(int argc, char **argv) {
	char path_ca[] = "/dev/dvb/0123456789abcdef/ca0";
	char path_sec[] = "/dev/dvb/0123456789abcdef/sec0";

	/* make dev paths + malloc buffers */

	if (argc != 2) {
		printf("usage: %s adapter_name\n", argv[0]);
		return 1;
	}

	if (strlen(argv[1]) > 16)
		return err("adapter name too long (max 16)");

	sprintf(path_ca, "/dev/dvb/%s/ca0", argv[1]);
	sprintf(path_sec, "/dev/dvb/%s/sec0", argv[1]);

	buf_in = malloc(BUF_SIZE);
	if (buf_in == NULL)
		return err("malloc buf_in");

	/* open devs */

	fd_ca = open(path_ca, O_RDWR);
	if (fd_ca == -1)
		return err("open path_ca");

	fd_sec = open(path_sec, O_RDWR);
	if (fd_sec == -1)
		return err("open path_sec");

	/* start work */

	if (pthread_create(&read_thread, NULL, &read_thread_main, NULL) != 0)
		return err("read_thread start failed.");
	pthread_detach(read_thread);

	/* CA reset loop */

	while (1) {
		sleep(3);

		printf("\nCA reset\n\n");
		ioctl(fd_ca, CA_RESET);
	}
}

Best regards,
Martin Vidovic