[vdr] Re: Improved CAM support in VDR

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Reinhard Walter Buchner wrote:
>
> Hi Klaus,
>
> The CAM support  doesn't work  ;. . .o(( sniff for me

Ok, in the following I've stripped all data from tests with the old FW,
since these don't have any meaning here.

> Here is the info I can provide based on my tests. My
> CI Revision is 1.4 & my DVB is Rev 1.6.
>
> I enabled both debug lines in ci.c.
>
> First TEST: MM with GlobeCam 2.04
>
> Using the new firm & driver:
> linux:/usr/local/src/VDR # ./vdr
> --> 00 01 82 01 01
> <-- 00 01 83 01 01 80 02 01 80
> ..................
> 2 CAM Slots found
> I can't access the CAM Menu
> It doesn't decrypt!! (probably the worst problem)
>
> The numbers above are all I get, even if I switch
> channels. The number of dots underneath also
> don't change .

What's happening here is that VDR sends the initial [00 01 82 01 01] sequence,
which the CAM replies to with [00 01 83 01 01 80 02 01 80]. With the Irdeto AllCAM
this sequence looks like this:

--> 00 01 82 01 01
<-- 00 01 83 01 01 80 02 01 00
    .  .  .  .  .  .  .  .  .

Now the difference is that the Irdeto AllCAM responds to the T_CREATE_TC message
with a T_CTC_REPLY that does _not_ indicate the availability of data, while the MM
indicates data right away (that's the 80 at the end of the message). Apparently
my CI interface didn't expect data to be available imemdiately after the initial
T_CREATE_TC message and so didn't correctly establish the connection. I've changed
this now and uploaded a new version of VDR/ci.c to

  ftp://ftp.cadsoft.de/pub/etc/ci.c

Please get that one and try again (I can't test this here since my CAM doesn't
show this behaviour - which, BTW is, of course, in total agreement with the standard,
it was my fault...).

>
> [... old FW...]
>
> Second TEST
> new firm & Alphacrypt 1.0
> linux:/usr/local/src/VDR # ./vdr
> --> 00 01 82 01 01
> <-- 00 01 80 02 01 00
> . . . . . .
> 2 CAM Slots found
> CAM NOT FOUND
> It doesn't Decrypt
>
> Interestingly enough this NO longer locks
> up the driver or vdr. The Alphacrypt was a
> prime candidate to kill the DVB driver &
> with it VDR.

Ok, here the CAM doesn't reply with the expected T_CTC_REPLY, but rather behaves
as if there's nothing to do. I suggest we look into this further once the MM CAM
above works, since that one at least appears to do the initial handshake.

>
> [... old FW...]
>
> Third  TEST
> new firm & Alphacrypt 1.1
> linux:/usr/local/src/VDR # ./vdr
> --> 00 01 82 01 01
> <-- 00 01 80 02 01 00
> . . . . . .
> 2 CAM Slots found
> CAM NOT FOUND
> It doesn't Decrypt
>
> Interestingly enough this NO longer locks
> up the driver or vdr. The Alphacrypt was a
> prime candidate to kill the DVB driver &
> with it VDR.

Same as with the Alphacrypt 1.0, let's look into this later.

>
> [...old FW...]
>

So, please get the new verison of VDR/ci.c and let me know what happens.

Klaus
--
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.