ngene CI problems

ngene CI problems

[Martin Vidovic]

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

ngene CI problems

[Issa Gorissen]

> 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.
>
> - 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

Re: ngene CI problems

[Issa Gorissen]

On 23/04/11 00:16, Issa Gorissen wrote:
>> 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.
>>
>> - 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 ?

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/linux-media@vger.kernel.org/msg22196.html>,
how did you do ?

Thx
--
Issa

RE: ngene CI problems

[Sébastien RAILLARD (COEXSI)]

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of Issa Gorissen
> Sent: samedi 23 avril 2011 12:20
> To: Ralph Metzler
> Cc: xtronom@gmail.com; linux-media@vger.kernel.org
> Subject: Re: ngene CI problems
> 
> On 23/04/11 00:16, Issa Gorissen wrote:
> >> 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.
> >>
> >> - 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 ?
> 
> 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?


> 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/linux-media@vger.kernel.org/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 majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

Re: ngene CI problems

[Martin Vidovic]

Hi Issa,
> 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).

> 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

Re: ngene CI problems

[Issa Gorissen]

On 23/04/11 13:37, Martin Vidovic wrote:
> Hi Issa,
>> 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).
>
>> 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

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

Re: ngene CI problems

[Martin Vidovic]

Hi,
> Okay, but have you managed to decode any channel yet ?
>   
Yes, I managed to descramble programmes without any problem.
> 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

Re: ngene CI problems

[Issa Gorissen]

On 23/04/11 14:39, Martin Vidovic wrote:
> Hi,
>> Okay, but have you managed to decode any channel yet ?
>>   
> Yes, I managed to descramble programmes without any problem.
>> 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.

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.

Re: ngene CI problems

[Oliver Endriss]

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/linux-media@vger.kernel.org/msg29870.html
Otherwise the data will be garbled.

CU
Oliver

-- 
----------------------------------------------------------------
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/
----------------------------------------------------------------

Re: ngene CI problems

[Issa Gorissen]

On 23/04/11 19:40, Oliver Endriss wrote:
> 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/linux-media@vger.kernel.org/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.

Re: ngene CI problems

[Oliver Endriss]

On Saturday 23 April 2011 20:56:47 Issa Gorissen wrote:
> On 23/04/11 19:40, Oliver Endriss wrote:
> > 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/linux-media@vger.kernel.org/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

-- 
----------------------------------------------------------------
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/
----------------------------------------------------------------

Re: ngene CI problems

[Issa Gorissen]

On 23/04/11 21:14, Oliver Endriss wrote:
>>> If you are running 2.6.39rc4, you must apply patch
>>> http://www.mail-archive.com/linux-media@vger.kernel.org/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.)
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 ?

Re: ngene CI problems

[Issa Gorissen]

On 23/04/11 21:14, Oliver Endriss wrote:
> 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

Re: ngene CI problems

[Oliver Endriss]

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

-- 
----------------------------------------------------------------
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/
----------------------------------------------------------------

Re: ngene CI problems

[Issa Gorissen]

On 11/05/2011 20:59, Oliver Endriss wrote:
> I reworked the driver to strip those null packets. Please try
> http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08
>
> CU
> Oliver
Great!

Will give it a try tonight and report.

Thx,
--
Issa

Re: ngene CI problems

[Issa Gorissen]

On 11/05/11 20:59, Oliver Endriss wrote:
>
> I reworked the driver to strip those null packets. Please try
> http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08
>
> CU
> Oliver
>

Hi Oliver,

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

Thx
--
Issa

Re: ngene CI problems

[Oliver Endriss]

On Thursday 12 May 2011 22:28:52 Issa Gorissen wrote:
> On 11/05/11 20:59, Oliver Endriss wrote:
> >
> > 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

-- 
----------------------------------------------------------------
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/
----------------------------------------------------------------

Re: ngene CI problems

[Martin Vidovic]

Hello Oliver,

On Wed, 11 May 2011, Oliver Endriss wrote:

> 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
> 

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