Klaus Schmidinger wrote:
Please start a new thread for a new topic ( I've at least changed the
subject).
Yes, You are right. Sorry.
Please activate the DumpTPDUDataTransfer and DebugProtocol switches
in ci.c
and check whether VDR receives a reply to its QUERY.
Honestly, I don't understand what info is exchanged. :/ File attached.
Arthur
Slot 1: reset...ok. Slot 1: module present Slot 1: module ready Slot 1: creating connection 0/1 Slot 1: create connection 0/1 1: --> 00 01 82 01 01 1: <-- 00 01 83 01 01 80 02 01 00 . . . . . . . . . Slot 1: connection created 0/1 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 07 01 91 04 00 01 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00010041 Slot 1: new Resource Manager (session id 1) 1: --> 00 01 A0 0A 01 92 07 00 00 01 00 41 00 01 Slot 1: ==> Profile Enq (1) 1: --> 00 01 A0 09 01 90 02 00 01 9F 80 10 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 09 01 90 02 00 01 9F 80 11 00 80 02 01 00 . . . . . . . . . . . . . . . . . Slot 1: <== Profile (1) Slot 1: ==> Profile Change (1) 1: --> 00 01 A0 09 01 90 02 00 01 9F 80 12 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 09 01 90 02 00 01 9F 80 10 00 80 02 01 00 . . . . . . . . . . . . . . . . . Slot 1: <== Profile Enquiry (1) Slot 1: ==> Profile (1) 1: --> 00 01 A0 1D 01 90 02 00 01 9F 80 11 14 00 01 00 41 00 02 00 41 00 03 00 41 00 24 00 41 00 40 00 41 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 07 01 91 04 00 02 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00020041 Slot 1: new Application Information (session id 2) 1: --> 00 01 A0 0A 01 92 07 00 00 02 00 41 00 02 Slot 1: ==> Application Info Enq (2) 1: --> 00 01 A0 09 01 90 02 00 02 9F 80 20 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 1E 01 90 02 00 02 9F 80 21 15 01 00 00 03 3D 0F 54 53 44 20 43 72 79 70 74 20 43 6F 6E 61 78 80 02 01 00 . . . . . . . . . . . ! . . . . . = . T S D C r y p t C o n a x . . . . Slot 1: <== Application Info (2) Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 07 01 91 04 00 03 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00030041 Slot 1: new Conditional Access Support (session id 3) 1: --> 00 01 A0 0A 01 92 07 00 00 03 00 41 00 03 Slot 1: ==> Ca Info Enq (3) 1: --> 00 01 A0 09 01 90 02 00 03 9F 80 30 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 0B 01 90 02 00 03 9F 80 31 02 0B 00 80 02 01 00 . . . . . . . . . . . 1 . . . . . . . Slot 1: <== Ca Info (3) 0B00 Slot 1: ==> Ca Pmt (3) 3 3 1: --> 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03
Klaus Schmidinger wrote:
That is, no reply in this point. Because I got second confirmation from TechniSat Support about multiple decryption possibility, I made small test changes in ci.c file (ci.diff).
After that multiple decryption works! I know, this is not right solution, but now it proved that CAM works in principle. Why it doesn't reply to query at vdr startup, i don't know, but later it does (log.txt).
Any ideas for an elegant solution?
Arthur
--- ci.c.orig 2008-04-15 14:55:59.000000000 +0300 +++ ci.c 2008-04-15 14:58:41.000000000 +0300 @@ -771,6 +771,7 @@ } dbgprotocol("\n"); } + state = 6; //AK break; default: esyslog("ERROR: CAM %d: conditional access support: unknown tag %06X", Tc()->CamSlot()->SlotNumber(), Tag); } @@ -789,6 +790,7 @@ else if (state == 3 && timer.TimedOut()) { dsyslog("CAM %d: doesn't reply to QUERY - only a single channel can be decrypted", Tc()->CamSlot()->SlotNumber()); state = 4; // normal operation + repliesToQuery = true; //AK } }
@@ -1888,7 +1890,7 @@ } }
-#define QUERY_REPLY_WAIT 100 // ms to wait between checks for a reply +#define QUERY_REPLY_WAIT 300 // ms to wait between checks for a reply //AK
bool cCamSlot::CanDecrypt(const cChannel *Channel) {
root@vdr:~# runvdr Slot 1: reset...ok. Slot 1: module present Slot 1: module ready Slot 1: creating connection 0/1 ------------------------- MakePrimaryDevice: 1 ========================= SetVideoFormat: 0 SetVolumeDevice: 200 Slot 1: create connection 0/1 1: --> 00 01 82 01 01 1: <-- 00 01 83 01 01 80 02 01 00 . . . . . . . . . Slot 1: connection created 0/1 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 07 01 91 04 00 01 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00010041 Slot 1: new Resource Manager (session id 1) 1: --> 00 01 A0 0A 01 92 07 00 00 01 00 41 00 01 Slot 1: ==> Profile Enq (1) 1: --> 00 01 A0 09 01 90 02 00 01 9F 80 10 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 09 01 90 02 00 01 9F 80 11 00 80 02 01 00 . . . . . . . . . . . . . . . . . Slot 1: <== Profile (1) Slot 1: ==> Profile Change (1) 1: --> 00 01 A0 09 01 90 02 00 01 9F 80 12 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 09 01 90 02 00 01 9F 80 10 00 80 02 01 00 . . . . . . . . . . . . . . . . . Slot 1: <== Profile Enquiry (1) Slot 1: ==> Profile (1) 1: --> 00 01 A0 1D 01 90 02 00 01 9F 80 11 14 00 01 00 41 00 02 00 41 00 03 00 41 00 24 00 41 00 40 00 41 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 07 01 91 04 00 02 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00020041 Slot 1: new Application Information (session id 2) 1: --> 00 01 A0 0A 01 92 07 00 00 02 00 41 00 02 Slot 1: ==> Application Info Enq (2) 1: --> 00 01 A0 09 01 90 02 00 02 9F 80 20 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 1E 01 90 02 00 02 9F 80 21 15 01 00 00 03 3D 0F 54 53 44 20 43 72 79 70 74 20 43 6F 6E 61 78 80 02 01 00 . . . . . . . . . . . ! . . . . . = . T S D C r y p t C o n a x . . . . Slot 1: <== Application Info (2) Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 07 01 91 04 00 03 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00030041 Slot 1: new Conditional Access Support (session id 3) 1: --> 00 01 A0 0A 01 92 07 00 00 03 00 41 00 03 Slot 1: ==> Ca Info Enq (3) 1: --> 00 01 A0 09 01 90 02 00 03 9F 80 30 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 0B 01 90 02 00 03 9F 80 31 02 0B 00 80 02 01 00 . . . . . . . . . . . 1 . . . . . . . Slot 1: <== Ca Info (3) 0B00 Slot 1: ==> Ca Pmt (3) 3 3 1: --> 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 1A 01 90 02 00 03 9F 80 32 11 04 04 42 01 00 01 01 02 08 C0 00 00 04 08 C1 00 00 SetAudioChannelDevice: 0 SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 SetVolumeDevice: 200 SetPlayMode: 1 frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00) SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 04 42 01 00 07 01 09 04 0B 00 E3 EC Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 04 42 01 00 07 01 09 04 0B 00 E3 EC 02 08 C0 00 00 04 08 C1 00 00 SetAudioChannelDevice: 0 SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 SetPlayMode: 1 video: synced early vdr-xine: Client connecting ... vdr-xine: Client connected!
=====> Recording started
=====> Switching to the next channel
SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 4 3 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 04 78 01 00 07 03 09 04 0B 00 E3 EE 02 08 A2 00 00 04 08 A3 00 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 13 01 90 02 00 03 9F 80 33 0A 04 78 01 82 08 A2 82 08 A3 82 80 02 01 00 . . . . . . . . . . . 3 . . x . . . . . . . . . . . . Slot 1: <== Ca Pmt Reply (3) 1144 01 82 2210=82 2211=82 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 04 78 01 00 07 01 09 04 0B 00 E3 EE 02 08 A2 00 00 04 08 A3 00 00 SetAudioChannelDevice: 0 SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 SetPlayMode: 1 frame: (0, 0)-(720, 576), zoom: (1,00, 1,00) video: synced early
=====> Got picture
On 04/15/08 14:33, Arthur Konovalov wrote:
Can you narrow down which of these three changes is actually necessary to make it work? I would assume that
state = 4; // normal operation + repliesToQuery = true; //AK }
by itself should do the trick.
Please revert all your changes and do just
#define QUERY_REPLY_TIMEOUT 5000 // ms to wait for a reply to a query
(change 2000 to 5000 in this line). If this doesn't help, try
#define QUERY_WAIT_TIME 3000 // ms to wait before sending a query
as well (and check whether any one of these changes helps by itself).
Klaus
Klaus Schmidinger wrote:
Can you narrow down which of these three changes is actually necessary to make it work?
I can repeat tests tomorrow, but I recall that this (it was first change):
and this (next change, because first doesn't help and I saw replays to query: Slot 1: <== Ca Pmt Reply (3) 1144 01 82 2210=82 2211=82): dbgprotocol("\n"); } + state = 6; //AK break;
was necessary in this case.
#define QUERY_REPLY_TIMEOUT 5000 // ms to wait for a reply to a query (change 2000 to 5000 in this line). If this doesn't help, try
Previously tried with 6000, negative.
#define QUERY_WAIT_TIME 3000 // ms to wait before sending a query
Will try tomorrow.
Arthur
Arthur Konovalov wrote:
Confirmed, only with those 2 changes multiple decryption works.
#define QUERY_WAIT_TIME 3000 // ms to wait before sending a query
Will try tomorrow.
Doesn't help.
Added syslog debug entries like this:
if (l <= 2){ ok = CA_ENABLE(caepl) == CAEI_POSSIBLE; dsyslog("AK: CA_ENABLE(caepl): %d, ok: %d", CA_ENABLE(caepl),ok); } while (l > 2) { uint16_t pid = ((uint16_t)(*d) << 8) | *(d + 1); unsigned char caees = *(d + 2); dbgprotocol(" %d=%02X", pid, caees); d += 3; l -= 3; dsyslog("AK: CA_ENABLE(caees): %d, ok: %d", CA_ENABLE(caees),ok); if (CA_ENABLE(caees) != CAEI_POSSIBLE){ ok = false; dsyslog("AK: ok set to false. state: %d", state); } } if (ok){ dsyslog("AK: ok true!"); state = 6; // descrambling possible } } } } dbgprotocol("\n"); } dsyslog("AK: state: %d", state); break;
And syslog (with 'repliesToQuery = true;' only):
Apr 16 11:00:35 vdr vdr: [17443] switching to channel 136 Apr 16 11:00:36 vdr vdr: [17447] AK: CA_ENABLE(caees): 2, ok: 1 Apr 16 11:00:36 vdr vdr: [17447] AK: ok set to false. state: 5 Apr 16 11:00:36 vdr vdr: [17447] AK: CA_ENABLE(caees): 2, ok: 0 Apr 16 11:00:36 vdr vdr: [17447] AK: ok set to false. state: 5 Apr 16 11:00:36 vdr vdr: [17447] AK: state: 5 Apr 16 11:00:36 vdr vdr: [17443] info: Channel not available!
It seems that 'if (CA_ENABLE(caees) != CAEI_POSSIBLE)' is reason of fault and 'state' always stay false. Unfortunately I don't understand this logic here :/
Arthur
-
Arthur Konovalov -
Arthur Konovalov -
Klaus Schmidinger