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
On 04/12/08 23:09, Arthur Konovalov wrote:
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.
Does the log really end at that point?
If there is no "Ca Pmt Reply" then the CAM doesn't reply to the query.
Klaus
Klaus Schmidinger wrote:
Does the log really end at that point?
If there is no "Ca Pmt Reply" then the CAM doesn't reply to the query.
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:
Klaus Schmidinger wrote:
Does the log really end at that point?
If there is no "Ca Pmt Reply" then the CAM doesn't reply to the query.
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?
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):
state = 4; // normal operation
repliesToQuery = true; //AK }
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:
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):
state = 4; // normal operation
repliesToQuery = true; //AK }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.
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