[linux-dvb] [PATCH] dst_ca : convert back Application Info DST reply to EN 50221 message.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Perceval Anichini wrote:

>	Hello !
>
>As fas as i understand, the DST_CA driver works as described below :
>	- The driver is fed with EN 50221 messages.
>	- The driver translates these messages to DST proprietary
>	command
>	- The DST process the command and reply to the driver in a
>	proprietary format (!@*#!@^$!&*!($@!#@!#@!)
>  
>
You can take a look at how it is implemented in

http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel/linux/Documentation/dvb/ci.txt?rev=1.4&view=markup

>	- The driver return the 'data' as is.
>
>It seems to me that it would be interesting to return replies in EN
>50221 format. Below is a patch that does it for the 'Application Info'
>reply, as described page 28 of the standard. I will send patches for
>other replies if i can retrieve some documentations about the DST
>part of the card.
>
>  
>

You mean the object return values, dont you ? Hmm.. if you would like 
that to be included since it would break dst_util, it would be nice if 
you would include a patch for the same for

http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-apps/util/dst-utils/
But the problem there is calculating the length of the messages. Right 
now it is a blind read. In exact terms need to fix that first, to do 
this, since length of message.

>	Moreover, I don't understand the ca_msg structure.
>	- Why is the msg field only 256 bytes long ? If I understood
>the standard, an EN 50221 message can be up to 65536 + 6 (3 bytes for
>tag, up to 3 bytes for field_length, and 65536 bytes of payload.) Is it
>a kernel related limitation (?)
>  
>
If you are looking at EN50221 implementation,

Refer EN50221 Section 8.3.2 as well as

R206, page 34 CA_PMT and friends

>	- I do not understand the index and type member. They seems to
>be always set to zero by the driver.
>  
>
Refer Linux DVB-API. The implementation of the HLCI API worked from 
start to leave out length from the header to avoid confusion, thus 
having length encoded as ASN.1 only.

>	- I do think I understand the length part :) But the driver
>set it to 0 too...
>
>For information, we are using a Technisat Skystar 1/CI, with an ASTON
>CAM PRO Viaccess (firmware 2.0100) .
>  
>

I don't know whether this is good news or not.
The list of supported CAM's are like this .. maybe it might be of some help.
This is regarding the state of the DST, Regarding the Skystar-1, i have 
not much of an idea. This might probably be applicable for you.

Crypto Works	1.0 	OK		
Cryptoworks 	12011	N/A???CAM?		
Magic	1.1	OK	76.5	NG
Dragon I & II	2.05, 2.06	N/A???CAM?		
PentaCrypt	1.05	OK		
Irdeto	2.09	OK	110.5	OK
Irdeto 	1.06	N/A???CAM?		
Free CAM2-018	??	OK		
AstonCrypt	1.03	OK		
Viaccess 	1.0 V481	OK	76.5	OK
Viaccess 	1.0 V483	OK	76.5	OK
AlphaCrypt 	1.0	OK		
Aston I	1.05	OK		
AstonII	??	NG		
SECA I & II	1.05	N/A???CAM?		
Nagravision	??	OK		
Free-X-TV	2.26	OK	95	OK
Free-X-TV	2.0	N/A???CAM?		
Module	0.78	OK		
Zeta Cam	??	OK	76.5/95	OK
Conax	4.00e	OK		
Conax 	4.0	N/A???CAM?		
BataCrypt	1.0	N/A???CAM?		
				
?????Pass(????????)   P/Pass(?????????)   NG(??????)   N/A(??????????)		


>- The second patch included corrects the asn_1_decode function.
>Patches apply in following order :
>	- patch-1-dst_ca-application-info-en50221
>	- patch-2-dst_ca-asn_1_decode
>
>Thanks a lot.
>
>Perceval.
>  
>
>------------------------------------------------------------------------
>
>--- dvb-kernel.orig/linux/drivers/media/dvb/bt8xx/dst_ca.c	2005-09-02 21:41:47.000000000 +0200
>+++ dvb-kernel/linux/drivers/media/dvb/bt8xx/dst_ca.c	2005-09-06 10:22:32.000000000 +0200
>@@ -163,6 +163,27 @@
> 		(state->messages[10] << 8) | state->messages[11], __FUNCTION__, (char *)(&state->messages[12]));
> 	dprintk(verbose, DST_CA_INFO, 1, " ==================================================================================================");
> 
>+	// Now, we need to build the correct EN 50221 
>+	// First, replace weird DST reply by EN 50221 Application Info SPDU (p 28)
>+	state->messages[0] = 0x9f;
>+	state->messages[1] = 0x80;
>+	state->messages[2] = 0x21;
>+
>+	// Second, compute field_length :
>+	//   FIXME -> might be coded on more than 1 byte.
>  
>
>+	//   FIXME -> Information already coded in state->messages[5] (???)
>  
>
>+	state->messages[3] = 6 + strlen (state->messages + 12);
>  
>

See my comment on this issue.

>+	
>+	// Third, fill application_type.
>+	state->messages[4] = state->messages[7];
>+	
>+	// Third, move application_manufacturer and manufacturer_code to the correct place.
>+	memmove (state->messages + 5, state->messages + 8, 2 * sizeof (u16));
>+	
>+	// And last, format correctly the menu_string_length
>+	state->messages[9] = strlen (state->messages + 12);
>+	memmove (state->messages + 10, state->messages + 12, state->messages[9]);
>+	
> 	return 0;
> }
>  
>


>--- dvb-kernel.orig/linux/drivers/media/dvb/bt8xx/dst_ca.c	2005-09-02 21:41:47.000000000 +0200
>+++ dvb-kernel/linux/drivers/media/dvb/bt8xx/dst_ca.c	2005-09-06 10:22:32.000000000 +0200
>@@ -329,7 +350,8 @@
> 	} else {
> 		word_count = length_field & 0x7f;
> 		for (count = 0; count < word_count; count++) {
>-			length = (length | asn_1_array[count + 1]) << 8;
>+			length = length  << 8;
>+                        length += asn_1_array[count + 1];
> 			dprintk(verbose, DST_CA_DEBUG, 1, " Length=[%04x]", length);
> 		}
> 	}
>  
>
>  
>
I will check this in, would you mind the signed-off-by: line ?


Thanks,
Manu




[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux