Enabling telnet access
Enabling telnet access on the Mvix requires a bit of work. You basically need to download a firmware package, open it up, change a couple of files and then package it up again. And then upgrade your player with this modified firmware. Needless to say, this may kill your media player and is in no way supported or recommended by Mvix or any other entity, including me. De-bricking your player *appears* to be something that works every time though, but your mileage may vary.
If you’re still interested, here are the instructions for generic manipulation of the firmware package. See below for how to do the telnet thing.
Manipulating the firmware package
Follow the rather detailed instructions on the Mvix Wiki site. I’ve included a copy of them here, as sites tend to disappear over time:
If you are starting from a .pkg firmware file then you need to strip the headers and decompress the ROMFS:
dd bs=108 if=mvix-fw-1.1.25.pkg skip=1 | gunzip > mvix-fw-1.1.25.romfs
This file contains a complete filesystem. You can look inside the
file system (readonly) by mounting it. You may need to be root to do
this:
mkdir romfs.mountpoint mount -o loop -t romfs mvix-fw-1.1.25.romfs romfs.mountpoint cd romfs.mountpoint ls -l
Now you can have a look around. It’s all read only, because you are still actually inside the firmware file.
To make changes to the firmware, you need to copy it and then repack it once the changes are made. Do the copying as root, as we don’t want strange ownerships.
cp -a -r romfs.mountpoint romfs.mycopy cd romfs.mycopy
Now you can edit files. Interesting places to look are:
- etc/ – contains setup files. you can change the passwords in etc/shadow – use /usr/sbin/grub-md5-crypt on your local linux machine to create a new password.
- usr/curacao/ – contains the GUI files – images etc..
Now that you’ve made your changes, you need to repack it into a ROMFS and then into a .pkg firmware file.
genromfs -V "mambo" -d romfs.mycopy -f myfw.romfs
(You can get genromfs from: romfs.sourceforge.net, although your linux distribution most likely has a package for it. For ubuntu do sudo apt-get install genromfs)
Finally, pack the ROMFS into a .pkg file using makeFirmware.pl (local copy as of April 2007).
perl makeFirmware.pl myfw.romfs -o myfw.pkg
You can now load this onto your player via the GUI.
Cygwin notes: genromfs compiles and works fine under cygwin, for extracting the romfs google for romfs-tools.zip
Adding telnetd support
There are two files to edit in the romfs image, and you need to create a third. All file references below are relative to the romfs root.
1. Edit etc/shadow
Since we do not know the default root password on the device, we need to either clear it or insert one we know. One of the first lines in the
shadow file will be the root-account. The password is the part between the second and third :, a junk text string starting with $1$. To generate a new one, you can
use the command grub-md5-crypt on your local linux machine. Run that command and type your chosen password twice and it will
output the MD5 encrypted string you need. Take this output and insert it instead of the original one. Save file.
If you just want a blank password, then remove the whole $1$…. string between the 2nd and 3rd colon, so that the line starts with root::.
2. Move the file usr/curacao/curacao to usr/curacao/curacao.bak
This is the main program of the player, and is executed on boot.
3. Create a new usr/curacao/curacao containing the following three lines:
#!/bin/sh
/usr/sbin/telnetd &
/usr/curacao/curacao.bak &
This file should be made executable, so remember to
chmod 755 usr/curacao/curacao
We are basically tricking the player into starting our telnetd before it starts the actual media player software.
That’s all the changes you need. Package up your image and update your player with it.
The "easy" way
I’ve created a copy of the recent 1.1.27 firmware release and activated the telnet daemon. The username is root and the password is olav. Not recommended for wireless networks or other places where you do not have full control over who accesses your net. Note that there is also an experimental HTTP-daemon enabled, so you can point your browser at your Mvix and have a look at all the files there. Note that this web server may or may not allow you to upload files as well, I haven’t checked yet. But that is the plan anyway, to provide an easy way of uploading and downloading audio/video files to the Mvix. You can find the firmware here. No warranty, no nothing, everything is your own risk.
Note also that as an experimental feature, it is set up to run the scriptmvix_init_script in the top directory of any local device mounted on your Mvix. I.e. if you have an internal IDE drive with one partition, this firmware will try to execute the file /tmp/ide/part1/mvix_init_script with the partition name as the single parameter. Similarly for USB devices. Why, do you ask? Because then you can for example automatically mount your SMB/NFS-share(s) at boot so you no longer have to log in and do that every time you fire up your Mvix. My /tmp/ide/part1/mvix_init_script looks like this:
#!/bin/sh
/bin/mount -o nolock 10.0.0.2:/data /tmp/ide/part1/data
The nolock-option is there since there are no NFS support daemons running on the Mvix, and mounting without this option takes about 5 minutes.
Transferring files over FTP/HTTP
Once you have enabled telnet access on your media player, there are a few neat things you can do. One is transferring files from remote computers without going through the whole "disconnect Mvix from TV, connect to PC using USB, copy files, disconnect from PC, connect to TV" thing. As part of the firmware package, you have a command called wget. This is a poor mans copy of the "real" wget command found on many unix systems. Basically it’s for Web GETting files, although it can be used for both HTTP and FTP.
For this to work, you need a local storage on the Mvix, either an internal hard drive or something writeable connected to the USB port. This is where we will copy our files so that the GUI will be able to show them to us later on. In this example I’ve used an internal hard drive. The drive has to have ext3 as the file system, not NTFS. The firmware only has read-only support for NTFS, but from 1.1.25 it has full read/write support for ext3.
Then simply use the built-in command wget to fetch files from a web or ftp server. E.g.
way:~# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 6986 6986 0 100% /
/dev/ide/host0/bus0/target0/lun0/part 1283855840 215820 268988340 0% /tmp/ide/part1
Our internal drive is here /tmp/ide/part1, so we’ll store our files there.
way:~# cd /tmp/ide/part1/
way:/tmp/ide/part1# wget http://www.mvixusa.com/images/logo.jpg
Connecting to www.mvixusa.com[72.29.86.148]:80
logo.jpg 100% |*****************************| 6806 00:00 ETA
way:/tmp/ide/part1# wget ftp://ftp:ftp@ftp.uio.no/pub/ls-lR.gz
Connecting to ftp.uio.no[158.36.2.10]:21
ls-lR.gz 100% |*****************************| 4487 KB 00:00 ETA
Very handy.
Note however, that there are file size limitations here. The built-in wget command will not fetch files of more than 2^32 (4294967296) bytes over ftp. Trying to get larger files will result in the error message wget: SIZE value is garbage.
The same thing is most likely the case for http as well. And in addition to this, your web server may or may not handle files of more than either 2Gb or 4Gb depending on compilation options. Stock Apache 2.0.55 on 64-bit Ubuntu Edgy will happily serve you larger files though.
Once you’ve mastered this however, you may want to NFS mount external shares onto your media player as well.
