Code Monkey home page Code Monkey logo

descrambler's Introduction

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License long with this program. If not, see http://www.gnu.org/licenses/

Due to 'Hollywood' legislation, the use of this software is illegal in most countrys. (but not in my country, hehe)

descrambler's People

Contributors

bas-t avatar eiten avatar peje66 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

descrambler's Issues

RSA not work correctly

Hi, you probably have an error in processing RSA. Tested with irdeto 1024bit certificate. The result is incorrect.

ffdecsawrapper segfaults

Hello,

It's me again. I'm using the mainline cx24120 drivers with Kernel 4.3 now. Until yesterday i have used 4.3.0 and everything worked fine. But after upgrading to 4.3.3 today ffdecsawrapper segfaults again and i don't know why :(

ffdecsa log:
http://pastebin.com/raw/BeVWeddm

backtrace:
http://pastebin.com/raw/vGac7bvG

I had the same problem with 4.3.0 but it magically disappeared after some reboots... Do you have any clue what could cause this?

DVB-S2 Card: Technisat SkyStar2
Distribution: Archlinux

cheers

TBS6981, Device or resource busy

Hello
First, many thanks for all your work on descrambler and dvbloopback! Awsome!

I'm having a problem with myth getting:

mythbackend: mythbackend[19224]: W CoreContext recorders/dvbchannel.cpp:245 (Open) DVBChan[3](/dev/dvb/adapter4/frontend1): Opening DVB frontend device failed.#012#011#011#011eno: Device or resource busy (16)
Aug 30 12:00:46 eddie mythbackend: mythbackend[19224]: W CoreContext recorders/dvbchannel.cpp:245 (Open) DVBChan[4](/dev/dvb/adapter5/frontend1): Opening DVB frontend device failed.#012#011#011#011eno: Device or resource busy (16)

in mythbackend.log.

My setup is Ubuntu 16.04, kernel 4.4.0-92 and a TBS6981 dual tuner card.
I have run your script:
./configure --drivers=no --headers=yes
and it seems to run without problems. Modules dvbloopback loads fine and ffdecsawrapper starts and seems to be running ok connecting to oscam.

Hardware is running ok on Ubuntu 12.04 with sasc-ng, so there is no hardware problem.

I'm a bit uncertain if it was the right way to run your configure script? Maybe I missed a patch or something?

Or perhaps I have misunderstood which driver I need for this to work? The card seems to be supported by the kernel as i could see the module cx23885 loaded after upgrading to 16.04.

Any help/pointers would be greatly appreciated.

Question: CPU utilisation

Jumping back to sasc-ng for some testing I noticed ffdecsawrapper/descrambler seems to utilise a lot more CPU and does not release it when descrambling stops. Not really a scientific test, And the values obviously jump around but:

Ubuntu 12.04/sasc-ng/mythtvbackend 0.27

CPU load:
Decoding and watching NPO1
mythbackend 8% sasc-ng 4%
Back to Gui screen
mythbackend 1% sasc-ng ~0%

Ubuntu 16.04/ffdecsawrapper/mythtvbackend 0.28

CPU load:
Decoding and watching NPO1
mythbackend 3% ffdecsawrapper 9%
Back to Gui screen
mythbackend <1% ffdecsawrapper 8%

The CPU load displayed by top stays above 7% continually for ffdecsawrapper.

Have you noticed this before ?

PowerVu Support

Hello Tycho, first of all thank you very much for your work on this. I was a sasc-ng user many years ago, but only recently dusted off my old Skystar2 pci card (dvb-s only) to play with. I am sure you are familiar with the oscam-emu patch for oscam and probably know they have implemented a method for descrambling powervu. But, their method includes a hack of using a stream relay. I am interested in a better solution and I think that your descrambler (and dvbloopback) could be the best way to do that. Since I am not that great of a programmer, and you know your code best, I would like to ask if you have any interest in adding powervu to the list of systems descrambler handles? I am currently using ffdecsawrapper (because I am using a stock Wheezy installation and kernel) but I can certainly update my kernel if needed for testing. If you don't have interest and/or time, can you give me some pointers on where I should begin to attempt it on my own?
Also, I read in an older issue with ffdescrambler when someone asked about a forum for support, that you did not know of one. Has that changed?

descrambler builds but crashes if GCC's -fstack-check flag is used

Hi,

I had some problems today getting the latest version of descrambler up and running, until I realized that the stack smashing protector (SSP) of gcc creates executables that crash immediately after decoding starts. Consider this as a bug report or a warning to all users of a hardened gcc that have SSP enabled.

I'm using hardened gentoo linux here.

gcc-config -l

[1] x86_64-pc-linux-gnu-4.9.3 *
[2] x86_64-pc-linux-gnu-4.9.3-hardenednopie
[3] x86_64-pc-linux-gnu-4.9.3-hardenednopiessp
[4] x86_64-pc-linux-gnu-4.9.3-hardenednossp
[5] x86_64-pc-linux-gnu-4.9.3-vanilla

Usually my gcc is set to profile [1] that enables both position-independend executables (PIE) and the stack smashing protector (SPP). Compiling the descrambler succeeds with all profiles (1, 2, 3, 4, and 5), but only the profiles 3, 4, and 5 create an executable that does not crash with a segmentation fault. Furthermore, this is not a freshly introduced misbehavior: I tested and picked multiple random commits even from the previous ffdecsawrapper repo and all of them are affected.

How to reproduce:

  • Use a nagra HD02 card for the german ASTRA 19.2E HD channels (via a local oscam)
    1.) Compile the ffdecsawrapper binary (most recent commit from descrabler git repo master) and copy the binary to your system, e.g., to /usr/bin/ffdecsawrapper. Assure that SSP is enabled for gcc to trigger the problem.
    2.) Start ffdecsawrapper: I use "/usr/bin/ffdecsawrapper --join 0:4 --join 1:5 --join 2:6 --join 3:7 --cam-dir /etc/camfiles --buffer 20M --sid-filt 20"
    3.) Start the mythbackend; it starts up and ffdescawrapper shows some log output regarding "clearing tuning cache" etc. No problem.
    4.) Start mythfrontend. Still no problem with ffdecsawrapper.
    5.) Start live-TV (to activate a DVS-S2-tuner and the process of descrabling). ffdescawrapper crashes immediately with a segfault.

GDB shows the following (I mangled the bytes to assure not to publish any keys here!)
[...snip...]
Oct 11 19:55:59.439 CAM(core.ecm): 0.1: found 186a(0000) (Nagra2) id 0000 with ecm 1d8e/80 (new)
Oct 11 19:55:59.439 THREAD: logger stats thread started (pid=26311, tid=3564746602240)
Oct 11 19:55:59.439 THREAD: logger 0 filter thread started (pid=26311, tid=3564737484544)
Oct 11 19:55:59.439 CAM(core.ecm): 0.1: try system Cardclient (1843) id 0000 with ecm 1234 (cached) (pri=-15)
Oct 11 19:55:59.495 CAM(core.au): 0: chain caid 1830 -> Nagra2(-10) [1003-82/fe]
Oct 11 19:55:59.495 CAM(core.au): 0: chain caid 1843 -> Nagra2(-10) Cardclient(-15) [1005-82/fe]
Oct 11 19:55:59.495 CAM(core.au): 0: chain caid 09c4 -> none available
Oct 11 19:55:59.495 CAM(core.au): 0: chain caid 098c -> none available
Oct 11 19:55:59.495 CAM(core.au): 0: chain caid 0648 -> Irdeto2(-8) Irdeto(-10) [1016-82/ff]
Oct 11 19:55:59.495 CAM(core.au): 0: chain caid 1860 -> Nagra2(-10) [1007-82/fe]
Oct 11 19:55:59.496 CAM(core.au): 0: chain caid 0650 -> Irdeto2(-8) Irdeto(-10) [1019-82/ff]
Oct 11 19:55:59.496 CAM(core.au): 0: chain caid 186a -> Nagra2(-10) [1013-82/fe]
Oct 11 19:55:59.496 CAM(core.au): 0: starting chain 1843
Oct 11 19:55:59.614 CAM(cardclient.core): cc-loop
Oct 11 19:55:59.614 CAM(cardclient.core): now trying client Newcamd (127.0.0.1:12345)
Oct 11 19:55:59.987 CAM(core.ecm): 0.1: correct key found
Oct 11 19:56:00.012 CSA: Creating csa for rb: 4
[New LWP 26360]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 26360]
0x0000007599ec18bc in block_decypher_group(long long vector, unsigned char, unsigned char*, int) ()
(gdb)
(gdb)
(gdb)
(gdb) bt
#0 0x0000007599ec18bc in block_decypher_group(long long vector, unsigned char, unsigned char*, int) ()
#1 0x0000007599ec6df5 in decrypt_packets(void_, unsigned char_*) ()
#2 0x0000007599e9788b in process_ts (csa=0x759c935340,

buffer=0x33e3f1590a4 "G\001\002\003\004V>\004\006\007\008\009\010\011\012\013\014\015\016\...", end=129344, force=0) at dvblb_plugins/plugin_ffdecsa.c:327

#3 0x0000007599e983b4 in process_ffd (msg=0x759c8ff890, priority=1) at dvblb_plugins/plugin_ffdecsa.c:512
#4 0x0000007599e8c0b6 in msg_loop (arg=0x1) at src/msg_passing.c:118
#5 0x0000033e421fa47c in ?? ()
#6 0x0000000000000000 in ?? ()

(gdb)

Each packet of my system was compiled with "-ggdb", so backstraces normally contain useful information even regarding calls to system libraries.

Valgrind terminates with the following error:
==28158== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==28158== Bad permissions for mapped region at address 0x417A460
==28158== at 0x1E68BC: block_decypher_group(long long vector, unsigned char, unsigned char*, int) (in /usr/bin/ffdecsawrapper)

Unfortunately, valgrind shows subsequent warnings before the crash and I would like to attach the whole dump it here, but (a) I'm not sure if that helps you and (b) I would like not to publish dumps that may contain "problematic numbers".

If I can help you / debug something... don't hesitate to reply :-)
Florian

Segfault in decrypt_packets due to bad driver

Hi,

I've noticed that FFdecsawrapper segfaults quite frequently on my environment. The crashes happen when FFdecsawrapper is running for a couple of hours.

I'm running dvbloopback+FFdecsawrapper+OSCAM+MythTV here using a TechnoTrend CT2-4400 USB device which is connected to the Ziggo DVB-C network. The operating system is CentOS 7 with kernel 3.10.0-229.20.1.el7.centos.plus.x86_64 and a git checkout of the v4l media_tree (with dvbloopback) from November 1 2015. FFdecsawrapper is compiled using PARALLEL_MODE=PARALLEL_128_SSE2. FFdecsawrapper is started with the following command line options: ./ffdecsawrapper -j 0:1 --sid-allpid --cam-budget --pidfile /run/ffdecsawrapper.pid --cam-dir /etc/camfiles

Because of the frequent crashes I decided to try to debug using Valgrind. There are multiple areas where Valgrind reports about (for one I already have a fix ready) but in this issue I'm limiting to the final segfault for now. To get more valuable/reliable backtraces I removed the compiler flag -fomit-frame-pointer and added the compiler flag -g in the config.mak file.

Here's the Valgrind output about the failures which eventually lead to the segfault:

==20195== Thread 12:
==20195== Use of uninitialised value of size 8
==20195==    at 0x48EA9F: decrypt_packets(void*, unsigned char**) (FFdecsa.c:840)
==20195==    by 0x4722DD: process_ts(csastruct*, unsigned char*, unsigned int, int) (plugin_ffdecsa.c:327)
==20195==    by 0x472C70: process_ffd(msg*, unsigned int) (plugin_ffdecsa.c:512)
==20195==    by 0x468FAA: msg_loop(void*) (msg_passing.c:118)
==20195==    by 0x4E3CDC4: start_thread (pthread_create.c:308)
==20195==    by 0x5F8521C: clone (clone.S:113)
==20195== 
==20195== Use of uninitialised value of size 8
==20195==    at 0x48EAA7: decrypt_packets(void*, unsigned char**) (FFdecsa.c:840)
==20195==    by 0x4722DD: process_ts(csastruct*, unsigned char*, unsigned int, int) (plugin_ffdecsa.c:327)
==20195==    by 0x472C70: process_ffd(msg*, unsigned int) (plugin_ffdecsa.c:512)
==20195==    by 0x468FAA: msg_loop(void*) (msg_passing.c:118)
==20195==    by 0x4E3CDC4: start_thread (pthread_create.c:308)
==20195==    by 0x5F8521C: clone (clone.S:113)
==20195== 
==20195== Use of uninitialised value of size 8
==20195==    at 0x48EAAF: decrypt_packets(void*, unsigned char**) (FFdecsa.c:840)
==20195==    by 0x4722DD: process_ts(csastruct*, unsigned char*, unsigned int, int) (plugin_ffdecsa.c:327)
==20195==    by 0x472C70: process_ffd(msg*, unsigned int) (plugin_ffdecsa.c:512)
==20195==    by 0x468FAA: msg_loop(void*) (msg_passing.c:118)
==20195==    by 0x4E3CDC4: start_thread (pthread_create.c:308)
==20195==    by 0x5F8521C: clone (clone.S:113)
==20195== 
==20195== Use of uninitialised value of size 8
==20195==    at 0x48EAB8: decrypt_packets(void*, unsigned char**) (FFdecsa.c:840)
==20195==    by 0x4722DD: process_ts(csastruct*, unsigned char*, unsigned int, int) (plugin_ffdecsa.c:327)
==20195==    by 0x472C70: process_ffd(msg*, unsigned int) (plugin_ffdecsa.c:512)
==20195==    by 0x468FAA: msg_loop(void*) (msg_passing.c:118)
==20195==    by 0x4E3CDC4: start_thread (pthread_create.c:308)
==20195==    by 0x5F8521C: clone (clone.S:113)
==20195== 
==20195== Use of uninitialised value of size 8
==20195==    at 0x48EAC0: decrypt_packets(void*, unsigned char**) (FFdecsa.c:840)
==20195==    by 0x4722DD: process_ts(csastruct*, unsigned char*, unsigned int, int) (plugin_ffdecsa.c:327)
==20195==    by 0x472C70: process_ffd(msg*, unsigned int) (plugin_ffdecsa.c:512)
==20195==    by 0x468FAA: msg_loop(void*) (msg_passing.c:118)
==20195==    by 0x4E3CDC4: start_thread (pthread_create.c:308)
==20195==    by 0x5F8521C: clone (clone.S:113)
==20195== 
==20195== Use of uninitialised value of size 8
==20195==    at 0x48EA73: decrypt_packets(void*, unsigned char**) (FFdecsa.c:840)
==20195==    by 0x4722DD: process_ts(csastruct*, unsigned char*, unsigned int, int) (plugin_ffdecsa.c:327)
==20195==    by 0x472C70: process_ffd(msg*, unsigned int) (plugin_ffdecsa.c:512)
==20195==    by 0x468FAA: msg_loop(void*) (msg_passing.c:118)
==20195==    by 0x4E3CDC4: start_thread (pthread_create.c:308)
==20195==    by 0x5F8521C: clone (clone.S:113)
==20195== 
==20195== Invalid read of size 8
==20195==    at 0x48EA73: decrypt_packets(void*, unsigned char**) (FFdecsa.c:840)
==20195==    by 0x4722DD: process_ts(csastruct*, unsigned char*, unsigned int, int) (plugin_ffdecsa.c:327)
==20195==    by 0x472C70: process_ffd(msg*, unsigned int) (plugin_ffdecsa.c:512)
==20195==    by 0x468FAA: msg_loop(void*) (msg_passing.c:118)
==20195==    by 0x4E3CDC4: start_thread (pthread_create.c:308)
==20195==    by 0x5F8521C: clone (clone.S:113)
==20195==  Address 0x3fbfff25c10fd55b is not stack'd, malloc'd or (recently) free'd
==20195== 
==20195== 
==20195== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==20195==  General Protection Fault
==20195==    at 0x48EA73: decrypt_packets(void*, unsigned char**) (FFdecsa.c:840)
==20195==    by 0x4722DD: process_ts(csastruct*, unsigned char*, unsigned int, int) (plugin_ffdecsa.c:327)
==20195==    by 0x472C70: process_ffd(msg*, unsigned int) (plugin_ffdecsa.c:512)
==20195==    by 0x468FAA: msg_loop(void*) (msg_passing.c:118)
==20195==    by 0x4E3CDC4: start_thread (pthread_create.c:308)
==20195==    by 0x5F8521C: clone (clone.S:113)

The code in question (FFdecsa.c:840) is:

  for(g=0;g<alive[iter];g++){
    COPY_8_BY(ib+8*g,encp[g]);          <<<< segfault happens here
  }

As can be observed in the output above it looks like the for-loop gets iterated 7 times using unitialized data and one time doing an invalid read.

I'm still doing research here but I decided to share my findings so far and perhaps you can assist in researching the root cause

ffdecsawrapper tuning issue

Hi,
i have a problem with ffdecsawrapper since i upgraded my MythTV system to Ubuntu 16.04LTS...
On all my three Hauppauge NovaS2 cards ffdecsawrapper works fine and as expected but after a while on one of the cards tuning hangs with (TL__) and the recordings fail.

The other two cards still work fine and the only thing i can do to fix this is to restart ffdecsawrapper.

After restarting ffdecsawrapper all three tuners are fine again until one of them shows the issue again. It does not matter what channel the card tries to tune to and also the adapter having the issue changes...

Did someone ever experience similar issues? Any hint would be highly appreciated...

Thanks!

Build fails due to removed DMX_KERNEL_CLIENT declaration (SOLVED, Gentoo Linux)

Related to this removal of the DMX_KERNEL_CLIENT declaration

https://patchwork.kernel.org/patch/9934253/

the build process fails here on my box. The build output:

powerstation descrambler # make clean
powerstation descrambler # make      
g++ -Wall -D__user=  -o objs/forward.o -c  -DRELEASE_VERSION=\"v1.0-7-g45f84c0\" -D__KERNEL_STRICT_NAMES -Isrc src/forward.c
g++ -Wall -D__user=  -o objs/process_req.o -c  -DRELEASE_VERSION=\"v1.0-7-g45f84c0\" -D__KERNEL_STRICT_NAMES -Isrc src/process_req.c
g++ -Wall -D__user=  -o objs/msg_passing.o -c  -DRELEASE_VERSION=\"v1.0-7-g45f84c0\" -D__KERNEL_STRICT_NAMES -Isrc src/msg_passing.c
g++ -Wall -D__user=  -o objs/plugin_getsid.o -c  -DRELEASE_VERSION=\"v1.0-7-g45f84c0\" -D__KERNEL_STRICT_NAMES -Isrc src/plugin_getsid.c
g++ -Wall -D__user=  -o objs/plugin_ringbuf.o -c  -DRELEASE_VERSION=\"v1.0-7-g45f84c0\" -D__KERNEL_STRICT_NAMES -Isrc src/plugin_ringbuf.c
g++ -Wall -D__user=  -o objs/plugin_showioctl.o -c  -DRELEASE_VERSION=\"v1.0-7-g45f84c0\" -D__KERNEL_STRICT_NAMES -Isrc src/plugin_showioctl.c
src/plugin_showioctl.c: In function ‘void demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)’:
src/plugin_showioctl.c:252:34: error: ‘DMX_KERNEL_CLIENT’ was not declared in this scope
                    (dmx->flags & DMX_KERNEL_CLIENT ? " KERNEL_CLIENT" : ""));
                                  ^~~~~~~~~~~~~~~~~
src/plugin_showioctl.c:303:34: error: ‘DMX_KERNEL_CLIENT’ was not declared in this scope
                    (dmx->flags & DMX_KERNEL_CLIENT ? " KERNEL_CLIENT" : ""));
                                  ^~~~~~~~~~~~~~~~~
src/plugin_showioctl.c:327:12: error: ‘DMX_GET_CAPS’ was not declared in this scope
       case DMX_GET_CAPS:
            ^~~~~~~~~~~~
src/plugin_showioctl.c:327:12: note: suggested alternative: ‘DMX_OUT_TAP’
       case DMX_GET_CAPS:
            ^~~~~~~~~~~~
            DMX_OUT_TAP
src/plugin_showioctl.c:330:70: error: invalid use of incomplete type ‘struct demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)::dmx_caps’
           tmprintf("","DMX_GET_CAPS(%d): %u num:%d\n", fdptr->fd, dmx->caps,
                                                                      ^~
src/plugin_showioctl.c:329:18: note: forward declaration of ‘struct demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)::dmx_caps’
           struct dmx_caps *dmx = (struct dmx_caps*)data;
                  ^~~~~~~~
src/plugin_showioctl.c:331:21: error: invalid use of incomplete type ‘struct demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)::dmx_caps’
                  dmx->num_decoders);
                     ^~
src/plugin_showioctl.c:329:18: note: forward declaration of ‘struct demux_ioctl(parser_cmds*, poll_ll*, cmdret_t*, int*, long unsigned int, unsigned char*)::dmx_caps’
           struct dmx_caps *dmx = (struct dmx_caps*)data;
                  ^~~~~~~~
src/plugin_showioctl.c:334:12: error: ‘DMX_SET_SOURCE’ was not declared in this scope
       case DMX_SET_SOURCE:
            ^~~~~~~~~~~~~~
src/plugin_showioctl.c:334:12: note: suggested alternative: ‘DMX_GET_STC’
       case DMX_SET_SOURCE:
            ^~~~~~~~~~~~~~
            DMX_GET_STC
make: *** [Makefile:59: objs/plugin_showioctl.o] Error 1
powerstation descrambler # 

Regards,
Florian

Error with CRC in tables (ie. PAT table)

I believe this is a descrambler issue, but could also be dvbloopback.
CRC of certain tables is failing using descrambler/dvbloopback, doing a channel-scan using dvbv5-scan.
In the example it below, it fails with 'table ID 0x00, program ID 0x00', but it fails also with other tables.

  • Can someone confirm this behavior?
  • Can someone explain the rewriting of the tables done by descrambler?

See response of virtual adapter:

user@hostname:~$ dvbv5-scan -v -a 2 -d 0 -f 0 /home/user/initial.conf -o dvb_channels.conf
WARNING  Ignoring device /dev/dvb/adapter2/osd0
WARNING  Ignoring device /dev/dvb/adapter2/osd1
WARNING  Ignoring device /dev/dvb/adapter3/osd0
WARNING  Ignoring device /dev/dvb/adapter3/osd1
using demux 'dvb2.demux0'
WARNING  Detected dvbloopback
Device ST STV0367 DDB DVB-C/T (/dev/dvb/adapter2/frontend0) capabilities:
     CAN_FEC_1_2
     CAN_FEC_2_3
     CAN_FEC_3_4
     CAN_FEC_5_6
     CAN_FEC_7_8
     CAN_FEC_AUTO
     CAN_INVERSION_AUTO
     CAN_MUTE_TS
     CAN_QAM_16
     CAN_QAM_32
     CAN_QAM_64
     CAN_QAM_128
     CAN_QAM_256
     CAN_QPSK
     CAN_RECOVER
     CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems: 
    [DVBC/ANNEX_A]
     DVBT
Frequency range for the current standard: 
From:            48.0 MHz
To:               864 MHz
Step:             167 kHz
Symbol rate ranges for the current standard: 
From:             870 kBauds
To:              11.7 MBauds
Failed to guess country from the current locale setting.

ERROR    command BANDWIDTH_HZ (5) not found during retrieve
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
Scanning frequency #1 474000000
FREQUENCY = 474000000
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6875000
INNER_FEC = NONE
DELIVERY_SYSTEM = DVBC/ANNEX_A
Got parameters for DVBC/ANNEX_A:
FREQUENCY = 1
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6874921
INNER_FEC = NONE
DELIVERY_SYSTEM = DVBC/ANNEX_A
Lock   (0x1f) Signal= -22.00dBm C/N= 34.68dB UCB= 11
dvb_read_sections: waiting for table ID 0x00, program ID 0x00
ERROR    dvb_read_sections: crc error
ERROR    error while waiting for PAT table
Scanning frequency #2 164000000
FREQUENCY = 164000000
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6900000
INNER_FEC = NONE
DELIVERY_SYSTEM = DVBC/ANNEX_A
RF     (0x01) Signal= -22.00dBm

See response of physical adapter:

user@hostname:~$ dvbv5-scan -v -a 1 -d 0 -f 0 /home/user/initial.conf -o dvb_channels.conf
WARNING  Ignoring device /dev/dvb/adapter2/osd0
WARNING  Ignoring device /dev/dvb/adapter2/osd1
WARNING  Ignoring device /dev/dvb/adapter3/osd0
WARNING  Ignoring device /dev/dvb/adapter3/osd1
using demux 'dvb1.demux0'
Device ST STV0367 DDB DVB-C/T (/dev/dvb/adapter1/frontend0) capabilities:
     CAN_FEC_1_2
     CAN_FEC_2_3
     CAN_FEC_3_4
     CAN_FEC_5_6
     CAN_FEC_7_8
     CAN_FEC_AUTO
     CAN_INVERSION_AUTO
     CAN_MUTE_TS
     CAN_QAM_16
     CAN_QAM_32
     CAN_QAM_64
     CAN_QAM_128
     CAN_QAM_256
     CAN_QPSK
     CAN_RECOVER
     CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems: 
    [DVBC/ANNEX_A]
     DVBT
Frequency range for the current standard: 
From:            48.0 MHz
To:               864 MHz
Step:             167 kHz
Symbol rate ranges for the current standard: 
From:             870 kBauds
To:              11.7 MBauds
Failed to guess country from the current locale setting.

ERROR    command BANDWIDTH_HZ (5) not found during retrieve
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
Scanning frequency #1 474000000
FREQUENCY = 474000000
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6875000
INNER_FEC = NONE
DELIVERY_SYSTEM = DVBC/ANNEX_A
       (0x00) Signal= -22.00dBm C/N= 37.19dB UCB= 11
Got parameters for DVBC/ANNEX_A:
FREQUENCY = 1
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6875142
INNER_FEC = NONE
Lock   (0x1f) Signal= -58.00dBm C/N= 34.91dB UCB= 11
dvb_read_sections: waiting for table ID 0x00, program ID 0x00
dvb_parse_section: received table 0x00, extension ID 0x0012, section 0/0
dvb_parse_section: table 0x00, extension ID 0x0012: done
PAT
| table_id         0x00
| section_length      157
| one                 3
| zero                0
| syntax              1
| transport_stream_id 18
| current_next        1
| version             23
| one2                3
| section_number      0
| last_section_number 0
|\ 37 program pids
|  pid 0x0010: service 0x0000
|  pid 0x00c8: service 0x4539
|  pid 0x00ca: service 0x453a
|  pid 0x00cc: service 0x453b
|  pid 0x00ce: service 0x453c
|  pid 0x00d0: service 0x453d
|  pid 0x00d2: service 0x453e
|  pid 0x00d4: service 0x453f
|  pid 0x00d8: service 0x4541
|  pid 0x00da: service 0x4542
|  pid 0x00dc: service 0x4543
|  pid 0x00de: service 0x4544
|  pid 0x00e0: service 0x4545
|  pid 0x00e2: service 0x4546
|  pid 0x00e4: service 0x4547
|  pid 0x00e6: service 0x4548
|  pid 0x00e8: service 0x4549
|  pid 0x00ea: service 0x454a
|  pid 0x00ec: service 0x454b
|  pid 0x00ee: service 0x454c
|  pid 0x00f0: service 0x454d
|  pid 0x00f2: service 0x454e
|  pid 0x00f4: service 0x454f
|  pid 0x00f6: service 0x4550
|  pid 0x00f8: service 0x4551
|  pid 0x00fa: service 0x4552
|  pid 0x00fc: service 0x4553
|  pid 0x00fe: service 0x4554
|  pid 0x0100: service 0x4555
|  pid 0x0102: service 0x4556
|  pid 0x0104: service 0x4557
|  pid 0x0106: service 0x4558
|  pid 0x0108: service 0x4559
|  pid 0x010a: service 0x4560
|  pid 0x1130: service 0x4d25
|  pid 0x0ed8: service 0x4d2b
|  pid 0x0c80: service 0x4d2c
Program #0 is network PID: 0x0010

< break >

segfault in plugin_getsid

Hi
I had two segfaults in plugin_getsid.c but both hade same root cause.
NULL pointer usage In function static int start(char *dmxdev... )
After macro "ll_find_elem(filt, ... "

There will be segfaults in function read_pmt() or when using filt-> 3 rows further down.
if(ret < 0) {
filt->parse_err++;

This simple patch solves the problem:

diff --git a/src/plugin_getsid.c b/src/plugin_getsid.c
index f157c02..9cd1e02 100644
--- a/src/plugin_getsid.c
+++ b/src/plugin_getsid.c
@@ -597,6 +597,8 @@ static int start(char *dmxdev, struct sid_data *sid_data, int timeout) {
           struct filter *filt;
           dprintf3("Read %d bytes\n", size);
           ll_find_elem(filt, pat.dmx_filter_ll, fd, pollfd[i].fd, struct filter);
+         if (!filt)
+           goto exit;
           int ret = read_pmt(pes, filt, sid_data, size);
           if(ret < 0) {
              filt->parse_err++;

Here is a back trace of a core dump.

Thread 31 "ffdecsawrapper" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7ead700 (LWP 14536)]
0x0000000000470329 in start (dmxdev=0x7ffff7eace00 "/dev/dvb/adapter3/demux0", sid_data=0x7b0730, timeout=200) at src/plugin_getsid.c:602
602                  filt->parse_err++;
(gdb) 
(gdb) bt full
#0  0x0000000000470329 in start (dmxdev=0x7ffff7eace00 "/dev/dvb/adapter3/demux0", sid_data=0x7b0730, timeout=200) at src/plugin_getsid.c:602
        filt = 0x0
        ret = -1
        count = 45
        num_filters = 45
        found = 13
        pes = "G\004)\324Ma\315ո\222\267L\255\a\r)\322\033\001\225\021쒊\202.-\303\377\065\233\032\203\310\002\222&\335\357#\375\221l\022\363\061\274\065\316զ\275PL\340\341\062\371\003\240\006 \301x\343s\224\313\\\355\266'(\037b\310}\177\201\366q\372e\366k\225\233\206\210\365\201\211\b\232\357_\307\303Bߔ\255\066\277F?\247\021\207Z\254\260f\317\342b'\254<\331>\271\177\242\275h\023\323\337\357\346\222N\320\004`\037\240\371l\301,)S\004\241A`\032\000I\000U\025\274\276\361)8:K\252\202\373\032ǭ\311\342uʖ\017fR\261WR\204\376\335\035yR\367\v\247\322G\004)\325\343Z\257\200d\270\236I\353\307\037\017\304\365^"...
        pfd = {fd = 7, events = 1, revents = 1}
        pollfd = {{fd = 5, events = 5, revents = 1}, {fd = 5, events = 5, revents = 1}, {fd = 5, events = 5, revents = 1}, {fd = 5, events = 5, revents = 1}, {fd = 5, events = 5, revents = 1}, {fd = 5, events = 5, revents = 1}, {fd = 5, events = 1, 
            revents = 1}, {fd = 69, events = 1, revents = 0}, {fd = 70, events = 1, revents = 0}, {fd = 71, events = 1, revents = 0}, {fd = 72, events = 1, revents = 0}, {fd = 73, events = 1, revents = 0}, {fd = 74, events = 1, revents = 0}, {fd = 75, 
            events = 1, revents = 0}, {fd = 76, events = 1, revents = 0}, {fd = 77, events = 1, revents = 0}, {fd = 78, events = 1, revents = 0}, {fd = 79, events = 1, revents = 0}, {fd = 80, events = 1, revents = 0}, {fd = 81, events = 1, revents = 0}, {
            fd = 82, events = 1, revents = 0}, {fd = 83, events = 1, revents = 0}, {fd = 84, events = 1, revents = 0}, {fd = 85, events = 1, revents = 0}, {fd = 86, events = 1, revents = 0}, {fd = 87, events = 1, revents = 0}, {fd = 88, events = 1, 
            revents = 0}, {fd = 89, events = 1, revents = 0}, {fd = 90, events = 1, revents = 0}, {fd = 91, events = 1, revents = 0}, {fd = 92, events = 1, revents = 0}, {fd = 93, events = 1, revents = 0}}
        pollretries = {5 <repeats 32 times>}
        pat_restart = 0
        done = 1
        size = 940
        i = 0
        ret = 0
        pat = {patfd = 7, version = 8, last_section = 0 '\000', section_seen = "\001\000\000\000", has_nit = 16, dmx_filter_ll = {next = 0x7fffa4009fe0, prev = 0x7fffb80008c0, priority = 4294967295}}
        lptr = 0x7ffff7eabb98
#1  0x0000000000470822 in read_sid (arg=0x7b0730) at src/plugin_getsid.c:710
        sid_data = 0x7b0730
        sid_ll = 0x0
        dmxcmd = 0x7fffbc1e8f00
        dmxdev = "/dev/dvb/adapter3/demux0", '\000' <repeats 231 times>
        ret = 0
#2  0x00007ffff75456fa in start_thread (arg=0x7ffff7ead700) at pthread_create.c:333
        __res = <optimized out>
        pd = 0x7ffff7ead700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737352750848, -6612622759983783371, 0, 140737488342575, 140737352751552, 0, 6612640462249452085, 6612638894808293941}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, 
              cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#3  0x00007ffff69dab5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Some data types have been made opaque in OpenSSL version 1.1 so stack allocation and accessing struct fields directly does not work.

Currently investigating, but sadly I'm not an openssl expert (actually not even a novice).

Current situation:

http://pastebin.com/R6TdhSqQ

For reference and as a personal reminder:

https://www.openssl.org/docs/man1.0.2/crypto/bn.html

https://wiki.openssl.org/index.php/Manual:BN_new%283%29

https://wiki.openssl.org/index.php/1.1_API_Changes

rdesktop/rdesktop#44

Any help on the matter is most welcome!

Incomplete support for PCSC reader

I try to compile the descrambler with PCSC enable but not found
From descrambler/examples/cardslot.conf.example:
; For using this cardslot type, you must have installed pcsd-lite and ccid
; driver package. Before compiling you should add something like this to your
; Make.config file:
; WITH_PCSC = 1
; INCLUDES += -I/usr/include/PCSC

I also install libpcsclite-dev for create the include /usr/include/PCSC and i add the directive in LIBS:
##################################
VERSION = $(shell git describe --always)

include config.mak

CC ?= gcc
CXX ?= g++
CXXFLAGS ?= -Wall -D__user=

DEFINES += -DRELEASE_VERSION="$(VERSION)" -D__KERNEL_STRICT_NAMES
LBDIR = src
TOOL = ffdecsawrapper
LIBS = -lcrypto -lcrypt -lv4l1 -lpthread -lpcsclite
SCDIR = sc/PLUGINS/src
SCLIBS = -Wl,-whole-archive ./sc/PLUGINS/lib/libsc-*.a -Wl,-no-whole-archive
./sc/PLUGINS/lib/libffdecsawrapper-sc.a

WITH_PCSC = 1
INCLUDES += -I/usr/include/PCSC

ifneq ($(RELEASE),1)
CXXFLAGS += -g
endif
......
......
......
########################################
This parameter is on main Makefile descrambler/Makefile

Total software installed is:
ii libccid 1.4.22-1ubuntu0.1 amd64 PC/SC driver for USB CCID smart card readers
ii libpcsc-perl 1.4.14-1build1 amd64 Perl interface to the PC/SC smart card library
ii libpcsclite-dev 1.8.14-1ubuntu1.16.04.1 amd64 Middleware to access a smart card using PC/SC (development files)
ii libpcsclite1:amd64 1.8.14-1ubuntu1.16.04.1 amd64 Middleware to access a smart card using PC/SC (library)
ii pcsc-tools 1.4.25-1 amd64 Some tools to use with smart cards and PC/SC
ii pcscd 1.8.14-1ubuntu1.16.04.1 amd64 Middleware to access a smart card using PC/SC (daemon side)

Compile is always ok whit this parameter but ffdecsawrapper not recognized the ccid reader:

loading cardslot config from /etc/camfiles/cardslot.conf
unknown cardslot type 'ccid'

Unicable

Hello, wanted to ask if ffdecsa supports the Unicable standard?

Best Regards,
Markus.

kernel: INFO: task ffdecsawrapper:xxxxxx blocked for more than 240 seconds

Hello,

I am running (l)ubuntu 20.04 with kernel 5.4.0 with mythtv which I couldn't find any current deb packages of your projects for so this is what I did so far:

  • copied ppa-aap/cam/ffdecsawrapper to /usr/src
  • modified the build-script so that it builds the current git master branch of ffdecsawrapper
  • modified dkms scripts so that it builds the current git dvbloopback and dvb-core modules out-of-tree (takes a few seconds vs building the whole kernel for hours via ./configure script)
  • built everything
  • made a systemd script for ffdecsawrapper (replacing the initd script) which modprobes dvbloopback and runs ffdecsawrapper

Now, loading the dvbloopback module creates new adapters for all my dvb devices and ffdecsawrapper also starts as expected. But, every few minutes, there's something like this in syslog:

[91712.712587] INFO: task ffdecsawrapper:958168 blocked for more than 966 seconds.  
[91712.712591]       Tainted: G           OE     5.4.0-60-generic #67-Ubuntu 
[91712.712592] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[91712.712594] ffdecsawrapper  D    0 958168      1 0x00000000
[91712.712596] Call Trace:
[91712.712603]  __schedule+0x2e3/0x740
[91712.712606]  ? default_wake_function+0x12/0x20
[91712.712609]  schedule+0x42/0xb0
[91712.712611]  schedule_preempt_disabled+0xe/0x10
[91712.712612]  __mutex_lock.isra.0+0x182/0x4f0
[91712.712615]  ? ep_poll_callback+0x29d/0x2c0
[91712.712616]  __mutex_lock_slowpath+0x13/0x20
[91712.712617]  mutex_lock+0x2e/0x40
[91712.712622]  dvb_device_open+0x22/0xe0 [dvb_core]
[91712.712624]  chrdev_open+0xd3/0x1c0
[91712.712625]  ? cdev_default_release+0x20/0x20
[91712.712628]  do_dentry_open+0x143/0x3a0
[91712.712629]  vfs_open+0x2d/0x30
[91712.712631]  do_last+0x194/0x900
[91712.712633]  path_openat+0x8d/0x290
[91712.712635]  do_filp_open+0x91/0x100
[91712.712637]  ? __alloc_fd+0x46/0x150
[91712.712638]  do_sys_open+0x17e/0x290
[91712.712639]  __x64_sys_openat+0x20/0x30
[91712.712642]  do_syscall_64+0x57/0x190
[91712.712644]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[91712.712645] RIP: 0033:0x7fb2332ffad4
[91712.712650] Code: Bad RIP value.
[91712.712651] RSP: 002b:00007fb23364e6d0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
[91712.712652] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb2332ffad4
[91712.712653] RDX: 0000000000008802 RSI: 00007fb23364e7e0 RDI: 00000000ffffff9c
[91712.712654] RBP: 00007fb23364e7e0 R08: 0000000000000000 R09: 00007fb23364eaf0
[91712.712654] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000008802
[91712.712655] R13: 00007ffe5360310f R14: 0000562e1065b7e0 R15: 00007fb23364efc0

Do you have an idea what I did wrong there?

edit
Sorry, my bad. Did something wrong. After re-compiling the dvb-core module and rebooting it works ;)

Thank you for that nice piece of software. It still does a good job ;)

segfault with simultaneous recordings

Hi, dvbloopback / descrambler (ffdecsawrapper) works fine as long as only one of the dvbloopback devices is being used. If I start another recording / live-tv, it has green artifacts and eventually ffdecsawrapper segfaults soon.

Using the debug version and the resulting core dump, gdb shows this backtrace:

/usr/bin/ffdecsawrapper --join 0:3 --join 1:4 --join 2:5 --cam-budget --sid-nocache --buffer 16M --debug 0 --cam-dir /etc/ffdecsawrapper

#0  0x000055b43bbff3ab in stream_cypher_group_init(stream_regs*, long long __vector(2) (*) [4], long long __vector(2) (*) [4], unsigned char*) ()
[Current thread is 1 (Thread 0x7fd9e820d700 (LWP 2663019))]
(gdb) bt
#0  0x000055b43bbff3ab in stream_cypher_group_init(stream_regs*, long long __vector(2) (*) [4], long long __vector(2) (*) [4], unsigned char*) ()
#1  0x000055b43bc02c57 in decrypt_packets(void*, unsigned char**) ()
#2  0x000055b43bbe2596 in process_ts (csa=0x55b43bf2fec0, 
    buffer=0x7fd9e9aa1d58 "G\001\377\030\003\021\200\344\302\030\003B-\266{\375\023\255EQܹ\325\065Ӟ;\250\003\034\232\375\367\027\064\033\275VL\034\310(\314\310\062\350FU\310jz\016\036\030v\266\232\251\005p\363\023\bw\022\006\f\371\374\366\227\262\231\360\212\210\022\203IM%\217졞?\273\307\344+\224\023EI8\224j4J\036e\303B\326f\372F\353渏\310Ɋ\232\372\027dV\237\271`L\362\210U\246b\202\064\262\332\377p\357\371Q\213\344\313V\357\001\064\020\365\273\370=\315gb\303\070G2s\243\033\214⒀\376\220\223*\016h\v|\026i\254\341\364@\244\204òׯ5h\356\234\066G\001\377\031O\243\064\321\036,\362T"..., end=34968, force=0) at dvblb_plugins/plugin_ffdecsa.c:327
#3  0x000055b43bbe2fec in process_ffd (msg=0x55b43be9f770, priority=1) at dvblb_plugins/plugin_ffdecsa.c:512
#4  0x000055b43bbd8258 in msg_loop (arg=0x1) at src/msg_passing.c:118
#5  0x00007fd9ed1fb609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6  0x00007fd9ecdd5293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95```

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.