PDA

View Full Version : blocking part of a package with CCcám?



borderfox
31-05-2010, 05:30 PM
Hi. I have a solid connect for a particular package. I use a hop2 card for an additional channel that comes with that package. However, sometimes CCcam connects me to the hop2 card for any channel on that package. The hop1 is better quality - but is a fair distance away - which means higher than normal ping but good ecm. I guess CCcám calls up the connect it finds the most responsive initially. Problem is, there are often glitching issues on the hop2.
This leads me to my question...

Is it possible to block all channels on this hop1 package with the exception of the one additional channel I want to use it for?????
If so, how do I config this?

snakie
31-05-2010, 06:00 PM
Per channel blocking no.
Per package yes.
If lets say package is 0500:012345 then you can add in the end of the C line restriction.
C: ip port user pass no { 0500:012345:1 }

This means that will use only card up to uphop 1 for that specific provider on 0500

borderfox
31-05-2010, 06:46 PM
Hi snakie. Appreciate the response. Advanced apologies for my ignornace on the subject but how do I find out what 'code' applies to each package??

Also, could this be implement from the other end ie. adding this package code ie. { 0500:012345:1 } to the F: line?? - and if so, where does it slot in? also, if implemented on this end, would this have to be reflected in changes to the c line also?

snakie
01-06-2010, 04:25 PM
lets say you use dream elite image, if you press blue button 1 time while on the channel that you decrypt you will get the info for the caid and provider.
Or if you press ok button 1 time while watching the channel maybe the skin that you use will report also the caid and provider.

As far as i know it cannot be done on the F line because you can define only the downhope reshares in the { } .Meaning that if he add lets say { 0:0:1, 0500:12345:1 } he will give you the chance to reshare to another hop that specific card if the card can be reshared, based on the incoming hops rules.

Giga
02-06-2010, 09:36 AM
you can block channel(s) in the F line:

#F: <username> <password> <uphops> <shareemus> <allowemm> ( { caid:id(:downhops), caid:id(:downhops), ... } { caid:id:sid, caid:id:sid, ... } { begintime-endtime, ... } ) hostname/ip address

#F: user1 user1 { 0100:000080:1 } { 0100:000080:15df }

15df channel id is blocked (this works). Have not tested this: but I think you can add more blocked channels to the F-line, don't know how many.

#F: user1 user1 { 0100:000080:1 } { 0100:000080:15de } { 0100:000080:15df }


have not tested this:
SMARTCARD SID ASSIGN

#example3: smartcard in device /dev/ttyUSB0 handles requests for max 5 sids, 3 of which are df3, df4, df5, remaining 2 are auto assigned
#
# SMARTCARD SID ASSIGN : /dev/ttyUSB0 5 { 0df3,0df4,0df5 }

this line should only share these 3
# SMARTCARD SID ASSIGN : /dev/ttyUSB0 3 { 0df3,0df4,0df5 }

don't know what happens with these localy?

snakie
02-06-2010, 12:24 PM
The second choice is to let your card to try to decrypt only the channels you want it to decrypt ( if ofcourse has the rights for it ).Is only to avoid ecms that are not for your card.

The first choice is to totally block channels to be received on the client side.
That means if he zaps onto a channel that is blocked he will not be able to decrypt it at all.
But his case is that he wants to decrypt the channels but if possible always with uphop1 card.So no good for him.

Giga
02-06-2010, 01:02 PM
The second choice is to let your card to try to decrypt only the channels you want it to decrypt ( if ofcourse has the rights for it ).Is only to avoid ecms that are not for your card.

The first choice is to totally block channels to be received on the client side.
That means if he zaps onto a channel that is blocked he will not be able to decrypt it at all.
But his case is that he wants to decrypt the channels but if possible always with uphop1 card.So no good for him.
yeah me bad reader, as you write c-line.