Hurrah - away with OrenoSP!

Advertisements

Many thanks. But, I've still got the same error as before. I've created a /var/hack/lib and but the library in there and changed the permissions. I've also put a copy in /var/hack/bin and done the same but still the same error message.

What have I missed? Are there any paths or links that I need to set for /var/hack/lib, or anything like that?

Thanks.

 

If this is the first library that you've added into /var/hack/lib then you'll need to add
"export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/var/hack/lib" (without the quotes) to
your .profile (which might be in /var/hack/.profile or might be in /.profile)

 

Thanks for that; another step forward.

Ok, Dropbear now running but unable to connect using PuTTY. Looking at the PuTTY log, it just seems to hang after "Connecting to a.b.c.d port 80". The PuTTY session window also appears to just hang.

Lo is Up on TiVo.

Any ideas? Thanks again.

Edit: Up and running now. It helps if you connect to the right port i.e. 22!

 

Got everything running perfectly with one exception. I can't get dropbear to start from rc.sysinit.author; I've tried most combinations of full paths in the shell script, .author and such like. The commands all work perfectly from a BASH prompt but reboot TiVo and everything but dropbear is started.

Any ideas/tips? Thanks again.

 

Advertisements

You'll probably need to add the /var/hack/lib to your library path within the script, the
.profile is only called for login sessions. Try adding the LIBPATH statement above (the one
you added to your .profile) to the script before the dropbear invocation.

 

Flippin' 'eck, you're clever I didn't think of that one! All working perfectly now. Thanks for all your help.

All I've got to get working now is the IP detection bit in Dailymail_jazz and I can keep the PC switched off; I don't have a static IP and my router doesn't support DynDNS updating and so I have to use DirectUpdate running on the PC).

One final question: Is there any way (or any point) in changing the SSH port number, perhaps to a higher, less likely to be probed number?

Thanks again.

 

I don't use DynDNS any more as I have a static subnet coming into the house pipe, but
for a while I used this script to update a DynDNS account from a Linux box.

I haven't tried it on a TiVo, but in theory if you grab that, change the path of the shell, and
install the wget TiVo binary and OzTivo resolver library then you should be able to cron-enable the script and have it update your DynDNS account directly from the TiVo.

It wouldn't hurt to have it listening on a much higher port, I would also suggest
only opening up firewall access to it from known/trusted IP addresses and/or
subnets and not having it world-open.

 

Excellent stuff. I've now got TiVo detecting my WAN IP address and updating my DynDNS account PC can now formally be switched off!

One final question: I'm happy about changing the listening port on the non-TiVo/remote end of the tunnel. Is there any way though of changing the port that the SSH tunnel establishes with, or is it fixed at 22?

Many thanks again for all your help with this. My electric bill should be getting smaller from now!

 

No probs, glad I've helped the ozone layer a little

You can change the port which dropbear listens on by adding a -p <port> to its invocation
command. Or, rather than forward port 22 on your router to port 22 on the Tivo then if your
router allows it remap a higher port on the router's outside edge to port 22 on the TiVo.

You can also change the listening port for the tunnel (ie the port on your client machine
that you browse via) via the SSH command. E.g. if you have dropbear accessed via port 22
(the default) then you can do
ssh -l tivo -L8080:127.0.0.1:80
to set up the client end of the tunnel to listen on localhost:8080
or
ssh -l tivo -L1234:127.0.0.1:80
to make it listen on port 1234, i.e. change the first parameter on the -L command. If you
are using e.g. PuTTY then just change the "source port" parameter on the tunnel definition.

If you do change the dropbear access port to something other than 22 then for
command line ssh clients add "-p <port>", e.g.
ssh -l tivo -p <dropbears_port> -L<localhost_port>:127.0.0.1:80
when you set the tunnel up.

Again though, I would definately suggest that you restrict the IP addresses which can
access your dropbear port so that only known trusted IP addresses can access it.

 

Next job, see if anyone can get HTTPS forwarding running on a WRT54G/GS to enable you to securely connect to TiVoWeb.

As an aside I am now running DD-WRT V23-beta 2 on my WRT54GS acting as a wireless bridge to a Netgear DG834G, with more than one device attached (unlike Satori and Alchemy) and using WPA wireless encryption. Works fine.

 

Well, it was great fun setting up Dropbear, name resolution and dyndns updating all on TiVo before Xmas, and it probably saved a few quid not having to have my PC with Orenosp running 24/7.

However, last week my seperate wireless AP went down and so I thought what the heck, might as well get a combined doodah, such as the Linksys WRT54GS, and replace the (working) router too! (PMs if anybody is interested in a Linksys BEFSR41 V2 4 port router)

The WRT54GS was a version 4 model but I had no problems whatsoever re-flashing it with the dd-wrt firmware (you have to flash the mini version first and then the full one, although both do have Dropbear SSH in the builds). Everything up and running very quickly indeed. The website/forums/wiki are very good with easy to follow instructions.

Thanks to ptruman for starting this thread and bringing to my attention what can be done with these routers (and also to tefster for the help in getting all the TiVo based bits up and running previously)

 

Thanks to tefster I have dropbear running on tivo, and it's accessible from the local LAN and from the outside world.

But I have noticed a few odd things when logging in via ssh, in particular the environment variables are a bit screwed up. If I telnet in the environment has:

Code:

HOME=/
PATH=/bin:/sbin:/tvbin:/devbin:/var/hack:/var/hack/bin
PWD=/var/tmp

as expected.

Logging in via ssh gives:

Code:

HOME=/var/hack
PATH=/usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin:.:/var/hack:/var/hack/bin
PWD=/var/hack

which is odd considering most of those directories in the path don't exist on tivo.

Have I done something wrong?

 

This looks an interesing post but have been putting it off in fear of killing my router but am now going to go for it.. I used to ssh to a seperate linux box on my lan and then I could telnet into Tivo. Also through this I could ftp files to the Tivo.

With this setup will there be any way to get files onto the Tivo remotely? i.e adding modules / logso etc. With this ssh will I be able to scp in?

Cheers

 

Do you mean with Dropbear running on TiVo or on the router (such as with the dd-wrt firmware)?

Either way, the answer's yes

Having never used SCP before I thought I'd give it a go to check. I SCP'd (using WinSCP) direct to dropbear on TiVo and all seemed fine. Then I set up an SSH connection to Dropbear on my router (usinf PuTTY) and with the appropriate port forwarding, could then setup an SCP connection to Dropbear running on TiVo. Phew

 

No, its a "feature" of the ported version

The PWD will be set to wherever the shell got invoked from, which will effectively be
wherever the dropbear binary lives. Your telnetd gets launched from a different location
in the filesystem tree and so the inherited PWD is different.

As for the other two, those are hard-coded into the dropbear binary (or at least they are
but I changed them to more TiVo-like defaults). It was so long ago since I did the port that
I can't quite remember the rationale, but basically from memory the forked bash shell needs
to have something in them otherwise it croaks when it runs.

I hard-coded a pseudo-passwd entry for the login user to have /var/hack as the home
directory, and for the PATH I just took the dropbear default and added the regular TiVo
binaries. In theory it shouldn't make too much different to use of it though.

I've been meaning for ages to roll my patches into the 0.44 version of dropbear, but my
new company has been keeping me busy. I'll try and get around to rolling the patches on
and at the same time I'll re-do the defaults to take out the non-existent directories. If you
find having them there causes problems though then yell and I'll re-do the current version.

 

I did originally mean using the firmware but realised that my linksys router wasn't the corrcet version sop went with the dropbear approach.. works like a treat (after stumbling across all the same issues you had.. glad you asked them questions first )

Hurrah this is exactly what I wanted... Creating the dss key did freeze the Tivo worryingly for 5 minutes which I thought had killed it but it all burst back into life.

So in theory I can now disable the port forwading on my router for external http access to tivoweb and just tunnel it through this connection? Next job for today then

Cheers guys