DirecTivo: Differences between 4.x and 6.2

[DocTauri]

I've noticed some differences in the way 6.2 does certain things over 4.x. I want to make sure it's not just me, and see if anyone may know of a correction or workaround for these. I'd also be curious to know if someone who doesn't have backdoors on sees the same thing.

So far, here's what I've noticed:

* No network settings GUI (Fix: use netconfig.tcl)
* MRV name not displayed on transfer screen (Fix: Unknown)
* Scheduled MRV's not in To Do list (Fix: Unknown)

Thanks,
Doc

[AlphaWolf]

6.2 does all of these things the same way that 4.x does (no scripts necessary either,) just the current *public* superpatch doesn't enable it all. There wont really be a fix until somebody takes the time to patch each individual part of the spigot that is necessary to enable only whats necessary for HMO/MRV without enabling some bad things (e.g. more of the trial nags.)

[DocTauri]

Really! Well that makes me feel better then. While we're on it, way back when we first realized the MRV stuff was in 6.2, everyone (powers that be, like yourself) said a 6.2 superpatch wouldn't come out, due to potential 7.1 hacking issues. Then all of a sudden, it appeared. What changed to cause this policy reversal?

Thanks,
Doc

[AlphaWolf]

Well, actually there are two superpatches that exist. Theres the public one that nutkase is distributing which unlocks the spigot about halfway, and some useful but unessential parts are missing. Then theres an underground version which completely 3M's the spigot. This is both good and bad even if your intent is just to steal service, because there are some things in the spigot that you really don't want enabled. It is also a patch that would be pretty easy for somebody to port to a standalone tivo. Even if nobody did use it to steal service, this still isn't a good patch to release to the public.

I always knew and even stated that there would be a public HMO/MRV patch available, but I also knew that it would take time to develop since a different approach at opening up the spigot would have to be found and taken advantage of. The current solution works well in that it doesn't force open any of the service auth portions of the spigot, but isn't quite what I was thinking would actually be released, or at least what may be released eventually if somebody actually wants to go through the work of finding each individual spigot function and only patching the portions that we want/need (thus we don't see the trial nags at all, and all configs, scheduling, etc are enabled.)

I tried digging around it myself now and then just as an excersize to learning assembly, but its tough. If you ever see such a patch, it probably wont come from a pissant like me. It would have to come from a guru who has absolutely nothing else to do for a week.

[imaloserbaby]

I read or perhaps mis-read something relating to a 4.x upgrade to 6.2 using slices, and wondered if anyone can clarify.

It implied that if you upgrade from 4.x to 6.2 then you will keep the Network Settings / Wireless Settings menu? But I would assume this is not the case? I.e. the menu is "hidden" in 6.2 and would need a patch to make it visible again? So the only reason to slice upgrade from 4.x is so that you can set everything up first, including wireless encrpytion settings and so on, then a 6.2 upgrade would perhaps keep those settings?

Sorry if this was already answered, I did search for quite a while and didn't see a completely clear answer.

[DocTauri]

Yes, when you configure networking in 4.x and upgrade to 6.2, the settings carry over, but that can be overcome in 6.2 by running netconfig.tcl. The other (and more important) reason to slice upgrade would be to keep your existing records, settings etc. (provided it was previously hacked as well).

Doc

[imaloserbaby]

Good point on the recordings yes, I'll look for that network.tcl script also since I tried just standard boot (with hacks) and get nothing for wlan0 under ifconfig (since it's a clean 6.2 image). I could only get the clean image from edonkey for now, but will try the slices when I can download them. What I did to preserve my recordings was to mfsrestore into a virtual machine, then I dd'd off /dev/hda4 as a root.gz file and then restored that to another drive, seemed to work, but of course no config settings as stated.

Sounds like netconfig.tcl should get me there, dhcpclient as is doesn't of course as you need to say "hey, by all means connect to my unsecured wireless named xxxxxx". Will give the script a try, thanks.

[DocTauri]

I haven't messed w/the wireless lan, but if I remember right, loading Jamie's backported drivers into 6.2 will give you the wireless stuff.

Doc

[imaloserbaby]

I haven't messed w/the wireless lan, but if I remember right, loading Jamie's backported drivers into 6.2 will give you the wireless stuff.

Doc


The problem was actually that the netconfig.tcl script was missing a setting to say, "wireless" instead of "wired". I forget the flag, but I posted an update in the creator(s) thread. I will try the backports next, I applied the backports to 4.x so it should just be a case of using the 2.4.20 files... hoping no issues there.