SamyGO

I see theres hope for the T-NT14 tv's.... right on. mine is the T-NT14MAKUC-1112.1 I have OTN & OTA support turned off from date of purchase. I followed the directions as specified, i setup the usb drive to fat32 and have the installsamygo icon on the tv, but its still the same problem when i try to install samygo. below is the screenshot of the error. also, im connected via ethernet cable, i set the schedule on feature, then powered off tv and waited for it to power back on. when i run nmap after doing all that it shows these open ports... 4443/tcp:pharos, 6001/tcp:X11:1, 7676/tcp:unknown, 8080/tcp:http-proxy, 8443/tcp: https-alt. if any of that info helps, good.

Man Why do you Post that here ? I dont think your tv is h Series or rootable

The "DNS proxy" way is also used to block Wii U Updates.
The TV has of course nothing to do with a Wii U but the technique (as already discussed) will work, if every user who is interested in rooting will do the same for the TV.

I personally find this solution not really comfortable (I rather use the block feature in the router than a custom DNS) but it works if there is no other way.

PS: I read that there are some problems because the "time trial" was over. But that shouldn't be an issue. What doo you think about the "DNS proxy" solution sectroyer?

I think that good that I blocked OTN Support on my TV ASAP

I too have made these changes in my router's DNS. I'm currently on 2602.2 (on a H6400) - from reading other posts it seems it's not rootable yet...

Let's summarize sectroyer's concerns (hope I got them straight):

1. If the TV is rooted, but OTN support is still on, the TV will update when it gets the chance, it will loose root access and possibly "phone back" to Samsung HQ and report on the rooting method attempted (let's assume we're paranoid about this)

Question - in this case can the root package check if OTN is on (by reading some part of the flash where such a flag would be stored) and if it is, simply refuse to attempt root?
Or, if OTN can't be turned off, do some checks via the default DNS server to see if the update domains resolve to 127.0.0.1 or not. If they don't, refuse to root (and log an appropriate message somewhere). Such a check can/should be performed at each startup (though, one may argue that the DNS configuration may change on each network up/down and the update might come at some considerable time after startup)...

2. If the TV is not rooted you can't run any checks automatically, but - maybe you can develop an app in the store that does the DNS checks and you instruct the user to run it as a prerequisite. If it fails don't attempt to root.

3. If the TV is not rooted but DNS checks pass, go ahead with the root...

Here's an idea regarding the DNS proxy:
In principle it would be easy to use by the end user, however, it would introduce delays in DNS response times for the TV because it would have to resolve everything (web browser, youtube, etc). Also, it will probably cause streaming issues where content providers (like youtube) have geographical caches that get accessed via DNS - for example:

DNS query to youtube.com to 8.8.8.8: DNS query to youtube.com to my ISP DNS: Getting a non-local server will impact your streaming performance.

However, I think I have a way around it:
1. Set up a public DNS that bans the domains used for update and resolve all other queries
2. Have the user configure that DNS manually and set up the rooting scripts (if possible) to check if the domains are "correctly" resolved
3. After root, override /etc/hosts. Even if it's on a read-only medium, it can be overridden by doing The changes should be instantaneous and system-wide. (It's read by the system dns resolver which opens it each time it has to resolve anything. This means we don't need to restart any processes that need resolving).
4. In the new hosts set the update domains to 127.0.0.1
5. Reset the manual DNS server back to DHCP (or ask the user to input their home gateway as DNS).

This way you only use the public DNS only on rooting, and take care of business internally afterwards.

I'm not sure if what I'm proposing is feasible on this platform (I am a noob afterall), but it may be a way to do things...

The hosts file needs to be overridden each boot of the TV.
But root only applies after the update-check.
This means that any hosts modification/override is useless because the initial purpose fails. (Well, if the TV looks for updates after root it may be useful.)

Afaik the DNS delay isn't a big issue simply because the DNS is cached in the system (TV) after it has been queried once. So only the initial DNS query may be delayed but that is not a big deal. But I didn't know about the geographical caches, this is somewhat important.

I think the "check OTN-support" part is pretty good.

Hmm, good point about the order of checks.

How about this, then...

1. Have the user set the desired "good" DNS server
2. On startup, after root, replace /etc/resolv.conf with the user's home gateway (located in a static text file or use the default gateway if blank). Do not change the DNS in the TV's settings, just the one used by the system - this should solve geographical caches at runtime. If /etc/resolv.conf is not writable, mount -o bind on top of it. If the system insists on rewriting it periodically (on network/up/down), set it read-only/immutable (if the filesystem allows it).
3. On next reboot/power outage go back to 2.

Just one info any ON-TV solution won't work. That's because OTN shit start BEFORE ANY ROOTING We CAN'T start anything before OTN

The proposed solution is a workaround -

1. Use an external DNS server to fool OTN - this is user configured and should work on boot, before root
2. After root, change temporarly back to LAN DNS and keep using it for best performance, until next reboot (via startup script).
3. Profit?

Why all the Stress Block the URLs in the Router and you dont have to worry about otn anymore