Message ID | 4804A0B0.7090104@hot.ee |
---|---|
State | New |
Headers |
Received: from mail2.elion.ee ([88.196.160.58] helo=mail1.elion.ee) by www.linuxtv.org with esmtp (Exim 4.63) (envelope-from <kasjas@hot.ee>) id 1JlkMl-0005qC-PM for vdr@linuxtv.org; Tue, 15 Apr 2008 14:34:29 +0200 Received: from mail.elion.ee (192.168.90.120) by mail2.elion.ee (192.168.90.164) with Microsoft SMTP Server id 8.1.240.5; Tue, 15 Apr 2008 15:32:50 +0300 Received: from elion.ee ([192.168.90.120]) by mail.elion.ee with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 15:32:52 +0300 Received: from [192.168.35.6] ([192.168.35.6]) by elion.ee over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 15:32:51 +0300 Message-ID: <4804A0B0.7090104@hot.ee> Date: Tue, 15 Apr 2008 15:33:52 +0300 From: Arthur Konovalov <kasjas@hot.ee> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: VDR Mailing List <vdr@linuxtv.org> References: <48012524.8000600@hot.ee> <480127F8.2080200@cadsoft.de> In-Reply-To: <480127F8.2080200@cadsoft.de> Content-Type: multipart/mixed; boundary="------------020702020904060304060001" X-OriginalArrivalTime: 15 Apr 2008 12:32:51.0977 (UTC) FILETIME=[D26F2F90:01C89EF4] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15850.007 X-TM-AS-Result: No--18.253300-8.000000-31 X-LSpam-Score: -2.6 (--) X-LSpam-Report: No, score=-2.6 required=5.0 tests=BAYES_00=-2.599 autolearn=ham Subject: Re: [vdr] Multiple decryption with TechniCrypt CW CAM X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Tue, 15 Apr 2008 12:34:29 -0000 Status: O X-Status: X-Keywords: X-UID: 16508 |
Commit Message
Arthur Konovalov
April 15, 2008, 12:33 p.m. UTC
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 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
Comments
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
--- 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) {