Jerrold TalkBack System
MrBMcG
Hi
Anyone interested in exchanging info about the Jerrold Talkback system?
For example, which packets do what?
To show I know a little about it, the following packet
0x07 0xFD 0x10 Box Address
will make the unit transmit back its serial number.
Anyone else in the know about talkback?
Bye
magicboxes
Yes, programmble traps in our testers kill those bad replies until the
customer feels its appropriate to test.
Our units don't change the dynamic address so clearly the below command
would prove useless.
As for "state of box" thats another story... In the ultra MVT(has fm data
receiver) we can change the state BACK when those command are transmitted
and then revert info when the cft 2200 (about 9 seconds later) has returned
happy data :)
As for the Multi-Mode-MVT we use a programmable trap.
As for talk back in general.. Its pretty useless... Its easy to mod data
below 10Mhz.
--
Manufacturing and R&D in cable television descrambler technology
Jim
http://www.magicboxes.com
magic...@magicboxes.com
MrBMcG <mrb...@aol.com> wrote in article
<19980129232...@ladder02.news.aol.com>...
MrBMcG
>Yes, programmble traps in our testers kill those bad replies until the
>customer feels its appropriate to test.
Why would you kill the replies when the box is in it's normal state i.e not
testing? Surely this only draws attention to your box because it is not
responding to being polled.
>Our units don't change the dynamic address so clearly the below command
>would prove useless.
What difference does that make? My cable co randomly scan all boxes for a
response, and randomly scan boxes for channel authorisation, using FD 18 ,so
the problem in this case is that your box address is NOT changed, if you send
back wrong authorisation information on your own address you are busted!
>As for "state of box" thats another story... In the ultra MVT(has fm data
>receiver) we can change the state BACK when those command are transmitted
>and then revert info when the cft 2200 (about 9 seconds later) has returned
>happy data :)
My cable co. send about twenty-five packets consecutively, when they randomly
interrogate a box ,with only 5 0xFF's in between and expect a response to each.
Each command transmits back immediately. If you buffer these commands,
de-authorise the box, and wait 9 seconds before transmitting, chances are the
headend software will have asked another box on the system to talkback in the
meantime, and your data could clash, causing either or both boxes not to return
a sensible result, again drawing attention to yourself.
Also, for you setup to work, you must know the correct channel authorisations
for that person's channel lineup, as a wrong de-authorisation is just as
conspicuous as a wrong authorisation to the head-end software. Do you monitor
what the boxes channel line up is during normal operation?
>As for the Multi-Mode-MVT we use a programmable trap.
Can you elaborate on what this is?
>As for talk back in general.. Its pretty useless... Its easy to mod data
>below 10Mhz.
What do you mean mod data? Send back garbage up the line to screw their system,
or have a talkback transmitter on the cube to send back "happy" data?
As for being useless, You may be right, but I could never sell anyone a cube in
the knowledge that they even might be busted, and two-way systems can get
people busted. It's true that it is difficult for cable co's to get two-way to
work, mostly because some joker selling cubes, plants a dummy transmitter to
blast garbage up the line, but when they are operational it's a pretty
dangerous time for your average cube owner, who is oblivious to what is going
on.
And if it's so useless, why do you go on about your stuff being Bandit software
aware, and Two-way aware if you think it's so rubbish?
mrbcg
magicboxes
I, myself, personally, am on a 2-way Starvue system and have SUCESSFULLY
watched and LOGGED 2-way requests. Our MVT tester line happily deals with
such and I haven't had ANY INCIDENT AT ALL. We have had a two way CFT
system online for over 1.5 years and everything is working fine.
Now, here is how we deal with 2-way:
First... some basic known information about 2-way:
1) CFT22XX models are SLOW.. They can take up to 9 seconds to process a
talkback depending on what they are doing.
2) Talk back is on 8-10Mhz
#1 ) How ALL other cubes deal with 2-way?
They don't. None of them. Most change you DSN so your box can't even TALK!
As for the rest RFT-DAM, non 22xxx
they just allow the cable company to poll information in the box every 5
seconds. BAD. The cable company gets
the state of the sunscriber box in NO TIME.. Ie: PPV being *tested* by T2,
etc = BUSTED!
#2) How we dealt with it in the Multi-Mode-MVT:
#1) Use a 2-hour timed programmable trap - the unit allows 2-way all
night, during the daytime when the SET-TOP
is not being used in a *tested* state.
#2) From our tests, If our unit disallows a talkback to happen it will
generally be allowed a short time later. The
cable company has to deal with boxes being unplugged, power outs,
glitches, etc. Our box allows polling
most of the time AND CLEARLY PUTS THE SET-TOP BACK IN ITS ORIGINAL
CONDITION PRIOR
to a query!
#3) How we dealt with it in the Ultra-MVT
#1) This unit has a FULL FM data receiver/transmitter. Because ALL of our
testers KNOW the DSN in the
set-top by FINDING IT, NOT changing it .. we can CHANGE the state of the
box back to its original
condition, send the command a sec later, then change the set-top BACK
into tested mode.
Don't forget. The CABLE COMPANY HAS A SERIOUS AMOUNT OF TRAFFIC WHEN IT
COMES TO AUTHORIZING BOXES/DE_AUTHORIZING, AUTHORIZING CHANNELS, MULTI-MODE
UPDATES, TIME/DATE, CHANNEL DATA, PROGRAM DATA. The cable company has VERY
LITTLE bandwidth to spend polling boxes. And if your in a system with
40,000-50,000 units it would take a LONG TIME TO POLL THEM ALL. Plus: They
can't JUST BLANKETLY ASK FOR 50,000 boxes for a response. The headend
software doesn't allow for it and clearly neither does the headend
software.
As for Starphone units (phone line attached to box) They can only poll it
once and awhile (once a month, etc..). AS A SUBSCRIBER I AM SURE I WOULD BE
PISSED OFF IF THE CABLE COMPANY HAD MY PHONE LINE DIALING OUT EVERY HOUR
ASKING WHAT I WAS WATCHING!
get real!
We have dealt with this problem seriously. Were the only company that has
ever even CONSIDERED selling a product which protects the end-user against
POLLING.
I have one other point:
"WHAT RIGHT DOES THE CABLE COMPANY HAVE POLLING MY BOX AND MY VIEWING
HABITS ANYWAY!"
REST ASSURED WE ARE BRINGING THIS ISSUE TO THE GOVERNMENT. Its an intrusion
on privacy. Pure and simple.
I address your issues below:
--
Manufacturing and R&D in cable television descrambler technology
Jim
http://www.magicboxes.com
magic...@magicboxes.com
MrBMcG <mrb...@aol.com> wrote in article
<19980205234...@ladder02.news.aol.com>...
> >Yes, programmble traps in our testers kill those bad replies until the
> >customer feels its appropriate to test.
>
> Why would you kill the replies when the box is in it's normal state i.e
not
> testing? Surely this only draws attention to your box because it is not
> responding to being polled.
WE DON'T. We kill replies when the damb head-end unit is asking for a reply
when our customer is happily testing a channel.
>
> >Our units don't change the dynamic address so clearly the below command
> >would prove useless.
>
> What difference does that make? My cable co randomly scan all boxes for a
> response, and randomly scan boxes for channel authorisation, using FD 18
,so
> the problem in this case is that your box address is NOT changed, if you
send
> back wrong authorisation information on your own address you are busted!
All testers but ours CHANGES THE DSN in the set-top. If their DSN is
changed the CABLE COMPANY CAN NEVER POLL THAT BOX... BAD NEWS... You make
it sound like the cable company is polling 255,000 boxes per hour??!!??? It
would take 3.2 hours MINIMUM to poll 255,000 once, (SENDING NO OTHER DATA-
IMPOSSIBLE), clearly thats not being done. They are polling for PURCHASING
in most cases... NOT polling a DSN which does not exist to see if anythings
out there.
I'll save you the time and effort:
POLL: 224 191 127 62. You'll get every customer with a
T2A/RFT-PLUS/BRICKMM2200/TESTBENCH 2200/FANTOM 2200.
Enjoy... Why waste your time polling other addresses???
SECOND... the headend box spends ALOT of its time 248ing (shutting down)
any DSN WHICH IS NOT THEIRS.
WHY POLL IT WHEN THEY CAN KILL IT???
>
>
> >As for "state of box" thats another story... In the ultra MVT(has fm
data
> >receiver) we can change the state BACK when those command are
transmitted
> >and then revert info when the cft 2200 (about 9 seconds later) has
returned
> >happy data :)
>
> My cable co. send about twenty-five packets consecutively, when they
randomly
> interrogate a box ,with only 5 0xFF's in between and expect a response to
each.
> Each command transmits back immediately. If you buffer these commands,
> de-authorise the box, and wait 9 seconds before transmitting, chances are
the
> headend software will have asked another box on the system to talkback in
the
> meantime, and your data could clash, causing either or both boxes not to
return
> a sensible result, again drawing attention to yourself.
Bullshit. CFT22XX boxes are by far the slowest computing pieces of crap I
have ever seen. My GOD - It takes the fricking box 9 seconds to REGISTER a
TIME CHANGE COMMAND!!!
(12 253 96 <Time> <Site Code>)
And further, DON'T FORGET ABOUT THOSE HUGH PACKETS BEING SENT TO UPDATE
CHANNEL DATA (PROGRAM INFORMATION EVERY HALF HOUR).
Only 6 of those can get sent every SECOND! (200 bytes/packet!)
>
> Also, for you setup to work, you must know the correct channel
authorisations
> for that person's channel lineup, as a wrong de-authorisation is just as
> conspicuous as a wrong authorisation to the head-end software. Do you
monitor
> what the boxes channel line up is during normal operation?
>
> >As for the Multi-Mode-MVT we use a programmable trap.
> Can you elaborate on what this is?
Yes, a trap which kills the 8-10Mhz (depending on config) data to be sent..
VERY TEMPORARY. The Ultra-MVT holds the command for a few milliseconds
WHILE it restores the boxes ORIGINAL CONDITION.
>
> >As for talk back in general.. Its pretty useless... Its easy to mod data
> >below 10Mhz.
>
> What do you mean mod data? Send back garbage up the line to screw their
system,
> or have a talkback transmitter on the cube to send back "happy" data?
I mean OUR NEXT GENERATION cubes WILL transmit BACK to the cable company
the information they are expecting to hear. I was telling some folks
earlier that that would cost alot more but we just got one running
yesterday for CHEAP $$$. Cool!
>
> As for being useless, You may be right, but I could never sell anyone a
cube in
> the knowledge that they even might be busted, and two-way systems can get
> people busted. It's true that it is difficult for cable co's to get
two-way to
> work, mostly because some joker selling cubes, plants a dummy transmitter
to
> blast garbage up the line, but when they are operational it's a pretty
> dangerous time for your average cube owner, who is oblivious to what is
going
> on.
>
> And if it's so useless, why do you go on about your stuff being Bandit
software
> aware, and Two-way aware if you think it's so rubbish?
We don't think its rubbish. 2-way systems DO get people busted when their
using T2s/RFT knockoffs. Its common knowledge.
Ive got another note for you.
MANY CABLE COMPANIES ARE ALREADY GETTING IN SHIT FOR BILLING CUSTOMERS FOR
EVENTS THEY DID NOT ORDER DUE TO TWO-WAY COMMUNICATIONS. I'll tell ya, if
the two-way is too much of a hastle do you REALLY think they will continue
to use it????