Suggesting boxes that have public servers is madness, UPC and the police already raided startview in ireland, kryptview wont be far off IMO.
Your lucky if sports will clear on the Starview HD, never mind the HD channels.
Dreambox.. Working solution?
- Thread starter GavSt
- Start date
Suggesting boxes that have public servers is madness, UPC and the police already raided startview in ireland, kryptview wont be far off IMO.
Your lucky if sports will clear on the Starview HD, never mind the HD channels.
Evastar
Inactive User
The Starview setup seemed to be pretty amateurish, i don't see what it has to do with kryptview.
wino
Inactive User
- Joined
- Jun 30, 2005
- Messages
- 465
- Reaction score
- 14
sky can also share over 60 clients on one card if set up right with the correct clock frequency and broadband speed ect i have seen it with 65 with no pic freeze at all
well i have 120 on my sky card no freeze what so ever and have 250 on my three n3 cards no freeze what so ever.
and before any one says trader not one person get charged a penny as im happy to have it running
i have sky half deal package
and the n3 is multiroom so i don't mine and the b/s speed is 50meg which i use .
so if i can do it can't see why any one should charge anyone anything.
and if i wanted other channels like from foreign sats i know i can get them free.
it's called sharing.
and before any one says trader not one person get charged a penny as im happy to have it running
i have sky half deal package
and the n3 is multiroom so i don't mine and the b/s speed is 50meg which i use .
so if i can do it can't see why any one should charge anyone anything.
and if i wanted other channels like from foreign sats i know i can get them free.
it's called sharing.
Fano
Inactive User
60 active clients on one card is not feasible,it will freeze like mad.
You can overclock it all you want but that load especially if different clients are watching different channels will cause freezing.
As for 120 clients ,well thats just ridiculous.Thats a possible 120 ecms per 6 secs,so one ecm every 50ms,the card wont know whats going on.
You may have 60 clients but whats the most active at any one time without freezing ,thats the most important number .
The best commercial servers have a limit of 10 clients per card to ensure a freeze free service so I honestly dont know how 60-120 is feasible.
Midnight Tboy
Inactive User
- Joined
- Feb 23, 2008
- Messages
- 851
- Reaction score
- 7
out of curiosity...how much do these commercial servers cost? After all if too much then sometimes makes no sense to try it...for sake of saving not a lot.......other than some people just liking the challenge of course
Liam1611
Inactive User
Why do people insist on saying 30 0r 40 clients max when with the correct sever setup it`s a lot higher
Probably because they don't know what can be achieved with a decent server running specific software. If people knew what was achievable, 100's of people connected to 1 card then I think it would be the downfall of C/S. Which I personally don't want to see. Although I do think I have opened Pandora's box with the above comment.
Here's a few extracts from the readme file.
Used properly a cluster of 2 proxies could handle several thousand client with a handful of cards, bandwidth being the only real limit.
Caching is centralized to the proxy (ideally the caches of the individual cardservers will never score a hit). This means that as long as someone in the same proxy or proxy cluster is watching a service, an infinite number of others can watch the same service without causing any extra traffic towards the card servers. Once there are enough cards connected to always keep all the providers services in cache at any given moment, the number of users becomes limited only by bandwidth.
Let the enquires commence.
Regards
Liam
deangreen4
Inactive User
- Joined
- May 14, 2005
- Messages
- 75
- Reaction score
- 0
I can see how, if using a cache, the number would be increased dramatically. I presume the idea is once all possible combinations of channel/key combos have been made they would live on the cache and given an expiry time. Only after the expiry time had been reached, it would be necessary to re-query 'the master'
What software is used for this sort of thing? I love playing with this sort of thing, have some nice kit and oodles of bandwidth and would be up for a challenge
What software is used for this sort of thing? I love playing with this sort of thing, have some nice kit and oodles of bandwidth and would be up for a challenge
What software is used for this sort of thing? I love playing with this sort of thing, have some nice kit and oodles of bandwidth and would be up for a challenge
At a guess I would say its probably always custom software designed specifically for the network topology in use and the particular systems that it offers.
Generally though, it should not be difficult to write such a piece of software. Only one box will ever communicate with the actual card (the source CW server) and this will then transmit the CW's that its allocated along with their channel ID's (a single CW server might handle 4 or 5 transponders, with each transponder having maybe 6 channels - so upto 30 channels from a single box/card) to the main server. Its this server that will buffer the information (possibly using standard database type functions) and re-transmit the required CW's back to the multiple clients.
I doubt they have written anything new, there is software that can do just that now.
With options for each server to either directly cluster together or connect to a central tracker and do near enough what you describe.
At a rough estimate you would need 3-4 cards to serve an infinite number of people, that 3-4 is not taking into account any redundncy though. So add a few more an off you go, nothing new its been done for ages now.
Si
Liam1611
Inactive User
Why don't you put this text in Google hit search and then see what it brings up.
Caching is centralized to the proxy (ideally the caches of the individual cardservers will never score a hit). This means that as long as someone in the same proxy or proxy cluster is watching a service, an infinite number of others can watch the same service without causing any extra traffic towards the card servers. Once there are enough cards connected to always keep all the providers services in cache at any given moment, the number of users becomes limited only by bandwidth.
Regards
Liam
Caching is centralized to the proxy (ideally the caches of the individual cardservers will never score a hit). This means that as long as someone in the same proxy or proxy cluster is watching a service, an infinite number of others can watch the same service without causing any extra traffic towards the card servers. Once there are enough cards connected to always keep all the providers services in cache at any given moment, the number of users becomes limited only by bandwidth.
Regards
Liam
I'm not planning to use it just yet... But it's something I have though long time ago. What has put me off is the fact that not many proxy are realable and setting up a dual mirror proxy it's quite complext! (otherwise we would have that implemented on our favourite P2P for file sharing?).
Sorry if I'm not researching on subject. But I will do.
deangreen4
Inactive User
- Joined
- May 14, 2005
- Messages
- 75
- Reaction score
- 0
Proxies arent that hard to setup. It would depend how the software wanted to do the query and what it asking. If the queries were http-like then using something like a pair of HAProxy servers and a load balanced set behind would give a lot of redundancy. If a database type thing was needed then either a MySQL master-slave pair or a mongo DB setup would do this with ease. I expect mongo would be faster and, as its horizontally scalable, could handle a lot of clients
here`s some intresting reading guys , i dont know if GENDT08 will work for us but worth trying :
c/p
RQCS Setup
This is a how-to guide to set up RQCS server using ISO programmer utilizing N2 or N3 card. This guide
only shows how to setup using Windows platform. (I might update to include linux, but that’s for later)
Information in this guide is written for educational purpose that you may use to learn. Please use at
your own risk.
Required Equipment:
1. Computer
2. ISO Programmer
3. N2 / N3 Card
Steps:
1. First of all, we need to get your ISO configured to your computer. You can use standard ISO
programmer or USB ISO Programmer. I have had no issues using the USB ISO Programmer; it
has worked flawlessly for me (TurboMax).
2. Assuming you have working ISO Programmer, you need to know what COM port it is using. You
should be able to find this out in Device Manger of your computer.
3. After you have downloaded the RQCS, unzip to a folder. Open the folder, you will find 6 files.
You only need 2 of them in order to run rqcs server:
a. rqcs.conf (configuration file)
b. rqcs.exe (window executable)
4. The configuration file in two main sections: General and Slots. General section covers
information about platform of the server, debugging information, and logging. Slot section
covers information pertaining to each card being used. You could run multiple cards using
multiple slots. For example, you could use 2 cards that different subscription to view all
channels on the client. Note: both cards need to same encryptions (N2 or N3) if you going to
use echo client with echo irds. Otherwise, it won’t work.
In order to run the server, you basically need to fill in the correct information in the
configuration file. I am going go over the configuration lines (Configuration file discusses most
the needed the information). I am only going to highlight the lines that need changing.
5. RQCS.CONF
a. [General ]
i. log_to_file=0 (change 0 to 1 to enable logging)
ii. logfile_name = Path file (i. e. C:\rq-client\client.log)
b. [Logical-Slot:Lower] (for additional slot, change the Lower to another name)
i. enabled=1 <- should be 1 if the slot is enabled.
ii. sci_type=1 <- should be 1 for windows platform
iii. sci_ordinal=0 <- this should match the com port of iso programmer (0 = COM1,
1 = COM2, etc)
iv. Session Key Negotiation section needs to be filled with information from the
card that is being shared. There are 4 different way to authenticate the card.
1. box_key <- If the subbed ird you are using dt08, then providing the
box_key should be enough. You should be able to jtag the receiver and
find the box_key. See the following if your receiver used dt08 or not:
DT08 For d*sh:
a. 2700/2800/3800/3900/4900,
b. 301.10
c. 501
d. 508
e. 6000
SK:
f. 301.13
g. 510
h. 311
i. 322
j. 522/625
k. 721
l. 811
m. 921
n. 942
o. all VIP
2. DT06 <- use this if the subbed ird doesn’t use DT08, then you could use
DT06. If you have Ird that previously used ROM102 and you have image
for it, you should be able to get the DT06 from that image. You need to
provide box_key as well for this to work.
3. CAM N <- similar to above.
4. SK <- this used if the receiver uses Secondary Key. This can be obtained
from the TSOP flash. I believe you can use GenT08 to get it.
v. protocol_server_port <- you can use any port you wish. Just don’t use common
ones, anything above 10000 should be okay unless it being used for another
applications. Default port is 10000.
vi. protocol_server_newcamd_des_key <- this is a encryption algorithm that is
used to encrypt the data being passed to and from server and client. This is 28
digits key. You can make your own.
vii. protocol_server_users <- on this line, you can specify the users that can connect
to this server. The specification are very easy and between every user, “|” used
to separated. (i.e. userass|user1ass1|user2ass3|user4ass4)
viii. protocol_server_max_active_users <- you can use this to limit the number of
users that can log on the server.
6. This ends the configuration the lower slot. You can add more slots if you wish you multiple
cards.
Starting the Server:
Now, we can try to start the server to see if it works. Click on the rqcs.exe. It should open a dos window
with following information:
****************** Starting log on Sun Mar 22 15:29:00 2009 ******************
Configuration settings:
Debug level: 3
Starting Logical Slot 'Lower' [Users: 15]
------------------------------------------------------------------------------
Device Path: COM1 | Listening Port: 10000
------------------------------------------------------------------------------
Opening sci... Done
Detecting card... Card present
Resetting card... Done
Identifying card type...
Historical bytes: D N A S P 2 4 1 D s h H 0 2
44 4E 41 53 50 32 34 31 20 44 73 68 48 30 32
Card type: Nagra
ROM Revision: 241
EEPROM Revision: DshH02
Configuring sci...
SCI | Conv: Inverse | Baud Rate: 115200 | Stop Bits: 2 | Parity: Odd
Slot custom parameters:
des_key: **************************** (THIS IS YOUR DES KEY: 26 DIGITS)
box_key: *************** (THIS IS YOUR BOX_KEY OF YOUR IRD: 16 DIGITS)
dt06_key_0d:
cam_n:
secondary_key:
rsa_key:
Card start-up initialization...
Using DT08 session negotiation method:
Setting Field Size: Done
Retrieving IRD serial number: ******** (THIS IS YOUR IRD SERIAL)
Retrieving CAM serial number: ******** (THIS IS YOUR IRD SERIAL)
Retrieving System IDs: 0101,0102,0106 <- THESE ARE ALL THE SYSTEM IDS ON YOUR CARD.
Retrieving CAM modulus (DT08): Done
Retrieving CAM challenge data: Done
Performing Session Key Negotiation: Successful
Starting card worker thread... Done
Starting protocol server on port 10000 [newcamd protocol]
Logical Slot 'Lower' READY!
------------------------------------------------------------------------------
If you screen looks as above, congratulations! Your card is ready to be shared. This has worked for me
on multiple setups. I hope this helps you as well.
Client Setup:
Quote:
Steps-by-Steps Setting up cw800PRV CardSharing service
(Created by skouk007)
Folks, here are the simple steps to set up CW800 with card sharing service assuming you're already have access to
card-share server. If you don't have access yet, you can request with card-sharing admin. There're plenty of Card-
Share services out there so search around and try at your own risk.
For this particular setup I signed up my testing service at: donglefever.com
1. Download the file "rq-sssp-client-1.00-binaries.zip", the file can be downloaded from many FTA sites.
2. Extract the zip file to any directory of your choice. If you extracted to your desktop you will see the folder called
"rq-sssp-client-1.00-binaries".
File descriptions:
- rq-sssp-client.bcm947xx - Binary for WRT54G and compatible linux routers.
- rq-sssp-client.conf - Configuration file. All versions.
- rq-sssp-client.exe - Binary for Windows (WIN32).
- rq-sssp-client.mips - Binary for MIPS boxes (Dreambox DM800HD and DM8000HD).
- rq-sssp-client.ppc - Binary for PowerPC boxes (Dreambox DM500, DM600,DM7000,
DM7020, Triple Dragon and DGStation boxes).
- rq-sssp-client.st40 - Binary for ST40 boxes (Kathrein UFS 910/IPBOX 9000HD).
- rq-sssp-client.x86 - Binary for Linux i386 PC's.
- rq-sssp-client-readme.txt - Description of rq-sssp-client
3. Open rq-sssp-client.conf file with WordPad (Do not open with notepad). See the content of the configuration file
below.
################################################## #############################
# rq-sssp-client configuration file
# All configuration options in this file observe the same format:
# <configuration_name>=<configuration_value
################################################## #############################
########################### general configuration #############################
[General]
# Serial port where the client receiver is connected.
# Examples:
# Linux PC: /dev/ttyS0, /dev/ttyS1, ... /dev/ttyS
# Dreambox/TD/DGS: /dev/tts/0, /dev/tts/1, ... /dev/tts/
# Windows: COM1, COM2, ... COM
serial_port=COM1
# Serial port communication settings.
# Example: 115200|8|N|1 = 115200bps, 8 data bis, no parity, 1 stop bit.
serial_port_settings=115200|8|N|1
# Receiver protocol (only SSSP supported).
# 0 - SSSP
receiver_protocol=0
# Sets the byte write delay. The default value of this parameter is zero.
#
# IMPORTANT: Normally you should *not* need to change this value. But if
# you're having problems with unreliable emu board communication, you can
# tweak this to see if the situation improves. Sensible values for this
# parameter go from 0 to 500 (microseconds).
#
# NOTE: This parameter *has no effect* in the Dreambox versions (PPC and MIPS).
byte_write_delay=0
# Enable or disable background execution
# 0 - Disable
# 1 - Enable
#
# NOTE: Ignored in the WIN32 version.
background_execution=1
# This sets the level of console output for debugging:
# 0 - Silent, 1 - Basic debug info, 2 - Extended debug info,
# 3 - Show all debug info
debug_level=1
# This option enables or disables the writing of debug information to the
# console.
log_to_console=1
# This option enables or disables the writing of console output to a log file
log_to_file=0
# When log_to_file is set to 1, this is the path and filename to write console
# ouput to.
#
# NOTE: In the WIN32 version, if enabled, this should be set to a valid
# Windows/DOS path.
logfile_name=/var/bin/rq-sssp-client.log
# URL of card-server to use, formats are as follows:
#
# newcamd://<username>:<password>@<hostname>:<port>/<des_key>/[EMM]
#
# Example:
# newcamd://foo:[email protected]:12345/0 ... B371E3/EMM
#
# NOTE: The "EMM" suffix is optional and tells rq-sssp-client whether
# to send EMM's to the card-server or not. Enabling or disabling this only
# has effect if the card-server is configured to accept emms from this client.
#
# Multiple card-server url's can be specified for server fail-over.
# If the emu fails to connect or fails to get valid CW's, it will try to
# connect to other servers in a round-robin fashion.
# Up to 65 servers can be added from index 0 to 63, plus a non-indexed parameter
# named "card_server_url"
# card_server_url=newcamd://dummy:[email protected]:10000/0102030405060708091011121314/EMM
# card_server_url_0=newcamd://dummy_2:[email protected]:10000/0102030405060708091011121314/EMM
# card_server_url_1=newcamd://dummy_3:[email protected]:10000/0102030405060708091011121314/EMM
#
# This is your Card-Share Service access that was granted by Admin (below is just example only)
card_server_url=newcamd://foo:[email protected]:12345/0CE3476FF2E1C9D9A0A109B371E3
Please note that in this configuration file only two lines needed to modify: Make changes to
these two lines in green and saved it.
a. Serial port - if using Windows default port=COM1. If your PC not recognize COM1 you can change to COM2,3...etc.
b. URL of card-share server
4. Now connect your cw800 to your PC using rs232 Serial null cable. Connect one end to your PC port and the other end
to your CW800 port.
5. Turn on your PC and your CW800
5a. Enable cw800 card-sharing ecm by pressing: F1 555 (You should see that on the screen)
6. Open rq-sssp-client-1.00-binaries folder and run rq-sssp-client.exe
c/p
RQCS Setup
This is a how-to guide to set up RQCS server using ISO programmer utilizing N2 or N3 card. This guide
only shows how to setup using Windows platform. (I might update to include linux, but that’s for later)
Information in this guide is written for educational purpose that you may use to learn. Please use at
your own risk.
Required Equipment:
1. Computer
2. ISO Programmer
3. N2 / N3 Card
Steps:
1. First of all, we need to get your ISO configured to your computer. You can use standard ISO
programmer or USB ISO Programmer. I have had no issues using the USB ISO Programmer; it
has worked flawlessly for me (TurboMax).
2. Assuming you have working ISO Programmer, you need to know what COM port it is using. You
should be able to find this out in Device Manger of your computer.
3. After you have downloaded the RQCS, unzip to a folder. Open the folder, you will find 6 files.
You only need 2 of them in order to run rqcs server:
a. rqcs.conf (configuration file)
b. rqcs.exe (window executable)
4. The configuration file in two main sections: General and Slots. General section covers
information about platform of the server, debugging information, and logging. Slot section
covers information pertaining to each card being used. You could run multiple cards using
multiple slots. For example, you could use 2 cards that different subscription to view all
channels on the client. Note: both cards need to same encryptions (N2 or N3) if you going to
use echo client with echo irds. Otherwise, it won’t work.
In order to run the server, you basically need to fill in the correct information in the
configuration file. I am going go over the configuration lines (Configuration file discusses most
the needed the information). I am only going to highlight the lines that need changing.
5. RQCS.CONF
a. [General ]
i. log_to_file=0 (change 0 to 1 to enable logging)
ii. logfile_name = Path file (i. e. C:\rq-client\client.log)
b. [Logical-Slot:Lower] (for additional slot, change the Lower to another name)
i. enabled=1 <- should be 1 if the slot is enabled.
ii. sci_type=1 <- should be 1 for windows platform
iii. sci_ordinal=0 <- this should match the com port of iso programmer (0 = COM1,
1 = COM2, etc)
iv. Session Key Negotiation section needs to be filled with information from the
card that is being shared. There are 4 different way to authenticate the card.
1. box_key <- If the subbed ird you are using dt08, then providing the
box_key should be enough. You should be able to jtag the receiver and
find the box_key. See the following if your receiver used dt08 or not:
DT08 For d*sh:
a. 2700/2800/3800/3900/4900,
b. 301.10
c. 501
d. 508
e. 6000
SK:
f. 301.13
g. 510
h. 311
i. 322
j. 522/625
k. 721
l. 811
m. 921
n. 942
o. all VIP
2. DT06 <- use this if the subbed ird doesn’t use DT08, then you could use
DT06. If you have Ird that previously used ROM102 and you have image
for it, you should be able to get the DT06 from that image. You need to
provide box_key as well for this to work.
3. CAM N <- similar to above.
4. SK <- this used if the receiver uses Secondary Key. This can be obtained
from the TSOP flash. I believe you can use GenT08 to get it.
v. protocol_server_port <- you can use any port you wish. Just don’t use common
ones, anything above 10000 should be okay unless it being used for another
applications. Default port is 10000.
vi. protocol_server_newcamd_des_key <- this is a encryption algorithm that is
used to encrypt the data being passed to and from server and client. This is 28
digits key. You can make your own.
vii. protocol_server_users <- on this line, you can specify the users that can connect
to this server. The specification are very easy and between every user, “|” used
to separated. (i.e. userass|user1ass1|user2ass3|user4ass4)
viii. protocol_server_max_active_users <- you can use this to limit the number of
users that can log on the server.
6. This ends the configuration the lower slot. You can add more slots if you wish you multiple
cards.
Starting the Server:
Now, we can try to start the server to see if it works. Click on the rqcs.exe. It should open a dos window
with following information:
****************** Starting log on Sun Mar 22 15:29:00 2009 ******************
Configuration settings:
Debug level: 3
Starting Logical Slot 'Lower' [Users: 15]
------------------------------------------------------------------------------
Device Path: COM1 | Listening Port: 10000
------------------------------------------------------------------------------
Opening sci... Done
Detecting card... Card present
Resetting card... Done
Identifying card type...
Historical bytes: D N A S P 2 4 1 D s h H 0 2
44 4E 41 53 50 32 34 31 20 44 73 68 48 30 32
Card type: Nagra
ROM Revision: 241
EEPROM Revision: DshH02
Configuring sci...
SCI | Conv: Inverse | Baud Rate: 115200 | Stop Bits: 2 | Parity: Odd
Slot custom parameters:
des_key: **************************** (THIS IS YOUR DES KEY: 26 DIGITS)
box_key: *************** (THIS IS YOUR BOX_KEY OF YOUR IRD: 16 DIGITS)
dt06_key_0d:
cam_n:
secondary_key:
rsa_key:
Card start-up initialization...
Using DT08 session negotiation method:
Setting Field Size: Done
Retrieving IRD serial number: ******** (THIS IS YOUR IRD SERIAL)
Retrieving CAM serial number: ******** (THIS IS YOUR IRD SERIAL)
Retrieving System IDs: 0101,0102,0106 <- THESE ARE ALL THE SYSTEM IDS ON YOUR CARD.
Retrieving CAM modulus (DT08): Done
Retrieving CAM challenge data: Done
Performing Session Key Negotiation: Successful
Starting card worker thread... Done
Starting protocol server on port 10000 [newcamd protocol]
Logical Slot 'Lower' READY!
------------------------------------------------------------------------------
If you screen looks as above, congratulations! Your card is ready to be shared. This has worked for me
on multiple setups. I hope this helps you as well.
Client Setup:
Quote:
Steps-by-Steps Setting up cw800PRV CardSharing service
(Created by skouk007)
Folks, here are the simple steps to set up CW800 with card sharing service assuming you're already have access to
card-share server. If you don't have access yet, you can request with card-sharing admin. There're plenty of Card-
Share services out there so search around and try at your own risk.
For this particular setup I signed up my testing service at: donglefever.com
1. Download the file "rq-sssp-client-1.00-binaries.zip", the file can be downloaded from many FTA sites.
2. Extract the zip file to any directory of your choice. If you extracted to your desktop you will see the folder called
"rq-sssp-client-1.00-binaries".
File descriptions:
- rq-sssp-client.bcm947xx - Binary for WRT54G and compatible linux routers.
- rq-sssp-client.conf - Configuration file. All versions.
- rq-sssp-client.exe - Binary for Windows (WIN32).
- rq-sssp-client.mips - Binary for MIPS boxes (Dreambox DM800HD and DM8000HD).
- rq-sssp-client.ppc - Binary for PowerPC boxes (Dreambox DM500, DM600,DM7000,
DM7020, Triple Dragon and DGStation boxes).
- rq-sssp-client.st40 - Binary for ST40 boxes (Kathrein UFS 910/IPBOX 9000HD).
- rq-sssp-client.x86 - Binary for Linux i386 PC's.
- rq-sssp-client-readme.txt - Description of rq-sssp-client
3. Open rq-sssp-client.conf file with WordPad (Do not open with notepad). See the content of the configuration file
below.
################################################## #############################
# rq-sssp-client configuration file
# All configuration options in this file observe the same format:
# <configuration_name>=<configuration_value
################################################## #############################
########################### general configuration #############################
[General]
# Serial port where the client receiver is connected.
# Examples:
# Linux PC: /dev/ttyS0, /dev/ttyS1, ... /dev/ttyS
# Dreambox/TD/DGS: /dev/tts/0, /dev/tts/1, ... /dev/tts/
# Windows: COM1, COM2, ... COM
serial_port=COM1
# Serial port communication settings.
# Example: 115200|8|N|1 = 115200bps, 8 data bis, no parity, 1 stop bit.
serial_port_settings=115200|8|N|1
# Receiver protocol (only SSSP supported).
# 0 - SSSP
receiver_protocol=0
# Sets the byte write delay. The default value of this parameter is zero.
#
# IMPORTANT: Normally you should *not* need to change this value. But if
# you're having problems with unreliable emu board communication, you can
# tweak this to see if the situation improves. Sensible values for this
# parameter go from 0 to 500 (microseconds).
#
# NOTE: This parameter *has no effect* in the Dreambox versions (PPC and MIPS).
byte_write_delay=0
# Enable or disable background execution
# 0 - Disable
# 1 - Enable
#
# NOTE: Ignored in the WIN32 version.
background_execution=1
# This sets the level of console output for debugging:
# 0 - Silent, 1 - Basic debug info, 2 - Extended debug info,
# 3 - Show all debug info
debug_level=1
# This option enables or disables the writing of debug information to the
# console.
log_to_console=1
# This option enables or disables the writing of console output to a log file
log_to_file=0
# When log_to_file is set to 1, this is the path and filename to write console
# ouput to.
#
# NOTE: In the WIN32 version, if enabled, this should be set to a valid
# Windows/DOS path.
logfile_name=/var/bin/rq-sssp-client.log
# URL of card-server to use, formats are as follows:
#
# newcamd://<username>:<password>@<hostname>:<port>/<des_key>/[EMM]
#
# Example:
# newcamd://foo:[email protected]:12345/0 ... B371E3/EMM
#
# NOTE: The "EMM" suffix is optional and tells rq-sssp-client whether
# to send EMM's to the card-server or not. Enabling or disabling this only
# has effect if the card-server is configured to accept emms from this client.
#
# Multiple card-server url's can be specified for server fail-over.
# If the emu fails to connect or fails to get valid CW's, it will try to
# connect to other servers in a round-robin fashion.
# Up to 65 servers can be added from index 0 to 63, plus a non-indexed parameter
# named "card_server_url"
# card_server_url=newcamd://dummy:[email protected]:10000/0102030405060708091011121314/EMM
# card_server_url_0=newcamd://dummy_2:[email protected]:10000/0102030405060708091011121314/EMM
# card_server_url_1=newcamd://dummy_3:[email protected]:10000/0102030405060708091011121314/EMM
#
# This is your Card-Share Service access that was granted by Admin (below is just example only)
card_server_url=newcamd://foo:[email protected]:12345/0CE3476FF2E1C9D9A0A109B371E3
Please note that in this configuration file only two lines needed to modify: Make changes to
these two lines in green and saved it.
a. Serial port - if using Windows default port=COM1. If your PC not recognize COM1 you can change to COM2,3...etc.
b. URL of card-share server
4. Now connect your cw800 to your PC using rs232 Serial null cable. Connect one end to your PC port and the other end
to your CW800 port.
5. Turn on your PC and your CW800
5a. Enable cw800 card-sharing ecm by pressing: F1 555 (You should see that on the screen)
6. Open rq-sssp-client-1.00-binaries folder and run rq-sssp-client.exe
also rqcs mentions more than one way to share ,and a lot more intresting info herses the read me :
----------------------------- Session Negotiation ---------------------------
# Following is a set of 4 parameters that may be used to achieve successful
# session key negotiation with the card.
# ---------------------------------------------------------------------------
--
# DT08 session negotiation method. Just the Box Key is required for this
# method to work. This is the simpler, preferable method, however, not all cards
# have DT08's.
box_key=8CA6A88CFDE2E263
# DT06 Key 0D session negotiation. An alternative method for when the card does
# not have a DT08. Useful when you have the card's DT06 and not the IRD's
# Secondary Key.
#
# If this value is specified, the DT06 method will be attempted instead
# of the DT08 one.
#
# IMPORTANT: BOTH the Box Key and the DT06 are needed for this method to work.
#
# HINT: The DT06 Key 0D *does not* change when a card is swapped, if you
# have this for an old card that was married to an IRD, it will work for
# newer cards on that same IRD.
dt06_key_0d=
# Plain CAM N negotiation method. Another alternative method for when the card
# does not have a DT08. It is somewhat equivalent to the DT06 Key 0D method and
# again, useful when you have the card's CAM N obtained from an expanded
# DT06 Key 0D. As a sidenote, this parameter is equivalent to newcs's
# <rsa></rsa> parameter.
#
# IMPORTANT: BOTH the Box Key and CAM N are needed for this method to work.
cam_n=
# Secondary key session negotiation method. If your card does not have a DT08,
# and you can't extract the cam's N key or DT06 Key 0D, this is the only possible
# method. The secondary key must be extracted from a provider IRD's TSOP dump.
#
# If this value is specified, it will supercede the DT08, DT06 Key 0D and Plain
# CAM N session negotiation methods. Neither the Box Key, DT06 Key 0D nor CAM N
# parameters are needed for this method to work, and will be ignored if they
# are provided.
#
# The secondary key is 96 bytes long and has the following structure:
#
# II II II II XX XX XX XX XX XX XX XX XX XX Y1 Y1 Y1 Y1 Y1 Y1 Y1 Y1
# SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK
# SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK
# SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK
# SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK
# Y2 Y2 Y2 Y2 Y2 Y2 Y2 Y2 CS CS
#
# II = IRD serial number.
# XX = Unimportant.
# Y1, Y2 = SK signature and also used to calculate the box key.
# SK = Actual secondary key data (CAM N, public modulus).
# CS = Checksum.
#
# NOTE: The Secondary Key should be specified as a single line without spaces
# (like the Box Key), and should be the exact 96 bytes as extracted from the IRD.
#
# NOTE: You can copy the 64 bytes that are labeled 'SK' from the Secondary
# Key, and use them in the cam_n parameter. This will also work, in that case
# the Box Key parameter must also be provided.
secondary_key=
# Optional. Card provider's IRD RSA key (only relevant for DT08 session
# negotiation method.
rsa_key=
it is recommended (but not necessary) that you use the new rqcs.conf included
----------------------------- Session Negotiation ---------------------------
# Following is a set of 4 parameters that may be used to achieve successful
# session key negotiation with the card.
# ---------------------------------------------------------------------------
--
# DT08 session negotiation method. Just the Box Key is required for this
# method to work. This is the simpler, preferable method, however, not all cards
# have DT08's.
box_key=8CA6A88CFDE2E263
# DT06 Key 0D session negotiation. An alternative method for when the card does
# not have a DT08. Useful when you have the card's DT06 and not the IRD's
# Secondary Key.
#
# If this value is specified, the DT06 method will be attempted instead
# of the DT08 one.
#
# IMPORTANT: BOTH the Box Key and the DT06 are needed for this method to work.
#
# HINT: The DT06 Key 0D *does not* change when a card is swapped, if you
# have this for an old card that was married to an IRD, it will work for
# newer cards on that same IRD.
dt06_key_0d=
# Plain CAM N negotiation method. Another alternative method for when the card
# does not have a DT08. It is somewhat equivalent to the DT06 Key 0D method and
# again, useful when you have the card's CAM N obtained from an expanded
# DT06 Key 0D. As a sidenote, this parameter is equivalent to newcs's
# <rsa></rsa> parameter.
#
# IMPORTANT: BOTH the Box Key and CAM N are needed for this method to work.
cam_n=
# Secondary key session negotiation method. If your card does not have a DT08,
# and you can't extract the cam's N key or DT06 Key 0D, this is the only possible
# method. The secondary key must be extracted from a provider IRD's TSOP dump.
#
# If this value is specified, it will supercede the DT08, DT06 Key 0D and Plain
# CAM N session negotiation methods. Neither the Box Key, DT06 Key 0D nor CAM N
# parameters are needed for this method to work, and will be ignored if they
# are provided.
#
# The secondary key is 96 bytes long and has the following structure:
#
# II II II II XX XX XX XX XX XX XX XX XX XX Y1 Y1 Y1 Y1 Y1 Y1 Y1 Y1
# SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK
# SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK
# SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK
# SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK SK
# Y2 Y2 Y2 Y2 Y2 Y2 Y2 Y2 CS CS
#
# II = IRD serial number.
# XX = Unimportant.
# Y1, Y2 = SK signature and also used to calculate the box key.
# SK = Actual secondary key data (CAM N, public modulus).
# CS = Checksum.
#
# NOTE: The Secondary Key should be specified as a single line without spaces
# (like the Box Key), and should be the exact 96 bytes as extracted from the IRD.
#
# NOTE: You can copy the 64 bytes that are labeled 'SK' from the Secondary
# Key, and use them in the cam_n parameter. This will also work, in that case
# the Box Key parameter must also be provided.
secondary_key=
# Optional. Card provider's IRD RSA key (only relevant for DT08 session
# negotiation method.
rsa_key=
it is recommended (but not necessary) that you use the new rqcs.conf included
