[Announce] Modify NAS200 firmware to run Telnetd and Twonkyvision 4.4.3

I figured out how to modify the NAS200 firmware (V3.4 R62) to run a telnetd daemon for shell access. See http://www.nslu2-linux.org/wiki/NAS200/Telnet to find out how I did it. You don't have to open the box so you won't void your warranty but you will need a Linux PC and some development tools such as Make to build the firmware.

The only problem I had with installing my own firmware was that the Twonky server goes nuts: it completely ignores the settings in the NAS200 setup pages and the database goes kerploowy: my D-Link DSM-320RD UPnP media player only finds a 48x48 Twonky icon when I run my own firmware.

So just for gits and shiggles I downloaded the Linux x86 version of TwonkyVision 4.4.3 (the latest) onto a harddisk of the NAS200, and used Telnet to start it from there. And guess what: it works!

Even better: it works better than the TwonkyVision that was included in the original NAS200 firmware: now my DSM-320RD shows all my videos (encoded in MPEG-1 by my photo camera and MPEG-4 "simple" with Nero Recode 7, haven't tried MPEG-2 yet) and my photos (although it takes very long for photos to show: probably Twonky has to resize them which takes long). And of course the downloaded Twonky has all the configuration web pages that are missing on the NAS200. I can even stream Shoutcast radio to my UPnP player. Cool!

Looks like after two years, I can finally put my dusty DSM-320RD to good use!

I LOVE that NAS200 (and no, I don't work for Linksys or D-Link )

===Jac

I know I may have to buy a new license for TwonkyVision (since the one I'm using now is not the one that came with the NAS) but I think it's worth it.

It not only runs 486 code, it also run glibc (not uclibc). So yeah, apart from the problem that 150MHz is not very fast compared to today's PC's and 32MB of RAM is not an awful lot of memory (it does create swap partitions on the SATA disks), it should be able to run literally thousands of apps.

I don't think the hardware emulates a complete PC but evidently it's close enough to run a server app like Twonky straight out of the box. Linux rulez!

Looks like you have to reinstall or update libstdc++ on your host system... You will have to give us waaaaay more information to help you with that. What distro of Linux do you have running on your host system? Which version?

This file contains the modified files and a script to unpack them into the Linksys source tree.

Unpack the archive on your host (Linux) system with tar xfvz nas200_telnetd_source.tgz and then type the command ./runme.sh

The runme.sh shell script will do the following:

It checks if the Linksys source tarball is in the current directory; if not, it downloads it from the Linksys FTP site using wget

It unpacks the Linksys source tarball

It unpacks the target filesystem in the Linksys source tree

It patches the sources according to the article I wrote

It optionally runs "make" to build the image

After you build the image, you can download it into the NAS200 by pointing your web browser to the NAS200's firmware page and using the browse button to browse to NAS200_V34R62_GPL/images/NAS200_V34R62.bin.

===Jac

PS1: The tarball on my website also contains the script that I used to pack up the sources into the tarball, in case you want to make modifications and roll your own. The "runme.sh" file can be started by itself, but the "pack_telnetd.sh" file needs to be started with source ./pack_telnetd.sh. I did this on purpose to prevent confusion about which is which.

PS2: I also have a tarball that contains both the changes and the original Linksys sources (in accordance with GPL). If you want to download that, PM me with your email address and I'll give you a link to it; it's quite big (230MB) so as long as the sources are available from Linksys, I'd rather let you use their bandwidth :biggrin:.

PS3: The sources don't include the thoughts about running the telnetd conditionally (I'm working on a more generic solution for running scripts and other software from the harddisk automatically)

My telnet sessions is consistently hanging when exiting busybox. I am unable to reconnect to telnet until I reboot the NAS200. Has anyone else experienced this issue? Any suggestions on how to resolve this?

My telnet sessions is consistently hanging when exiting busybox. I am unable to reconnect to telnet until I reboot the NAS200. Has anyone else experienced this issue? Any suggestions on how to resolve this?

Thanks,

Steve

Click to expand...

I figured it out. I needed to run the twonkymedia service demonized. Now telnet will exit properly.

Incidentally, the reason why Telnetd won't allow multiple sessions is because it can't get a terminal if another Telnetd is already running. It may be possible to fix this by creating more than one /dev/pts/<number> device but I haven't checked this.

And I can't... because I bricked my NAS200 this weekend: I made a small mistake in a startup script so it wouldn't boot anymore and once I figured out how to get to Redboot (and unnecessarily voided my warranty in the process ), I made the even more stupid mistake of following the NSLU2 recovery instructions too literally so I put the firmware in the wrong location and now Redboot won't even come up :wall:.

I'm working on a JTAG cable (worked most of Sunday on tracing the pins of the JTAG connector to the CPU) but Frys in Tempe is very bad on electronic parts stockkeeping so I couldn't find a chip I needed, and a passive cable doesn't seem to do the trick: the LEDs are blinking but my host machine doesn't seem to hear the NAS200. Or maybe it's speaking the wrong language: the R8610 is not on the list of supported devices of JTAG Tools and there may not be enough information available to add it -- RDC is unfortunately very secretive.

Anyway just so you know: the entire Flash is writeable in the NAS200 and there's no built-in recovery program like on the WRT54G or the NSLU2. So if you make a mistake and wipe the boot loader of the NAS200, it's JTAG time. You have been warned.

I'll keep you guys posted and if I get it to work again, I guess I'll write a page on JTAGging the NAS200.

And if I can't get it to work again, I'll have to wait until I get paid again to buy another one. In that case I might mod my first NAS200 into an eSATA case .

Thanks. I already had the first link but not the second one. Looks like that thread has some interesting links. I will look into it later.

Anyway for now, in case you're reading along... the pinout for the JTAG connector on the NAS200 board (starting on the side that's farthest from the speaker) is:

VCC

GND

TCK

TDO

TDI

TMS

This pinout seems to be the standard in the RDC world. The picture of the JTAG connector on Ivan Kuten's page corresponds to this and I've seen other RDC based schematics that use this.

To make the board boot in JTAG mode, you have to pull pin 40 of the R3210 to high while you're applying power. The pin is normally pulled low by a 4K7 resistor R119 near the flash chip. The easiest place to solder a wire to this trace is pin 35 of the unused U26 chip (where more RAM can be installed). You will have to temporarily connect it to VCC (e.g. on the JTAG plug) while switching the board on, then let it hang loose (make sure it doesn't cause a short circuit).

The 3 rightmost LEDs and the one unimplemented LED are connected to the same pins as the JTAG:

The good news first: I built a new JTAG cable, based on the Xilinx design (see mstombs' first link), and it works. I used RDC Loader (see somewhere in the forum thread at mstombs' second link) to connect to the board and I can see just how screwed up my flash now is :biggrin:.

The bad news: the RDC loader doesn't recognize the Intel flash, so there's no easy way to flash an image (or even just redboot) onto the board.

I can load Redboot into RAM, but it appears that there's no easy way to tell the debugger to jump to another location (changing CS:IP doesn't seem to work).

Later today I will try the jtag tools to try and flash Redboot (JTAG tools should know the flash chip but it doesn't claim to know the CPU).

I wish I didn't have to go to work today so I could continue figuring this out

This weekend I managed to revive my box using JTAG. I think I'll rename my box "Johnny5" (as in the quote "Johnny5 is alive! No disassemble!" from the movie Short Circuit). Here are some conclusions and it's not all good news...

The only JTAG software that seems to work with the board is RDC Loader (http://rapidshare.com/files/62288505/DT_4MB_XP.zip, contact me if this link goes dead). No other JTAGgers that I could get my hands on, would recognize the CPU. RDC Loader is a great little Windows program that offers all the features you would expect from a JTAG debugger. It's also supposed to be able to write a file into Flash memory (it wants to do this at startup) but unfortunately it doesn't recognize the Intel flash chip on the NAS200 motherboard so it can't erase it or overwrite it.

So the only way to bring up the board when your flash is b0rked, is to download working boot code into RAM and tell the debugger to run it from there. In theory that shouldn't be too hard because it's easy to extract the ecos ROM boot code and if you know which registers of the North Bridge to hit, you can even download it into shadow RAM in the normal location where it's supposed to be. By the way the boot code is in images/redboot.bin in the Linksys source tarball at offset 0x1FB00. The length is 0x266 bytes and normally this is stored at real-mode memory location 0xF000:0xFB00. The CPU boots from 0xF000:0xFFF0 and then jumps to 0xF000:0xFB00 via a long jump instruction. The source code is in ecos/ecos-2/packages/hal/i386/pc/v2_0/src/romboot.S

In practice, the problem is that while the CPU is in real mode, there seems to be some weird address translation going on that's confusing the crap out of the debugger. At least for some of the real-mode address space (0x0000:0x0000 - 0xF000:0xFFFF), whatever you see in the debugger is not what the CPU sees: you can download files (right-click on the memory window) and execute them (by setting CS:EIP and using the debugger), but sometimes no matter how much you refresh the windows (by using Go To in the right-click menus), the CPU is just clearly executing instructions that have nothing to do with what you're seeing. And every time you restart, the list of working and non-working segments in RAM seems to be different.

It took me a long time to figure out what's going on, and last Saturday, because I thought something must be wrong with my cable, I spent most of the day trying to get parts from the two "local" Fry's stores to build another JTAG cable that resembled the original Xilinx schematic closer than my first cable. I'm still not 100% sure if my hypothesis is right but I think the RDC R3210 CPU may be using GDT/LDT address translation while in real mode. If this is true, it's a hardware bug: the only translation that should happen in real mode is segment * 16 + offset -> physical.

Normally one of the first things an OS does (even an embedded OS) is set up a GDT and switch to Protected mode, so this is not very severe for normal bringup. But it makes it very difficult to put together a web page with a guaranteed-to-work recipe to "Johnny5" a b0rked NAS200. I can't just write: "output this-and-that value to I/O port such-and-such, load redboot.bin into memory location this-and-that, change CS:EIP to these numbers and click GO". I would have to either let readers figure out manually which memory segments work (by poking in some code and single-stepping through it, which is basically what I did), or find some foolproof way to make everything run smoothly.

I have a strong suspicion that the GDTR register is properly initialized to 0 at reset time, so the GDT is in a predictable location at least, although it may get overwritten during debugging because SS:ESP is inited to 0000:00000004. I think one way around the problem is to construct a "sane" GDT in a binary file and load it into memory at location 0 after changing the stack pointer: downloading files via RDC Loader's Memory window always happens to physical memory locations so no translations.

[Edit: modified this paragraph with new findings] Anyway, I learned a lot from reading the ecos/Redboot source code and the datasheet of the R8610 (I couldn't find a full R3210 datasheet but the R8610 is equivalent). The "flash" command flashes the 128KB from address 0x400000 into the real-mode part of the Flash ROM to update Redboot. This is unfortunate because it doesn't warn you about what it's going to do, and by the time it's done, you turned your box into a nice paperweight. This is basically what happened to me in the first place and I'm sure I won't be the last person that this will happen to. The good news is that it's a lot harder to wipe the Linux kernel and ROM disk with Redboot commands, so once you know how to JTAG the device and restore Redboot, chances are that your Linux will be intact and your box will boot just fine like before you decided to play around with Redboot a little bit.

During startup, 2MB of Linux kernel are copied from 0xFF800000 to 0x400000 by the Redboot code and booted from there. The rdinit image is not copied to RAM at all (the code is commented out in the Redboot sources). This is fine because the squashfs image that the NAS200 uses, is read-only anyway and copying to RAM would only be a waste of memory. Redboot has an "upgrade" command that lets you update the Linux image over the network. One such utility is UGUTIL (found via the NSLU2 Linux website) which "sees" the NAS200 when you run the upgrade command in Redboot, but then gives an error saying it doesn't recognize the hardware. There is a (closed-source) program called "download" in the images directory of the Linksys source tarball but I haven't been able to use that. Fortunately I was lucky enough to find my linux kernel and initrd intact enough to get to a shell prompt so I could launch all the usual programs and flash the entire ROM via the webpages. I think for now I spent enough time on this and I'll leave it to someone else to figure out how to flash the kernel and initrd by using only Redboot :tongue:.

If you are reading this because you b0rked your NAS200 beyond what can be done with Redboot, and you want to JTAG it, let me know and I'll try to help you. Note that you'll have to get or build a Xilinx style JTAG cable (see Ivan Kuten's website). I tried a passive cable on 3 different PC's and it didn't work; your mileage may vary. You will need something with at least 4 tri-state line drivers (latches). The transistor and surrounding components at the top of the schematic which are connected to pin 15 of the printerport, aren't needed (they seem to be there only to detect that a device is connected), and you also don't need the part of the circuit that's designed to pull down TDO (the fifth line driver and second OE pin, controlled by pin 6 of the printer port). If you don't understand this, let me know as well but be prepared to hear me say that you may not be qualified to do the project

The parts aren't very critical: I already mentioned that I had a hard time getting parts in retail stores and I didn't want to wait for an online order for a 50 cent part with 5 dollars added for shipping and handling. So I built my cable around whatever I could get: one of my cables has a 74HC244 and no capacitors, and another cable has a 74HC573 and capacitors. Both work fine, without the transistor circuit and without the pulldown. I used about a foot (30cm) of flatcable on the printerport side and about 2 inches (5cm) of flatcable on the JTAG side.

Actually I had already found that site, too (we must have the same Google or something heh :wink. Indeed, for now it looks like RDC Loader is the only way to go with JTAG on the NAS200. No problem really -- I'm sure that for the time being, RDC loader will be much more useful than urjtag or jtag tools anyway.

===Jac

PS: I got Dropbear to work and I'm working on kexec-tools. More info later.

Even though I haven't got a NAS200 (yet?) I used your script to build myself a version of the telnet enabled firmware. I've no idea why but the script hung after spending hours getting the tarball from Linksys, so I had to crtl-c it and run it again which went fine - maybe I just lost a prompt and it was waiting for input?

Known issues:
- When picture rescaler is disabled and and images do not have an embedded thumbnails
the Playstation 3 needs a long time to show thumbnails. In such a case the PS3
retrieves the whole image and downscales it by itself. On large images or when system
resources are low the PS3 is not able to show more thumbnails.
- Playstation 3 is unable to recognize some MP3 files which contain ID3v2-tags at the
beginning of the media file

Even though I haven't got a NAS200 (yet?) I used your script to build myself a version of the telnet enabled firmware. I've no idea why but the script hung after spending hours getting the tarball from Linksys, so I had to crtl-c it and run it again which went fine - maybe I just lost a prompt and it was waiting for input?

Click to expand...

Dunno... Probably just a glitch. I have to admit I didn't do a whole lot of testing on the script :biggrin:.

If you download the file from the Linksys site manually, it should work fine. It does take a while to download the tarball (it's more than 200MB) but I think wget should give at least SOME feedback about progress even if you're condemned to a non-broadband internet connection .

wget did give lots of feedback (only downloading at 20k/s for some unknown reason!) and got to 100% , but the script didn't move on, I couldn't see what was wrong so just ran it again and it continued fine

wget did give lots of feedback (only downloading at 20k/s for some unknown reason!) and got to 100% , but the script didn't move on, I couldn't see what was wrong so just ran it again and it continued fine

Click to expand...

The second time you ran it, it saw that the file was there and skipped the download. Like I said, should be fine

[Edit: Maybe it was unpacking the tarball? This takes a while and I believe I didn't use the "v" flag to show filenames as they are unpacked]

I already have 3.4r71 loaded on my NAS200, and my drives are formatted as non-journaled. I'd like to load the hacked 3.4r62 version, but I'm concerned about the formatting difference. Has anyone tried this?

I already have 3.4r71 loaded on my NAS200, and my drives are formatted as non-journaled. I'd like to load the hacked 3.4r62 version, but I'm concerned about the formatting difference. Has anyone tried this?

Click to expand...

What will happen when you do this is that the NAS won't recognize the filesystem type of the data partitions: the kernel of R62 doesn't have ext2 filesystem built in. It will however boot just fine because the configuration partitions are still XFS in R71. It will just show both your disks as unformatted.

I had R71 on my NAS200 for a short time and formatted my second harddisk unjournalled. Now that I have my hacked R62 installed, it sees the second harddisk as unformatted but it doesn't spontaneously format it and it doesn't keep bothering me about the unknown disk format. So I simply added ext2 support to the R62kernel and now I run a script to mount my second harddisk onto a "disk2" directory that I created on my first harddisk (I couldn't figure out how to mount it on /harddisk/volume_2 and make the system recognize it automatically and add shares on it).

I don't think downgrading to R62 (a hacked R62 in this case) will cause the NAS200 to automatically reformat either drive, but I haven't tried it so if there's important data on your disks, don't do it. (Actually I wouldn't run beta firmware on a NAS that stores anything you can't do without, but that's a whole different matter).

Unfortunately Linksys hasn't released a source tarball of R71 so there's no telnetd page for R71 yet. However if you already have R62 hacked and you want to build a Telnet-enabled version of R71, you could just extract the R71 filesystem and loop-mount it, change it as needed and rebuild an image. Be careful: if you make a mistake and download a bad image to the NAS200, you will brick it (i.e. it will not boot) and only the serial port or JTAG will save it. Needless to say I haven't tried it and I would recommend against it.

Here's a challenge to you Jac. For a NAS there isn't a problem with diskspace, could you install build tools on it and get it to build itself a new firmware? Guess it would take forever, but wouldn't it mean native tools not cross-tools?

The NAS200 has plenty of harddisk space and enough memory space to compile its own firmware. I haven't tried it, but I suspect that the compiler that's included in the Linksys source tarball is not really a cross-compiler i.e. it was built to run on x86 (not i686) to compile code for x86. It wouldn't surprise me if it turns out that it runs on the NAS200 right out-of-the-box. The difficulty in getting it installed is probably that the root file system is read-only so you'd have to do all kinds of workarounds to put the libraries and include-files into your file system. Could be fun, but I'd rather spend my time on making something else work that doesn't already work in a different way.

If you want to experiment with running the compiler on the NAS200, you will probably want to set up distcc to let other (faster) machines on the network do the actual heavy work.

Of course if you have multiple NAS200's, you could even use distcc to make them work together and then your firmware would still be all "NAS200 natively compiled" (we should design a sticker for that :biggrin: )

Hey Jac thanks for the great post and scripts to do all the leg work. The bad part of my whole situation is I downgraded from the RC71 firmware and now my drives are unrecognized. The major problem I have is that all my data exists on 1 of the 2 drives and I really don't feel like losing it. I tried going back to RC71 to copy the files to the 2nd formatted drive but it still wouldn't recognize the drive! I noticed you mentioned compiling with ext2 support and mount the drive. Just curious how to do that so I can all my stuff off of there!

I noticed you mentioned compiling with ext2 support and mount the drive. Just curious how to do that so I can all my stuff off of there!

Click to expand...

The easiest and fastest way to get files off your drive is probably to take the drive out of the NAS200 and connect it to a PC that is running Linux, then mount the second partition of the harddisk and copy your data.

As for reconfiguring the kernel: this works the same as reconfiguring a kernel for your Linux PC: basically you go to the linux directory in the source tarball, su to root, run "make menuconfig", add "Second Extended Filesystem" under "filesystems", make bzImage, copy the bzImage file to the images directory and run build_image.sh in the root of the unpacked source tarball.

The easiest and fastest way to get files off your drive is probably to take the drive out of the NAS200 and connect it to a PC that is running Linux, then mount the second partition of the harddisk and copy your data.

As for reconfiguring the kernel: this works the same as reconfiguring a kernel for your Linux PC: basically you go to the linux directory in the source tarball, su to root, run "make menuconfig", add "Second Extended Filesystem" under "filesystems", make bzImage, copy the bzImage file to the images directory and run build_image.sh in the root of the unpacked source tarball.

===Jac

Click to expand...

Sadly I have a laptop and no PC with SATA (I can get my hands on one if I need it) hence why the attached storage was so very attractive.

I have tried to build a new linux kernel (don't feel like bricking my NAS though) but have encountered stiff resistance (some compilation errors) but this might be because I am using a ****ty Mandriva VMWare image. Maybe if I use a decent VMWare image of a distro such as gentoo I might be in better luck...

Sadly I have a laptop and no PC with SATA (I can get my hands on one if I need it) hence why the attached storage was so very attractive.

Click to expand...

If your laptop at least has USB, you can get a USB to SATA converter for about $20 (like this oneor this oneor this one at Newegg; good electronics stores like Fry's also carry these although they may offer less variety).

The cool thing with VMWare is that it supports USB so you can connect your virtual PC to a real USB device like a harddisk on a USB adapter. The USB device will show up to the VMWare computer as a USB device, but any recent and decent Linux distro should have no problem accessing a storage device on a USB port.

If you're currently using VMWare Player (which doesn't let you change anything to the virtual PC), get VMWare Server instead; it's free and it will let you create VM's and modify existing ones (unlike Player).

I have tried to build a new linux kernel (don't feel like bricking my NAS though) but have encountered stiff resistance (some compilation errors) but this might be because I am using a ****ty Mandriva VMWare image. Maybe if I use a decent VMWare image of a distro such as gentoo I might be in better luck...

Click to expand...

My favorite distro is Gentoo; it's a source distro that lets you build exactly what you need, customized for the system that you're building on. Maybe if you're working with VMWare you should google for VMWare "appliances" with linux already installed. There's a Slackware and Gentoo appliance here.

If you want to learn more about how Linux works, I also recommend Linux From Scratch which is an incredibly good way of "learning by doing" (Gentoo could be seen as sort of an automated way to do Linux From Scratch, although they're not related). I have to warn you that LFS takes a lot of patience: it took me over a week to do my first LFS install. A Gentoo install takes a few hours the first time you do it.

The reason I didn't give more detailed instructions is that I don't want to give anyone a false sense of "nothing can go wrong". I'm not saying that you aren't smart enough to build your own firmware, I just want to prevent casual readers from bricking their box. I'm working on a better solution for building your own customized image; I expect to make an announcement in these forums in about a week or so.

I'm making some changes to files in /etc but as you mentioned this directory is a ramdrive. So, where do I need to copy the files to so that they are saved? I made changes to files in /etc/rc.d and /etc/resources... I tried to copy the new files to /harddisk/volume_1/conf but they aren't moved over after the reboot. and I used /etc/rc.d/rc.reboot..