Possible Fix - DTivo dial-home with 6.2 SuperPatch Applied

[LanMan]

When superpatch-67all was introduced, (Thanks NutKase), I applied it to both of my Hughes systems. They are running 6.2-01-2-351. Before I implemented cron with FakeCall40.tcl both units had phoned home.

In this post and others members talk about the problems of this and the addition of certificates for the HMO/MRV features, with a six-month deadline.

On my systems the phone-home added 2 entries in MFS:
/State/Keyring/SP_4-production-5-12929-180-A-13109-A-13109-A
/State/Keyring/SP_5-production-2-12929-180-A-13109-A-13109-A

On the System Info screen it indeed added certificates with a 6 month expiration.

To get rid of these I just Rubbished / Nuked them out of MFS. My two systems are working great and HMO/MRV have no problems.

Any (right, wrong, dumb idea) comments or discussion about this would be appreciated.

Thanks,

Eric

[BigYellowDog]

What does the system info screen now say? I made the same mistake. What would be nice, is a hack to set the days to 0 instead of 180....assuming this would work. We might need to change the start date as well.

[BigYellowDog]

I did some testing, and I don't believe the certificates are that big a deal. I nuked the object ids and they went a way. I forced another call to the mothership (ok, maybe I shouldn't have, but I wanted to test) and the certificates appeared again. The 180 day expiration reset. Also, the certificates seem to control two added servers to the "Music and Photos". The first being Best Buy New Music and the second being Legends. When the certificates are deleted, these servers are removed. After the call to the mothership, the servers were added back. I assume, but can't validate, that when the expiration time comes, these two servers will simply disappear. Will they be replaced by other servers? I don't know. Will HMO be completely disabled at that time? I don't know. As long as you delete the certificates before the expiration date, I'm guessing you will be OK.

[LanMan]

After I Nuked the two certificates in mfs under /State/Keyring everything
on the System Info screen was back the way it was before the call.

Music and Photos have always been the same, reguardless of the call.

I think the 2 Certificates obtained during the call actually effected my MRV
between two systems. Before I got rid of them, the units would have to be
"named" every 2 to 3 days to communicate. The units would show up in
Now Playing, but as the service number. After I ran the naming script, they
would be back for a few days.

Since Nuking the Certificates all as been well, going on 2 weeks without
any problems.

Eric

[BigYellowDog]

Sounds great. I figured out why my other servers disappeared...it was related to a bad backup and restore that I was doing in combination with your recommended fix and the fix is quite easy. The good thing is, that if you happen to accidently call home again, it will give you another full 180 days to nuke the objects.

[macinator]

LanMan - Your previous post seem to describe my situation exactly. I let the 6.2 upgrade via slice to call in once before loading Fakecall on both Tivo's. In my /state/keyring I have certitifcates dated from the date I upgraded. My MRV works fine but it drops every 1-3 days and I need to rerun setmrv. I have set it up as a cron job but would like to fix the problem.

Can you tell me how to "rubbish" the certs from /state/keyring as you detailed? I have looked at modifying some of the tcl scripts but frankly I am no programmer and fear I would simply muck something up.

Thanks,

Macinator

[LanMan]

macinator

Not knowing anything about mfs let alone how to write a .tcl script I
modified set_mrv_name_67.tcl, line 39 to include SP_4|SP_5 .

Worked in my case. That way, anytime I name the unit it wacks the
unwanted certs.

Eric

[macinator]

Thanks a bunch LanMan for your mod to NutKase's setmrv script - that did the job. Hopefully it will be the long term answer for my Tivo's as well.

I have the following two items still in the keyring area - they do not appear on my other Tivo. Only differences in the units - one is RCA the other is Hughes - the other is I did the upgrade to 6.2 via slices from slightly different builds of 4.x. The data would indicate these are sitting here from the earlier 4.x install. Not sure if they should be there - they do not seem to be causing a problem though .

6049Ant-199806 tyDb 653976 04/04/05 20:43 112
IL12488-199806 tyDb 653975 04/04/05 20:43 112

Thanks,

Macinator

[bluemodena]

I found RubbishObjectByFsId commannd in tivosh. Works like a champ. ... if you want to manually do it. But, it looks like the same thing can be done by running setmrvname script again.

[BigYellowDog]

I do really like the set_mrv_name_67.tcl change. Any chance this might whack more than we want?

[LanMan]

BigYellowDog

Only what you tell it on line 39...........

One other note. As described many many times, I put a route in my rc.sysinit.author so that my devices don't phone home over my dsl connection.

route add -net 204.176.49.0 netmask 255.255.255.0 reject

Eric

[BigYellowDog]

Lanman,

I figured that. I just wasn't sure if anything else would pop up in the tree beginning with the same few letters.

Attached is a tcl I wrote to delete a specific mfs object id.

I take no responsibility if you are forced to rebuild your tivo after using it however.

This is my first tcl program and I cut and paste code from others and tweaked from there, so it might not be the best written script.


Edit: I guess the script is worthless since it does the same thing as RubbishObjectByFsId, but it was a good exercise nonetheless.

[Homer S]

Originally Posted by BigYellowDog

Lanman,

I figured that. I just wasn't sure if anything else would pop up in the tree beginning with the same few letters.

Attached is a tcl I wrote to delete a specific mfs object id.

I take no responsibility if you are forced to rebuild your tivo after using it however.

This is my first tcl program and I cut and paste code from others and tweaked from there, so it might not be the best written script.


Edit: I guess the script is worthless since it does the same thing as RubbishObjectByFsId, but it was a good exercise nonetheless.

The script worked for me. I had some trouble getting fixsub configured to run automagically. Once I got that working, I blocked the two local IP addresses via my hardware firewall and did phonereset.tcl to prevent any accidental call completion.

The script above has one typo in the error text to include an object id. I applied the fix to both DTivo's, verified via System Information that the 180 expire was gone. Rebooted and after boot, verified that the expire was still gone.

Hopefully all will be well!

Homer Out

[dong941]

Originally Posted by LanMan

macinator

Not knowing anything about mfs let alone how to write a .tcl script I
modified set_mrv_name_67.tcl, line 39 to include SP_4|SP_5 .

Worked in my case. That way, anytime I name the unit it wacks the
unwanted certs.

Eric

Should I write it like this:

if { [regexp {^(NAMETABLE|TIVOVID|MRV)} $name] } { SP_4|SP_5

[LanMan]

dong941

This would do the trick. NAMETABLE|SP_4|SP_5|TIVOVID|MRV

Eric