Can't get Tivo to respond to telnet or ftp

[bis]

I am trying to enable telnet and ftp on my Tivo, and AFAIK I've done everything I need to do, but it's not responding.

I have a Tivo-branded Series 2 DVR (the 60 GB version, but I've upgraded to 120), running kernel version 7.2.2b-oth-01-2-140.

Using the PTVupgrade CD, I've modified the kernel, and have verified that my changes to files in /etc/rc.d are not being removed. I added the following lines to rc.sysint.author (yes, I did make this file executable with "chmod 755"), and when that didn't work, I added them directly to the bottom of rc.sysinit (right before the last line that echos a message indicating that rc.sysinit is complete):

tnlited 23 /bin/bash -login &
/var/hack/tivoftpd.mips

(Yes, tivoftpd.mips is in /var/hack and is executable).

Next, I tried adding "/sbin/" before tnlited, and I added the following line to disable the firewall:

[ -x /etc/netfilter-disable ] && /etc/netfilter-disable

I still can't telnet or ftp to the Tivo. It responds to ping, and it boots up and runs fine, but when I try to telnet I get "Could not open connection to host...", and when I try to ftp I get "ftp: connect :Unknown error number.

Does anyone have any ideas?

[Note: I'm following instructions in a guide called "How to hack your Tivo Series 2 (AT&T/Tivo/Comcast model) w/HMO to stream content to your computer". I tried to provide the URL but apparently I'm not allowed to, but if you google for "How to hack your Tivo Series 2" it will be the first hit.]

[arctanstevo]

What is the model #? Some series 2 are not hackable in that manner, some are. Do a search for a list of hackable tivo's.

When you hooked the drive back up to your PC, were your changes to enable telnet still there?

I'm not familiar with the command you used to disable the firewall, I just remember renaming it oh so long ago.

[MungoJerrie]

I believe newer sw versions require you to change iptables as opposed to just renaming netfilter. Try this:

cd to /sbin on mounted "root" partition
mv iptables iptables.old
echo -e '#!/bin/bash\nexit 0' > iptables
chmod 755 iptables

That ought to do the trick!

[bis]

When I put the drive back in the PC, I can see that all my previous changes have been left intact, ever since I replaced the kernel with the hacked version from the PTVupgrade CD.

The model # is TCD140060. It's not a new model, I've had it for 4 years. Are you saying that some Series 2 are completely unhackable, even with killhdinitrd, and there's no way to get around it?? I haven't seen any mention that some Tivos are unhackable in any of the guides I've looked at, and I haven't been able to find any sort of list of which models are hackable, do you have any idea where I might find one?

The command I used to disable the firewall was copied verbatim from the guide I mentioned, I really don't know what it's supposed to do. Maybe it doesn't work. You say that you renamed the firewall, maybe I should try that. Do you know what filename I should look for?

[bis]

I tried what MungoJerrie suggested, but the Tivo didn't like that at all. It went into an infinite reboot cycle, crashing each time a few seconds after reaching the "Almost there. Just a few minutes more..." message. I had to change everything back.

I'm not sure what echo -e is supposed to do, but it doesn't appear to be supported by the PTVupgrade CD. I'm assuming that it's to enable metacharacters, so I created a file called iptables with the following contents and made it executable:

#!/bin/bash
exit 0

BTW, the original iptables is a 140k binary file, can it really be replaced with a two-line text file? When I put the drive back in my PC to change it back, I noticed that the new iptables file also turned into a binary, albeit a very small one (19b).

The really bizarre thing is that when I tried to change things back, my changes wouldn't stick. I had no problem making the change in the first place - renaming iptables to iptables.old and creating a new iptables. However, when I renamed my new iptables to iptables.hack and renamed iptables.old back to iptables, the Tivo still went into the infinite reboot loop. When I put the drive back in the PC, I saw that everything had reverted to the way it was after my first set of changes - I had a 19 byte file called iptables with today's timestamp, a 140k file called iptables.old with the original file's timestamp, and no iptables.hack! I watched this happen twice. Then, I tried delete the 19b iptables and rename iptables.old to iptables, but I still had the infinite reboot cycle, and when I put the drive back in the PC this time, I saw that it had again been renamed back to iptables.old, but this time there was no iptables file at all - just the iptables.old, which was the original iptables file, which I verified was named iptables the last time I had shut down the PC. N.B.: each time I booted the Tivo, it didn't revert back to the *original* configuration, it kept reverting back to my first set of changes!

I was finally able to resolve this issue by renaming iptables.old to iptables, then creating an empty file called iptables.old. Now the Tivo boots, so apparently this prevented the reversion that was happening each time.

What exactly is this iptables file, and why did you suggest replacing it with a shell script that exits immediately?

[MungoJerrie]

Iptables is the linux firewall; by replacing the existing binary with a script that "returns 0" you effectively bypass the firewall. Renaming netfilter is also another way. The "exit 0" works for me on my "240" series tivo. See this (http://www.tivocommunity.com/tivo-vb/showthread.php?t=289174) thread on the approach by another using a sleep command in the rc.sysinit.author file. Also, it might help if you had a serial cable and could attach the console log...

[bis]

Console access would be great, I didn't realize it was possible. I have a couple of serial cables, but there is no standard RS232 port on the back of the Tivo. There is a port labeled "serial" that looks like an audio jack, right above the IR port where the transmitters that control the cable box are plugged in. It's been years since I read the setup manual, but I thought this was an interface to control different kinds of receivers (satellite?). Is it really possible to get console access through this? What kind of cable would I need, I've never seen this kind of serial cable before.

I'll also give the sleep method a shot, thank you.

[MungoJerrie]

See here (http://www.tivocommunity.com/tivo-vb/showthread.php?p=3972671#post3972671) and here (http://www.garysargent.co.uk/tivo/images/tivoserialcable.jpg) for info on serial cable console access.

The other thing you could do is mount the 9th partition (/var) while the drive is in your pc and take a look at the kernel log - /mnt/log/kernel (edit path to reflect your actual mount point)

[bis]

That did the trick! Well, sort of. I added a "sleep 60" before the line that disables the firewall, and I can now telnet in, but ftp doesn't work, and the shell I'm getting doesn't recognize a lot of basic commands. The prompt is "bash-2.02#", but I get "command not found" errors when I try to use ls, ps, and vi. On the other hand, cd, pwd, and df all work. So, what the hell kind of Linux shell is this??? It's kind of difficult to navigate the filesystem or make any changes when you can't do a simple directory listing or use a text editor! Or is that the idea?

Also, df -h tells me that I have two filesystems, /dev/hda7 mounted on /, and /dev/hda9 mounted on /var, that each have a size of 124M. This is a 120 GB disk...where is the rest? I can't try mounting other partitions by trial and error because if I try to create a subdirectory of /mnt, I get an error saying "Read-only file system".

[MungoJerrie]

The reason why ls,ps,vi don't work is that they are not included in the standard tivo (linux) distro. You have to install them separately and then add the directory (or put them in /bin) to your PATH statement by editing your rc.sysinit.author file. The root (/) filesystem (in your case /dev/hda7) is always mounted read-only. All the rest of your 120GB disk (more or less) is allocated to MFS (Media File System) partitions which are not readable from bash, only through specialized tools. If you ever did want to make changes to your root filesystem (like editing rc.sysinit.author in /etc/rc.d) you would do the following:

mount -o remount,rw /

This will remount root as read-write; be sure to change it back though, it's not a good idea to leave root mounted read-write. To change it back:

mount -o remount,ro /

Hope it helps...happy hacking!

[bis]

Wow, it looks like this is going to be a much bigger project than I expected, I'll have to find some time for it later. At least I've now gotten over the main hurdle. Thanks for all your help!