A few months ago, I posted a hardware teardown of the CVS Sylvania Netbook pictured above. After working with it and performing a lot of research on it, I promised a follow up article, and here it is.  To sum it all up, with a bit of modification to the software, a spare SD card and a lot of patience, you can actually turn this thing into a somewhat useful Linux device.  There’s also some improvements and suggestions to be had for improving the Windows CE side of things should you decide to continue using it in its default state.

When I posted the original teardown, I was somewhat distressed at how little information there was for this device. There was a ton of “marketing” material online however very few real-world posts.  This appears to have changed and although most of the reviews lamblasted the device as a horrible design and underpowered, I have found that for the price I paid for it, it’s not bad at all.  In this article, we will be focusing on software because as much as I’d like to say I’ve done a lot of hardware mods to this thing, the truth of the matter is that I haven’t.  Time has continued to get away from me and I’ve had to put a lot of projects on hold.  But let’s not start this article off on a downbeat.

In the three months that I’ve been doing research on the Sylvania Netbook, I have uncovered a lot of information that can help turn this machine into a pretty useful piece of equipment.  The fact that it has a pretty decent battery in of itself should be of merit to justify the time invested in fine-tuning it.

1: Windows CE

In my research, there have been two key complaints against the Sylvania netbook in regards to a “stock” configuration.  The first complaint has been that it is running Windows CE (affectionately called “WinCE”) and the second being that the WinCE installation is really badly implemented.

• The key thing to remember with working with Windows CE is that Windows CE is NOT Windows like on your desktop or “normal” laptop! Windows CE was designed for small form factor devices and although it shares the same name as it’s bigger brother desktop OS, Windows CE can not run Native Windows applications. This appears to be the biggest hurdle in locating user software for the device as people will attempt to download software then when they get the software into the netbook, they are thrown off by an error message stating it’s not a “valid” application.  Consider it like taking a MacOS program designed for MacOS and attempting to get it running in Windows XP.  It ain’t gonna happen.  That being said, there is Windows CE applications out there, however the pickings are slim.

• The other issue with working with the stock Windows CE installation is that the OS software is so badly implemented on the netbook that most things that should work, don’t.  Thankfully for us there is a patch available that will make things easier.  From research, the patch addresses several performance issues with the core OS, several updates to the builtin applications as well as an update to Internet Explorer.  Unfortunately, IE will still render mobile sites by default, but the rendering won’t take as long.  The patch also fixes the issue with the wireless card not being able to properly associate with WPA/WPA2 secured networks and DHCP release/DHCP renew works as expected.  I have uploaded the patch to here.  In order to install the patch, follow the below instructions. You will need a spare SD card at least 128MB in size.

Here’s how to download and perform the OS update:

1. Download the patch from here:  sylvania_laptop_OS_update.zip
2. Extract the executable to an SD card.
3. Insert the SD card into the Sylvania netbook.
4. Browse to the SD card slot (Computer -> SD Card)
5. Launch the patch and follow the on screen prompts.

2:On the Linux side of things…

When I did my original research, I was fortunate to have come by a site dedicated to a Linux distribution made solely for the WM8505 series devices like the Sylvania Netbook. The site and the distribution were called Bento Linux and much like the Japanese namesake, the distribution was very small and was designed to be able to run within the computer’s limited spec.  Unfortunately, the site www.bento-linux.org no longer exists but thankfully I still have the documentation and files needed to pull it off.  If you are the owner of bento-linux.org and are willing to give me the site files, I would be more than happy to host it here. Please contact me in the comments.

One of the added benefits of Bento-Linux is that unlike some replacement OS installations, this is a sidecar installation meaning that all work is done on the SD card.  If you want to boot to Windows CE, halt the Linux OS, pop out the SD card and power the Netbook back on and you’re up and running like nothing happened.  Although the Bento Linux site did have instructions for performing an installation to the device’s flash ram, it is not recommended as if you accidentally mess up the Linux distribution, there may be no recovery. In a sidecar installation, you can pop the SD card into another device, make your changes, and then put the SD card into the netbook and you’re up and running again.

Although the site claimed that the distro could run on a 512MB SD card, I will up the recommendation to at least a 2GB card.  Prices are low and SD cards are very commonplace so it’s worth it to get a larger chip.  I started out on a 2GB SD card, but later upgraded to a 4GB Microdrive and noticed a significant performance increase going from solid-state memory to a USB Microdrive. Your mileage will vary, but it is recommended to stick with an SD card first, then perform upgrades and additional installations as needed later on.  As far as USB devices are concerned, you can use any USB storage device/keydrive that is recognized by the usb mass-storage driver in Linux.

Please note that the version of Bento I was running is usable however it did not appear that the sound card was operational. Since I am intending to use this as an external serial console, this was not a deal breaker for me.

Installation (SD Card Only)

Bento-linux comes in two parts. One part is for a FAT16 partition placed at the beginning of the SD card and it contains the boot commands needed to tell u-boot (the Netbook’s bootloader) how to boot the linux kernel and the root filesystem.  The other part contains the linux kernel and the filesystem in an EXT3 filesystem and will contain all the files needed to run Linux.

1. You will need to start with an SD card at least 1GB in size.  I used a 2GB which gave me some room to play around on and of course the bigger, the better.
2. Partition the SD card with a 20MB FAT16 partition at the beginning of the card and the rest of the disk space can be allocated for an EXT3 partition.  Do not create a swap partition.
3. Download the file fatpart.tgz and extract it into the root of the FAT partition on the SD card.
4. Download the file extpart.tgz and extract it into the root of the EXT3 partition of the SD card.
5. Unmount the card and insert into the Sylvania’s SD cardslot and power on the machine. It should boot the Bento Linux distribution

Installation (SD Card + USB stick)

This setup does not require special partitioning, however it does require that the SD card be formatted FAT16.   You will also need a USB storage device formatted EXT3.

1. Download the file fatpartusb.tgz and extract it to the root of the FAT formatted SD card.
2. Download the file extpart.tgz and extract it to the root of the EXT3 formatted USB stick (or hard drive).
3. Insert the SD card into the Sylvania’s SD slot and insert the USB stick into a free USB port on the Sylvania.

In either instance, when you first boot the distro, it will simply bring you to a console prompt and you are good to go.  There are a couple of things you may want to do:

• (Pretty much required)  Set a root password.
• Install fluxbox (light weight graphical interface) and wicd for wireless control.
• Install aurora (lightweight firefox lookalike)
• Install other applications though apt-get as desired.

Although the bento-linux site is no longer in existence, it appears that all the repositories that come with the distribution point to the arm ports of the official Debian repositories.  Prior to them going offline, I saw a note about Bento-Linux had the sources for the WM8505 however it appears that VIA has recently released the sources for the WM8585/VT8505 chips that drive the netbook so if you have any custom drivers, it appears that now there is an easier method for getting the drivers compiled in.  I am not a kernel compiler expert so I can’t advise on this process, however some brief research does seem to indicate that there is some element of truth to this.

Linux Impressions and final words

After getting the Bento Linux distribution working comfortably in the netbook, I played around with it and made some tweaks here and there that did give some notable boost in performance.   If you are using a spinning platter form of storage, creation of a  swap file or swap partition is recommended as it will give you a performance boost.  Attempting to make a swap file on the SD card or on a solid-state USB drive are not recommended because of the performance hit when writing to these devices and also due to the issue of “burn-in” when a storage cell is written to frequently.  I found that the device works decently enough for quick tasks and light webpages however it will not handle flash at all, nor will it be able to render sites with large amounts of images.  In my testing, I was able to use this device to configure Cisco switches and other devices through a USB-Serial adapter and Linux’s “minicom” terminal emulator.

While I believe it was a valiant effort by Sylvania to enter into the netbook market, I do believe that they should have done more research.  The Sylvania netbook, even running Linux and with all the performance tweaks mentioned, still is easily beat by Asus’ first offerings into the Netbook market. The two biggest things that seem to harm this device are the lack of RAM in the system (mine only has 128MB RAM) and the sub-par processor less than 1GHz.  If you have one, then you may be able to make it work for you, however if you are considering one, I’d stay clear.  It’s not worth the price they are asking for it at CVS.

A couple of comments left by Syed and Dave to the original CVS netbook post indicates that there are people out there that are able to get Android running on this device.  If you have information or an article written on how you did it, let me know in the comments.  I’m interested in trying it out and finding out what works on this machine.

In this final article in the three part Ubuntu IDS series, we will go over installing, compiling and configuring Snort and Nessus on our new IDS device.  We will use Snort to analyze traffic as seen by the IDS and we will use Nessus to perform vulnerability testing on the network. The process for installing Snort will also cover installing SnortReport provided by Symmetrix Technologies so we can translate Snort’s cryptic messages into a more readable format that we can take action on.  Read on as we wrap up the installation and finish our IDS device.

This article is divided into three sections. The first section will cover installing Snort, then we will move on to customizing Snort beyond the steps covered in the first section for our specific installation.  Finally we will end with installing Nessus.

1:  Installing Snort

Admittedly, this was the longest part in the series. I had tried manually to compile and install Snort from sources over and over again and wasn’t getting anywhere fast.  I had performed research over and over again on what options to use and was no further along than when I had unzipped the sources.  Luckily my research finally turned up a complete HOWTO article written by Symmetrix Technologies which provided instructions on how to compile and set up Snort.  You can download their HOWTO from this site:  http://www.symmetrixtech.com/articles/004-snortinstallguide286.pdf

There are some discrepancies that you must take note of: If you are using the bonded interface as described in the prior articles, you will need to use the interface “bond0″ instead of the document’s provided eth1 interface for monitoring.  If you monitor an ethX interface, you will only get half of the conversation, and since most of Snort’s ability to detect traffic relies on analyzing stimulus and the responses to that stimulus, you will be severely cutting down on Snort’s effectiveness.

2: Snort Tuning

If you’re this far in, then it’s safe to assume that you have already downloaded Snort, the associated ruleset and have SnortReport installed and running.  There are some things that the Snort installation howto did not entirely touch on and these are things that we will cover here.

Adding BPF to /etc/init.d/rc.local

One of the things missing from the Installation HOWTO was to add a BPF expression to the snort command line. BPF stands for “Berkeley Packet Filter” and is used by Snort and tcpdump to control what traffic is being analyzed by the respective tool.  In our configuration, we need to add an exception for the IDS’s management traffic otherwise when we install and run Nessus, we will end up triggering a ton of alerts.

Edit the /etc/rc.local file and locate the snort line.  Add ” not host 192.168.0.253″ to the end of the snort line. Replace 192.168.0.253 with that of the IP of the management interface of your IDS.  This is the BPF syntax that tells it to monitor your network but not the IP of your IDS device. By adding it to the end of the snort command, we are effectively telling Snort to not listen to the traffic generated by Nessus when we decide to fire it off.

Password Protect SnortReport:

Regardless of whether or not your IDS device can be reached from the Internet, there exists several vulnerabilities in SnortReport including one that allows potential code execution.  This could allow someone that knows you run SnortReport to execute code on your IDS and would be counterproductive to our efforts.  Until SnortReport has been fixed by SymmetrixTech, we will have to use a more basic method of securing it.  In order to provide minimal protection for SnortReport, we will add .htaccess protection to the directory that SnortReport was installed in so that way only authorized people will have access to SnortReport.

As root, we will use htpasswd to create the password file.  If you forget it later on, you can recreate the file easily using the below steps. Use the below command to make the password file and replace “joe” with that of your desired username.

# htpasswd -c /var/snortreportpasswd joe

Now, we need to create a .htaccess file in /var/www/snortreport-1.3.1 to reference it.  Copy the below code and enter it into /var/www/snortreport-1.3.1/.htaccess and don’t forget the . in the filename.

AuthName "SnortReport"
AuthType Basic
AuthUserFile /var/snortreportpasswd
Require valid-user

Finally, there is one more change we need to make to Apache2 to get the .htaccess protection working.  Edit /etc/apache2/sites-available/default and look for the clause that looks like the one below:

<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

Change the “AllowOverride None” to “AllowOverride All” and then restart apache2 via /etc/init.d/apache2 restart . Now try it out by going to http://(your IDS IP address)/snortreport-1.3.1/alerts.php. You should  get a password prompt. Type in the password that you created using the htpasswd command earlier and you should see a green page that says SnortReport.

When you first load the page, you will see two dropdowns for Timeframe and Day.  If your IDS has received any incidents, you will see it show the incidents here.   Clicking on the incident summary will show more details including the source and destination IP addresses. Clicking on the IP will return correlated events that include the source or destination IP you clicked on and will show packet payloads and IP addressing information.

Now that you have a way to read the incidents that the IDS receives, it’s up to you to decide whether or not the incidents generated are something to take action against. However, installing an IDS is only one half of the solution.  In order to be aware of the effect an attack may have on your network, you first must know what vulnerabilities exist on your network.  For that, we turn to the free vulnerability scanner, Nessus.

3: Installing Nessus

Nessus is widely used as a professional commercial-grade vulnerability scanner. It can generate reports that indicate per host what vulnerabilities exist and can provide information on where to go to learn more about patching or mitigating the threat.  Keep in mind that while Nessus is often used on Linux, it is a commercial product.  It does have a home version which we will be using in our installation however the home version can not be used in a commercial environment.

The Nessus HomeFeed provides your Nessus installation with the most up-to-date vulnerability detection methods and signatures.  Access to the HomeFeed does come at a cost, however the benefits of having a vulnerability scanner outweigh the loss of a couple of features. Most notably, a feature that is only available to their commercial feed is that you can not set up recurring scans of you home network, e.g. you can’t tell the IDS to automatically scan your network and generate reports on a regular schedule.  The only other limitation that I have been able to find is that the scans are limited to 16 active hosts per report so if you have 32 hosts, you will need to run two scans. Despite the two limitations mentioned above, Nessus is still a great scanner, and will work quite well for identifying vulnerabilities on your network.

All that being said, let’s get started.

First off, head to Tenable Security’s website at http://www.tenable.com/products/nessus/nessus-homefeed and register to receive your activation code. Keep your email handy, you will need it later.

Next, head to http://www.tenable.com/products/nessus/nessus-download-agreement and agree to the license, then download the Ubuntu debian package that is appropriate for your distribution.  Since this tutorial is based on using Ubuntu 10.04, I downloaded the Ubuntu 10.04 32 bit version. Although the filename says “ubuntu910″, this version was recommended by Tenable as the version to use for 10.04.

Now, SCP the installation package to the IDS and then use dpkg -i Nessus-4.4.1-ubuntu910_i386.deb to install it into the server. Please note: If your Ubuntu Server is running a 64 bit kernel, please download the 64bit version of Nessus.

Once installed, you will need to add a Nessus user to the service so you can login.  Nessus users are seperate from OS users, so you can have multiple users without having to add multiple users to the system.  To start this process, run /sbin/nessus-adduser and follow the prompts.  For the first user that you add, you will want to add an administrative user. This user will be able to adjust Nessus’s scan policies, behaviors and other settings within Nessus.

Now that you’ve added a user, you will need to register your Nessus installation using the HomeFeed code in your email.  Run the command /opt/nessus/bin/nessus-fetch –register <Activation Code> and allow it to complete the installation. Substitute <Activation Code> with the HomeFeed code in the email.  Please note: This step may take a considerable amount of time due to the fact that Nessus will download and update itself according to the HomeFeed subscription.  This only took about an hour on my system, your mileage may vary depending on Internet connectivity speeds.

Now that the Nessus service is installed, registered and updated, it’s time to test the installation.  Open a web browser and go to https://your-ids-ip-address:8834 .  If you are running Firefox and are using Noscript, AdblockPlus or Flashblock, you will need to add exceptions for Javascript and Flash for the IDS IP.  This is required as the Nessus UI relies entirely on Javascript and Flash.

Now that you have Nessus installed, it is highly recommended to take a read through the Nessus User’s Guide: http://cgi.tenable.com/nessus_4.4_user_guide.pdf While Nessus is a vulnerability scanner, some of the tests it performs can cause unpredictable results. It is recommended to set up a “safe” scan that performs basic testing and then set up a “full” scan for aggressive testing.

How to read the scan results:

Once you have made it through the User’s Guide and have performed your first scan, you can download or view the report.  The report is listed according to IP address, then service name, then vulnerability. Each vulnerability will include the service name, port, protocol, related CVE information (links to the CVE database for more information), as well as common fixes for the vulnerability.

I recommend taking a look at the vulnerability list in this order:

1. Externally accessible services: A vulnerability in Apache that listens to the outside world threatens your internal network.  Address this first!
2. Internally accessible services on the same server as external services:  Should the external service be compromised, internal services could be used to further compromise the network.
3. Internally accessible services: A service listening internally may not pose much of a threat, but may be a possible point of compromise should another host get infected.  ( A common example is a weakness in older versions of Samba that would allow for remote code execution.)

Generally speaking, it is a good idea to keep up to date with all service packs, updates and patches as this will prevent any known exploits from turning into full-blown worms.  Remember, it only takes one vulnerability to get compromised.

Final thoughts:

This has definitely been quite a project. I have learned a whole lot about network security in the course of my GCIA training and in building this project. I honestly think that building an IDS device from scratch is a great way to get acquainted with network security and how to perform vulnerability assessments.  Using Snort Report to analyze suspicious traffic and incoming threats and using Nessus to identify vulnerabilities in your system will help your home network stay secure against the ever evolving threats going around the Internet.

Always remember that security is no use if the warnings go unheeded.  While you don’t have to turn into a complete security nut, make it a good habit to take a look at Snort Report once a week at least.  Personally, I record the number of events logged and if it changes, I then investigate further however I haven’t picked up any incidents in the last month so for me it’s a pretty easy check.  If you find yourself with tons of IRC events and you don’t use IRC, it’s very possible that you have an active trojan on your hands and may warrant further investigation.

I hope you had fun and learned a lot from this project. I had a lot of fun building it and working out the kinks to make it all work together.  If you have any comments or questions, please leave me a comment and I’ll do my best to answer.

FIRESTORM_v1

In an earlier article, I demonstrated how you can build a passive monitoring device for an Ethernet network as the first part to a three part project to build a home IDS device.  In this article, the second in the series, I will describe how to set up the networking for an IDS using the passive tap that I built earlier.This setup will involve using a technique called bonding to take two physical interfaces and bond them together, creating a logical interface that we can use for Snort.  This article will also explain where is the best location to place the tap and what you can expect to see once the networking is set up using common Linux utilities like tcpdump.

Requirements

• A Passive Tap as mentioned in “Build a Passive Ethernet Tap” or similar device.
• Three network cards or a single network card with  three interfaces.
• A new installation of Ubuntu Server. (I am using Ubuntu Server 10.04LTS).
• Beer. (Always)

The requirements for this project aren’t that extensive and chances are you have most if not all the equipment you need in your parts bin. The most significant item in this list is the three network cards.  If you followed the steps in my first article in this series, you already have a machine with two or three network cards in it so you’re pretty much there. If not, then go ahead and get three network cards in your Ubuntu server and ensure that all three cards re properly recognized by the system even if there’s no IP address. for them.

The first two network cards will be combined together to form the monitoring interface while the third card will be for our management interface.  The management interface will be assigned an IP address and will be how we acccess the server’s commandline (via SSH), and the scanning and reporting tools we will install in Part 3.

Getting things set up

With the proper hardware in hand, we can now set about performing the configuration necessary to getting our interfaces configured properly. In the code below, you can see the interfaces (eth0, eth1 and eth2) and that eth0 has been configured with an IP address.  If you haven’t configured yours with an IP address, this will be covered while we perform the configuration.

matt@ids-01:~$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:18:f3:18:1c:25 
 inet addr:192.168.0.222  Bcast:192.168.0.255  Mask:255.255.255.0
 inet6 addr: fe80::218:f3ff:fe18:1c25/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:45458 errors:0 dropped:0 overruns:0 frame:0
 TX packets:23861 errors:0 dropped:0 overruns:0 carrier:2
 collisions:0 txqueuelen:1000
 RX bytes:55984695 (55.9 MB)  TX bytes:2326303 (2.3 MB)

eth1      Link encap:Ethernet  HWaddr 00:e0:b6:00:a2:06 
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:11505094 errors:2 dropped:0 overruns:0 frame:2
 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:3057886364 (3.0 GB)  TX bytes:218 (218.0 B)

eth2      Link encap:Ethernet  HWaddr 00:e0:b6:00:a2:06 
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:8061127 errors:1 dropped:0 overruns:0 frame:1
 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:1434430796 (1.4 GB)  TX bytes:250 (250.0 B)

lo        Link encap:Local Loopback 
 inet addr:127.0.0.1  Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:48 errors:0 dropped:0 overruns:0 frame:0
 TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:3948 (3.9 KB)  TX bytes:3948 (3.9 KB)

In this output, you can see eth0 is my management interface as it has been assigned an IP, eth1 and eth2 are both going to become a new interface called bond0.  When we set up Snort, we will use bond0 as our monitoring interface so that way we can take advantage of Snort’s stateful analysis and because it will be critical for any network analysis to hear both sides of the conversation on the passive tap.

In order to set up bonding, we will need to install the ifenslave package.  As root, run the below command:

# apt-get install ifenslave

Once apt-get completes, let’s check a few things.  First, let’s take a look at /etc/modprobe.d/aliases.conf.  Make sure that the two lines below appear in the file:

alias bond0 bonding
options mode=0 miimon=100 downdelay=200 updelay=200

If you will be making more than one bonding interface, you will need to add another alias line to coincide with the bond interfaces you wish to add (bond1, bond2, etc..) and you will need to add max_bonds=X to the end of the options line. Set X to the maximum number of bonding interfaces you will be using.

Now this is where things get interesting.  In order to test this out, we will bond the interfaces using the command below:

# ifenslave bond0 eth1 eth2

It does not matter which order the two eth interfaces appear, however bond0 must come first.  This command tells the Linux kernel to take eth1 and eth2 and pair them together into a single interface (bond0).  Now that we have done that, ifconfig -a will present a new interface:

root@ids-01:~# ifconfig -a
bond0     Link encap:Ethernet  HWaddr 00:e0:b6:00:a2:06 
 inet6 addr: fe80::2e0:b6ff:fe00:a206/64 Scope:Link
 UP BROADCAST RUNNING PROMISC MASTER MULTICAST  MTU:1500  Metric:1
 RX packets:19568527 errors:3 dropped:0 overruns:0 frame:3
 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:198240524 (198.2 MB)  TX bytes:468 (468.0 B)

eth0      Link encap:Ethernet  HWaddr 00:18:f3:18:1c:25 
 inet addr:192.168.0.222  Bcast:192.168.0.255  Mask:255.255.255.0
 inet6 addr: fe80::218:f3ff:fe18:1c25/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:45907 errors:0 dropped:0 overruns:0 frame:0
 TX packets:24117 errors:0 dropped:0 overruns:0 carrier:2
 collisions:0 txqueuelen:1000
 RX bytes:56024505 (56.0 MB)  TX bytes:2411029 (2.4 MB)

eth1      Link encap:Ethernet  HWaddr 00:e0:b6:00:a2:06 
 UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
 RX packets:11506043 errors:2 dropped:0 overruns:0 frame:2
 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:3058301702 (3.0 GB)  TX bytes:218 (218.0 B)

eth2      Link encap:Ethernet  HWaddr 00:e0:b6:00:a2:06 
 UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
 RX packets:8062484 errors:1 dropped:0 overruns:0 frame:1
 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:1434906118 (1.4 GB)  TX bytes:250 (250.0 B)

lo        Link encap:Local Loopback 
 inet addr:127.0.0.1  Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:48 errors:0 dropped:0 overruns:0 frame:0
 TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:3948 (3.9 KB)  TX bytes:3948 (3.9 KB)

Now that we have the bonding interface up, we need to write the configuration in /etc/networking/interfaces so that they will be brought up at boot time.  After struggling with this for a few moments, I finally found out the proper rules needed in order to do this:

1. You have to define your bonding interface first.
2. You must use an “up” statement to specify how to bring up the interfaces. We will be using the parameter promisc to ensure that the interfaces are ready for when we install Snort.
3. We must use bonding-specific statements to specify how the bonding interface will be created and for each interface’s role in the bonding configuration.

Edit /etc/networking/interfaces and remove the existing information.  Add the below lines, but be sure to add the proper IP addressing information for your management interface.

# The primary network interface
auto eth0
iface eth0 inet static
 address 172.20.1.253
 netmask 255.255.255.0
 broadcast 172.20.1.255
 gateway 172.20.1.250

auto bond0
iface bond0 inet manual
 bond-slaves none
 bond-mode 0
 bond-miimon 100
 up ifconfig bond0 promisc up

auto eth1
iface eth1 inet manual
 up ifconfig eth1 promisc up
 bond-master bond0
 bond-primary eth1 eth2

auto eth2
iface eth2 inet manual
 up ifconfig eth2 promisc up
 bond-master bond0
 bond-primary eth1 eth2

In the above configuration, the up parameter tells the network scripts to bring up the selected interface up with the promiscuous mode enabled so we can prepare the interfaces at boot time for  listening to network traffic. The bond-master and bond-primary parameters indicate which bonding interface the physical interface should be added to.  Granted for one bond interface it would appear faster to just single keywords however if you decide to set up multiple bonded interfaces, the keywords would lose meaning quickly.

When all is said and configured, reboot the computer.  When the computer comes back up, check ifconfig -a and see if you see something like the below.

root@ids-01:~# ifconfig -a
bond0     Link encap:Ethernet  HWaddr 00:e0:b6:00:a2:06 
 inet6 addr: fe80::2e0:b6ff:fe00:a206/64 Scope:Link
 UP BROADCAST RUNNING PROMISC MASTER MULTICAST  MTU:1500  Metric:1
 RX packets:19570074 errors:3 dropped:0 overruns:0 frame:3
 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:198918392 (198.9 MB)  TX bytes:468 (468.0 B)

eth0      Link encap:Ethernet  HWaddr 00:18:f3:18:1c:25 
 inet addr:172.20.1.253  Bcast:192.168.0.255  Mask:255.255.255.0
 inet6 addr: fe80::218:f3ff:fe18:1c25/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:46106 errors:0 dropped:0 overruns:0 frame:0
 TX packets:24224 errors:0 dropped:0 overruns:0 carrier:2
 collisions:0 txqueuelen:1000
 RX bytes:56042559 (56.0 MB)  TX bytes:2427777 (2.4 MB)

eth1      Link encap:Ethernet  HWaddr 00:e0:b6:00:a2:06 
 UP BROADCAST RUNNING PROMISC SLAVE MULTICAST  MTU:1500  Metric:1
 RX packets:11506719 errors:2 dropped:0 overruns:0 frame:2
 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:3058600599 (3.0 GB)  TX bytes:218 (218.0 B)

eth2      Link encap:Ethernet  HWaddr 00:e0:b6:00:a2:06 
 UP BROADCAST RUNNING PROMISC SLAVE MULTICAST  MTU:1500  Metric:1
 RX packets:8063355 errors:1 dropped:0 overruns:0 frame:1
 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:1435285089 (1.4 GB)  TX bytes:250 (250.0 B)

lo        Link encap:Local Loopback 
 inet addr:127.0.0.1  Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:48 errors:0 dropped:0 overruns:0 frame:0
 TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:3948 (3.9 KB)  TX bytes:3948 (3.9 KB)

Now to install it…

In order to install this machine where it will be most effective in your network, there are some things to consider:

• What kind of Internet access do you have? (Cable, DSL, FiOS, etc…..)
• Does your ISP require running a program on your router to connect? (like PPPoE clients, RASPPPoE, others..)
• What is considered the “edge” of your network?
• Where is the location where the IDS would have most visibility to the network traffic generated by your computers either wired or wireless?

In most corporate networks, there is a single switch that handles all the traffic for a network. This makes things a loss less complex as the network traffic is in one place however in most homes, this is simply not the case.  At least in my network, there’s at least four switches between the router (my edge) and the innermost device (my Wireless Access Point). Since I wanted all the traffic monitored, I elected to connect the passive tap between my router and the first switch.  Any internet activity generated by any device on the network will be monitored by the IDS and if malicious will generate an alert.  If you have only a couple of PCs that are wireless but have several embedded devices like gaming consoles or media streaming boxes (not media center PCs, more like Boxee boxes and the like) you may want to move the passive tap between your wireless access point and the switch connecting the embedded devices as they are a lot less likely to generate malicious traffic.  Your configuration may be different, but when in doubt, installing the passive tap and your soon-to-be IDS between your edge router and the rest of your network is a safe bet.

What’s Next?

We’ve covered how to build a passive tap. We just covered how to configure bonding for the passive tap.  In the final article in the series, we will discuss how to install Snort and make this machine into a full blown IDS device.

Happy Hacking!

FIRESTORM_v1

One of the things that the GCIA study has taught me is that being able to monitor the network your computer is on is a critical necessity to maintaining a secure network. Corporate environments can set up IDS devices to monitor traffic however monitoring doesn’t work unless you have proper connectivity to what you want to monitor. Unfortunately, most of us don’t have central wiring in our house and expensive managed switches that can set up span sessions with which to monitor traffic in transit.  In this HOWTO, I will cover how to build your own monitoring connection that you can use on your own network to monitor traffic without breaking the bank. This article is first in a three part series on how to build your own home IDS for monitoring your network traffic. Look for the other two sections soon!

A little bit more info first…

In the early days of affordable Ethernet networking, devices called hubs (or repeaters) were used to bring the signals together from each workstation in order to allow the workstations to communicate with each other. When a packet was sent to the hub, the hub repeated the packet across all ports on the device and all other workstations would receive it, even if it was not destined for that particular workstation.  The hubs gave way to switches as networking technology became cheaper and faster. Unfortunately, the switches also changed the old way of signal transmission. When a workstation sends a packet to a switch, it is sent from the sender’s switch port  and arrives at  the switch port of the workstation that the packet is destined to. It does not get sent to other workstations’ switch ports unlike the hub’s transmission method.  Because of the need for network monitoring, more advanced switches started offering monitor ports (Cisco calls them span sessions) that are used to forward all traffic that goes through a switch out of this specifically configured port.  This port would then be connected to the monitoring device and would allow the monitoring device to “listen” to all packets that traversed the switch.

The good thing is that most if not all managed switches support a monitor port however the bad thing is that a managed switch is way outside the pocketbook of most home network users.

But why not use a hub?

A hub would allow us to listen in on network traffic however a hub would degrade your network’s performance thanks to it’s lack of proper high speed flow control and its susceptability to collisions.  In my testing, I used a 100baseT hub between my firewall and my network and found that my previously rock solid network connection had dropped well below speed and would barely support YouTube streaming, much less Netflix.  Instead of using a hub and risking continued degradation, I decided to research another solution.

So, what’s the solution and how do I use it?

The solution is the Passive Tap.  This device sits between a unmanaged switch and a computer or router and allows a monitor device to listen in on the network connection between a computer and switch.  The word passive in this instance means that there is no way to detect the device’s presence. It does not have a MAC address, it does not repeat. For all intensive purposes, the tap does not exist.

In the image above, we have connected the Passive Tap between a network switch and a monitored host in order to monitor traffic between the host and other machines on the network (in this case the Server).  This would be an ideal setup for monitoring traffic generated by the monitored host and the rest of the network with the focus being on the monitored host. In this configuration, the monitor device would pick up all traffic destined to or originating from the host and any broadcast traffic generated by the network.

This configuration is a bit different than the first image however the scope of the monitor device’s visibility has changed. Instead of just monitoring the Monitored Host, this configuration allows the monitor device to monitor any Internet traffic that passes between any host on the switch and the firewall. If there were additional devices connected to the switch (other desktops, an Xbox, a Wifi Access point, etc..) their communication with the Internet would also be monitored.  The only communication that would not get monitored would be communication between the devices plugged into the switch (for example the Monitored Host and a Wifi Accesspoint, etc.)

Parts List

In order to build a passive tap, you will need the following items.  The parts themselves cost me about $20 at a computer store which is a lot better than the $200 that some eBay sellers want.

• A cat-5 patch cord
• A surface mount biscuit jack / modular mounting box. (See picture below)
• Two CAT5 keystones (they don’t have to be green/red like mine)
• Screwdriver
• Wire cutters/blade
• A M110 punch down tool (If you have one, it makes the installation easier)
• A monitoring computer with two network interfaces and Wireshark installed (windows) or tcpdump(linux)
• A test computer (or device) with one network interface
• A network switch.
• Beer (optional)

Parts

Here’s an image of the parts. The biscuit jack on the left, the two keystones are in the center and the patch cord is on the right.

We’ll start off by first taking a look at the keystones up close.

Keystones

These keystone jacks are wired up and marked in such a way that all you need to do to wire it up properly is to follow the color code. A closer inspection will reveal that there are small numbers in between the symbols for the wire positions. In this page on twisted pair wiring, you can see that of the four pairs in a Cat-5 10/100 cable, only pairs 2 (white/orange) and 3(white/green) are used.  In order to properly receive both sides of the conversation on the wire, we will need to “tap” into both pairs and route them to the proper pins on the two keystones to each jack’s Pair 2 (receive pair) so that the data being sent can arrive at the NIC of our monitoring device.

If you scroll down to the section labeled “568A and 568 B Color Schemes”, you will see that the receive pair is on pins 3 and 6 of the diagram jacks.  Our keystones are similarly labelled and when we are done, we will have one pair of the Cat-5 patch cable going to pins 3 and 6 of one jack, and the other pair of the Cat-5 patch cable going to the other jack.

Let’s get started.

First off, it is important to understand that you must be able to do this WITHOUT NICKING OR CUTTING THE WIRES.  A cut or nick could result in either your tap not working properly or the tap getting all the data but your connected host doesn’t or any one of a whole handful of issues.  Thankfully, Cat-5 patch cords are not very expensive, but it still sucks to put a project on hold because a slip of the knife.

To start, lay out the patch cord and decide on where you want the tap.  Since the hosts are closer to my monitor machine, I’ve decided to create a short end and a long end with the tap being more towards one end.  You may want to have the tap in the middle or very close to one end of your patch.  It electrically does not matter.

Strip back about two to three inches of jacket so that you have something like below.

Stripped Wires

Mount the keystones in the surface mount box as shown below.

mounted keystones

Now that they are mounted, we will then need to take a look at which pair of pins we need to match the wires up to. Below is a better side-view pic of the green jack in detail.  Please note, your jacks may appear different, but all CAT5 keystone jacks that I have seen have both a color designation and a numeric designation. Be sure to pay attention to which is which and where you are placing your wires otherwise it may not work.

Wire/Pin designations

You can click on the picture for a larger more detailed image.  In the above image (using the top set of colors as a guide) we see that the orange/white hash is pin 3 and the solid orange is pin 6. The same goes for the red jack (not shown).  That being said, untwist the orange and green wires, and place them into their respective slots. Make sure that the solid wire goes with the solid pin and the hashed wire goes with the hashed pin. A reversal here will cause the monitor port not to receive data and could affect your host/switch.

Wires ready to crimp

In the above photo, you can see that the white/orange pair are lightly inserted into the wire channels.  If you don’t have the M100 punch tool, you can get away with using the wire caps that came with your keystones.  These caps will push down the wire and crimp it into place over a metal pin that connects the wire to the pin in the jack.  When you are done, you will have something akin to the below:

Tap ready to close

Also of note: To act as a strain relief, I have added tiewraps on the cable. This will serve to protect the cable from getting yanked out and damaged.  In this picture, you can also see the two white caps that have punched the wires down in place. Reassemble the jack and make sure to install the screw in the lid if your jack has one.

Completed Passive Ethernet Tap

Here’s the completed tap in all it’s glory!

Testing the Tap

In order to test the tap, we need at least two computers, one of which must have two network adapters.  The computer with one network adapter will be our “test host” and the other computer will be our monitoring host.  On the test host, I have assigned the IP address 10.0.0.2 and on the monitoring computer, I have assigned one interface (eth0) with the IP of 10.0.0.1.  The monitoring interface (eth1) will have no IP address assigned to it and will be for testing the tap.  Remember that as far as the test host is concerned, the tap is just a CAT-5 patch cable.

Before proceeding, mark the passive tap where the Ethernet cables come out as A and B.  This will be important as this test will also help us label which side of the conversation we are listening to.  One side will be considered “Network to Host” and the other will be considered “Host to Network”.  It is imperative that we get both sides of the conversation, each side represented by one of the two keystone jacks. While it might not be important now, later on when you use this tap for something else (like an IDS project), you will need to know which side of the conversation you are listening to.

To get your test rig set up, connect the long side (side A in my case) of the tap cable to the switch.  Connect the short side (side B in my case) to the test host.  Connect the ethernet interface on the monitoring machine to the switch, but leave the  unmonitored interface disconnected.  Keep in mind that on my monitoring machine, eth0 was the interface with the IP address, and eth3 was the interface that will be used for monitoring. I’m using Linux on my system, you may need to make adjustments where needed.

• On the monitoring host, ensure that you can ping the test host before hooking up the monitoring interface to the tap.
• On the monitoring host, open two terminal windows
• In the first window, start tcpdump using this command:  sudo tcpdump -i eth3 -nvs0 -c 10 ip[9]=1This translates to start tcpdump on eth3, no host resolution (-n), verbose mode (v), no snapshot length (s0), for a count of 10 packets (-c 10) and only on ICMP protocol (ip[9]=1).
• Attach the monitoring interface to one of the two keystones.  I picked the red jack.
• In the second window, ping the test host using the -c 5 parameter:  ping testmachine -c 5 The -c 5 tells ping to try 5 times.
• You should see the below text in your ping window:

$ ping  testmachine -c 5
PING testmachine (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=7.25 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.685 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.719 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.746 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.704 ms

• Your TCPDUMP window should show something like this:

21:48:59.093624 IP (tos 0x0, ttl 64, id 27270, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 1, length 64
21:49:00.088502 IP (tos 0x0, ttl 64, id 49871, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 2, length 64
21:49:01.087486 IP (tos 0x0, ttl 64, id 36772, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 3, length 64
21:49:02.086630 IP (tos 0x0, ttl 64, id 27025, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 4, length 64
21:49:03.085505 IP (tos 0x0, ttl 64, id 28037, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24899, seq 5, length 64

• Keep in mind that there are two packets associated with ping. One is an ICMP Echo Request and the other is an ICMP Echo Reply In this case I received the echo reply which means that the red jack is for “Host to Network” monitoring or B->A. If you got ICMP echo request, then your jack is A->B.
• Mark the jack as B->A and continue testing. At this point, we know that our tap at least hears half the conversation.
• Switch the monitor interface to the other jack (Mine is green) and rerun the ping.  Your ping should show the below just like before:

$ ping 10.0.0.2 -c 5
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=9.69 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.705 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.663 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.722 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.714 ms

• This time, however, the TCPDUMP output should have changed:

22:00:28.084339 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 1, length 64
22:00:29.077220 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 2, length 64
22:00:30.076215 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 3, length 64
22:00:31.075218 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 4, length 64
22:00:32.074214 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
 10.0.0.1 > 10.0.0.2: ICMP echo request, id 40269, seq 5, length 64

• Just like before, I received 5 packets however last time I got the ICMP echo reply, this time I got the ICMP echo request.  This means that the green jack is the A->B connector, that is Network to Host. Mark it as appropriate.

If you’re at this point, then you have demonstrated that the tap works.  It allows the test host to communicate with the network unimpeded, it also allows the monitoring of host to network and network to host data.  My passive tap looks like the one below:

Finished Passive Tap

Now what to do?

At this point, with a good passive tap in hand, you have a whole bunch of things you can do. You could:

1. Establish an IDS for your network (my original plan)
2. Monitor a host’s traffic exchange with the network/Internet.
3. Perform traffic reconstruction for analysis.
4. Monitor network communication between your Wireless access point and the rest of your network

Troubleshooting

Unfortunately, I can’t account for every situation however there may be some situations where the tcpdump test doesn’t exactly work as planned.  Here’s some common solutions if your tests don’t work quite right:

I can see the A->B traffic, but can’t see the B->A traffic. The ping window shows the host responds. (or)

I can see the B->A traffic but can’t see the A->B traffic. The ping window shows the host responds. (or)

I can not see any traffic, but the ping window shows the host responds.

Check your wires on the keystone and make sure the wire went down onto the metal pin. Sometimes when using the caps to crimp down the wires, one of the wires will shift at the last second.

I can see the ICMP Echo Request  on one port but I see nothing on the other. The ping window shows that the host does not respond.

Check to see that the wires didn’t rip apart or that they were not nicked in the construction process.

Last Thoughts

Even if you don’t plan on building a home IDS, having a passive tap in your toolbox is a good idea.  You never know when you will need to intercept and analyze traffic between two devices on a network. This device will allow you to do so with minimal effort and cost all while allowing the host to chatter away unimpeded by the monitoring.

Happy Hacking!

FIRESTORM_v1

Foreword

Please note that per Notch (the Minecraft developer), running the Multiplayer server is still in beta phase so expect it to crash, be buggy and generally not work.  That being said, I can personally tell you that Minecraft Server DOES work and except for a few minor gameplay glitches, the server works quite well. Please keep in mind that this is by no means an exhaustive article on all things Minecraft Server, nor is it written in stone (ba-dum-thish!) as the Minecraft Server application may change.  If it does, I will make changes to this article to keep it current.

I can tell you that having your own Minecraft server is awesome and that you will never go back to playing singleplayer as you won’t have to worry about files to migrate and that your world will continue to evolve even as you are not playing.  This being said, before you disconnect your Minecraft session, it is recommended to make sure that your minecraft player is somewhere safe, be it in your bunker or somewhere where baddies can’t get to you while you are away. Remember, just because you’re not logged in, doesn’t mean that the world stops.

System Requirements

The System Requirements for Minecraft Server have yet to be officially established however there are some guidelines that have turned up during my research into this topic.  The below is a guideline only and not an exhaustive set of requirements.  It’s perfectly fine if you don’t meet all of them however expect performance hits depending on how you use the server.

• Processor: At least a 1.5GHz single core chip, whichever architecture you desire.
• RAM:  At least 1.5GB FREE RAM. If you use the server for anything more than Minecraft, make sure you have at least 1.5GB free RAM at full utilization.
• Disk: At least a 20Gb disk, with swap space allocated. (Using the “Use Full Disk” and “Automatically Setup Partitions” options in the Ubuntu Setup will ensure you have enough swap.  Although the game isn’t that big, the save files and caching elements will be quite large so of course the more the merrier.
• Networking: 10/100 Ethernet is recommended.
• Video:  Doesn’t matter. We will be running Minecraft Server in a Screen session, so there’s no need for a fancyOMGWTFBBQ video card. Save that for the rig you will play Minecraft on.

Please note: In order to take advantage of Minecraft Server, you must purchase the game from Notch at www.minecraft.net and have a username and password. You will still need to use either the Minecraft Beta standalone application or the Minecraft Beta web-based application to access your server.

This is the basic setup of a good single person Minecraft server. While the possibility exists that you may be able to run multiple connected players on the specs above, if you are planning on hosting a lot of players, you may want to consider a beefer rig. My Minecraft server uses the below stats:

• Processor: Dual Core Intel Core 2 Duo 1.86GHz
• RAM:  3.5GB DDR-2
• Disk: 80GB SATA
• Networking: 10/100/1000 Ethernet (onboard)
• Video: whatever’s on the motherboard.

Getting Started

This HOWTO will already assume you’ve installed your core Ubuntu Server installation and have performed no additonal steps. Login with your user account that you created during setup and perform the following steps. While you can technically prepend “sudo” to each command, I find it faster and less frustrating to just “sudo bash” and type your password once.

• apt-get update
• apt-get install openssh-server
• apt-get install screen

This will install the OpenSSH server so you can remotely manage the server.  You will need a client like PuTTY (download from here) in order to access it.  This will also install Screen which will contain the Minecraft server process.  If you don’t install screen, you will not be able to exit the SSH session without the Minecraft server being killed off.

Now for the fun part.  You will need to install Java in order to start the Minecraft server but Minecraft server will require the use of only the Sun JVM. I tried with the other JVM and it did not work at all.

• apt-get install sun-java6-bin sun-java6-jdk sun-java6-jre

In order to ensure that the java environment is correct, run the command “java -version” and make sure it matches the below text.
# java -version
java version “1.6.0_22″
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Server VM (build 17.1-b03, mixed mode)

If it shows something else, you will need to do the following:

• update-java-alternatives -l

This will list off all the various Java VMs that are installed.
# update-java-alternatives -l
java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk
java-6-sun 63 /usr/lib/jvm/java-6-sun
You will need to set the proper Java VM to use via the below syntax:

• update-java-alternatives -s java-6-sun

Now, run “java -version” again and it should show the same version information as above. If it does, you’re good to go otherwise check your error messages.

Please note that the rest of these commands are run without root privileges. NEVER EVER RUN MINECRAFT SERVER AS ROOT!

Installing Minecraft Server

If you’re this far, then you’ve got the Java VM set properly and your server is all set for Minecraft Server.  You will need to download the minecraft_server.jar to your computer then use scp to put it on the server. You can download a Windows SCP client called WinSCP from this site. Copy it into your non-root user’s home directory, in my case I’m using “mcserver”.

To start the server, you will need to use the following command:

• java -Xmx1024m -Xms1024m -jar minecraft_server.jar nogui

You will see a lot of text scroll past the screen and you will see it generate a new world via the console messages. Once it settles down, you can then type “help” for a list of commands.

Since we just fired it up, let’s go ahead and stop it. Type in the command “save-all” which forces the server to save the generated map, then “stop” to shut the server down.

Stopping and Starting the server

To start the server, first off make sure you are in a screen session by typing “screen -list” like below:

mcserver@mcserver:~$ screen -list
There is a screen on:
 2434.tty1.mcserver        (01/09/2011 12:58:57 PM)        (Attached)
1 Socket in /var/run/screen/S-mcserver.

This indicates that you are in a screen session.  If you see “(no screens running)” then just type “screen” to start one.

Once in the screen session, type in the command shown below.  This is the exact same command as when we installed it, but this time we’re not going to shut it down.

• java -Xmx1024m -Xms1024m -jar minecraft_server.jar nogui

To disconnect from the screen session, hit Ctrl-A and then the D key, this will drop you back to the shell prompt where you can then type “exit” to logout. The Minecraft Server will continue to run.

To stop the server that is already in a screen session, login to the server using SSH and the non-root user.  To reconnect with the screen session, type in “screen -r”.  You will be reconnected to the server and can then perform the following commands:

• say Server is going down

This lets any players know that the server’s going down.

• save-all

This tells the server to save the entire world.

• stop

This tells the Minecraft Server to shutdown and exit. You will be dropped to a console prompt from there you can shutdown the server or do whatever you need to do.

Other useful commands in MC Server

Console commands:
 help  or  ?               shows this message
 kick <player>             removes a player from the server
 ban <player>              bans a player from the server
 pardon <player>           pardons a banned player so that they can connect again
 ban-ip <ip>               bans an IP address from the server
 pardon-ip <ip>            pardons a banned IP address so that they can connect again
 op <player>               turns a player into an op
 deop <player>             removes op status from a player
 tp <player1> <player2>    moves one player to the same location as another player
 give <player> <id> [num]  gives a player a resource
 tell <player> <message>   sends a private message to a player
 stop                      gracefully stops the server
 save-all                  forces a server-wide level save
 save-off                  disables terrain saving (useful for backup scripts)
 save-on                   re-enables terrain saving
 list                      lists all currently connected players
 say <message>             broadcasts a message to all players

Quick and Easy Start script

Below is a very simple script I wrote because I kept forgetting all the java commands.  In order to use it, save both lines below as a file (like “startmcserver.sh”) and then “chmod +x startmcserver.sh” so that way you can start the server simply by running “./startmcserver.sh”

#!/bin/bash
java -Xmx1024m -Xms1024m -jar minecraft_server.jar nogui

Remember to keep both lines intact.  It’s essentially the same Java command, but it’s easier to type.

Have fun and Happy minecrafting!

FIRESTORM_v1

The reason I haven’t written any more about my fun with the Dockstar was that due to an unfortunate set of circumstances I was left with a bricked dockstar. (read: I did something stupid.)  After performing a lot of research and thanks to a bunch of people over at the PlugApps.com Forum site who helped me, I was able to get it running.  Read more for a complete list of what you will need including how to build an adapter and where to get the needed JTAG kit.

Before we begin

This document demonstrates how to recover your Dockstar and upload a custom bootloader to it using a JTAG cable.  JTAG is used for low-level in-circuit debugging of embedded applications and is very hardware specific. If you are familiar with working with Linksys routers and uploading custom firmware to them, you have heard of the term bricking and you have more than likely heard of something called JTAG that is used to recover it.

Because of the nature of JTAG and the fact that manufacturers don’t typically like us having access to the JTAG port, these ports are often hidden in many different locations, usually unmarked or unpopulated headers, or other odd locations and is the way that the manufacturer loads the firmware for the very first time on to a new device.

By using JTAG, we can place the hardware into a “debug” mode where we can manipulate the microprocessor’s core functionality.  We can also send instructions to it, monitor responses from it, or even pause the chip, leaving it in a state of suspended animation until we issue the command to start it up again or reset the device.

In this particular howto, we will cover how to use the debug mode of the Marvell chip in the Dockstar to upload a new boot loader in order to rewrite the bootloader to the onboard Flash which will result in a working, new Dockstar.  Please note that if you have NOT bricked your dockstar, there is no need to perform the steps in this howto.  This is only for bricked dockstars that have been verified with a serial adapter to be dead. (A dead dockstar will produce NO serial output and the front panel LED will not light up when power is applied.)

Legal Disclaimer

By performing the steps outlined in this document, you agree not to hold firestorm_v1, YourWarrantyIsVoid.com or any other linked sites, forums, companies, liable if you really screw something up.  You can also not hold any of these entities responsible for data loss, physical damage, emotional trauma, spousal abuse or any other act of whatever god(s) that you may have happen to you.  In short, Read twice, type once, hit enter and don’t screw up.  If you’re at this point, then you’ve already come to terms that your dockstar may be unrecoverable already so deal with it.

Parts List

In order to perform this recovery, you will need the following items:

1. The dead seagate dockstar and power supply.
2. A handful of 2.0mm female connectors or one 2.0mm female connector with at least 10 pins (5 pins in 2 rows)
3. A 10 pin header that matches your PCB 2.5mm spacing  (again, 5 pin, 2 row)
4. A bit of holed PCB board 2.5mm pin spacing. (Radio Shack is good for this kind of stuff)
5. A CA-42 cable with the appropriate pins as outlined in my previous Dockstar post.
6. A handful of extra breadboard jumpers.
7. Superglue
8. A Windows PC (2k or XP, untested on vista/7 although plugapps forums says it should work.) with a Parallel Port
9. Whatever provisions needed for the CA-42 cable to work properly.  (I have to use a linux box to SSH to, you can do the same or if your Windows computer works with the CA42 cable, you can use that as well.  You don’t need two PCs for this operation.)
10. A TAIO Buffered/Unbuffered “Universal” Parallel Port JTAG module kit (Here’s the eBay seller where I got mine, ~$21.00 out the door) and a Parallel cable extension (Male to Female) so that you can reach it without having to get behind your PC. For my setup, I used an old iomega Parallel/SCSI Zip drive cable. I also recommend the ebay link as this is the seller that I purchased mine from and it comes with a lot of extra jumpers that are very useful for this project.
11. A USB A to USB mini B cable (for powering up the JTAG adapter).
12. Glue gun with extra gluesticks
13. Heatshrink tubing and lighter/heat source
14. In lieu of building/reinforcing your JTAG cable, you can use a laptop hard drive adapter (3.5 IDE to 2.5IDE) if you’re in a pinch and just need to get it running.

In addition to the above items, you will need the following software applications:

1. Kragorn’s copy of dockstar.cfg – Mirrored Here
2. A copy of OpenOCD – Mirrored Here
3. A copy of the Jeff Doozan’s custom USB-boot capable u-boot (Recommended!) (Mirrored Here) or a copy of another factory or custom uBoot.  If you want to compile your own, there’s a great write-up here: http://jeff.doozan.com/debian/uboot/
4. A copy of PuTTY for Serial/Telnet communication.  You can download it here.

Getting Started

This howto will be divided up into several sections:

Section I:Building an adapter cable – This section will cover how to build the required cable from spare 2MM connectors or if you already have the proper cable, this will describe how to reinforce it for repeated use using heatshrink tubing. I call it a smokestack cable because it resembles a small smokestack sticking out of the Dockstar’s mainboard.

Section II: Wiring it all up – This will cover the Dockstar’s pinout, the TAIO parallel port pinout, the serial port pinout and how to wire it up together.

Section III: Performing the JTAG recovery – This is where the actual recovery process takes place now that we have everything wired up.

Section IV: Notes and credits – As much as I’d like to say this was all my doing, truth is it’s not.  I couldn’t have done it without some great people from the PlugApps forums.

Each section will have lots of pictures that you can use as a guide to make sure you’re making the right connections.

BIG FAT OBNOXIOUS WARNING!!!

Although there are as many JTAG adapters on the market as there fish in the sea, I can not cover each and every device’s unique configuration options. Generally the JTAG port is a universal standard but many vendors implement their own standard, have other standards that they choose to leave out and their pin configurations may not match what is given here.  This article is based on my experience performing the JTAG restoration of a dockstar I broke using the equipment and the software outlined above.  If you are new to JTAG, I recommend using the versions and adapter board listed as other devices/software may not work in the same way.  When in doubt, go with what you know!

Section I: Building out the JTAG adapter cable.

The dockstar’s JTAG port uses a 2.0 mm spacing and while it’s good for tight spaces, isn’t exactly ideal when dealing with breadboard jumpers as most breadboards have a 2.5mm spacing and the jumpers have connectors to match.  In this instance I felt that since I was going to be working on actually developing code for the Dockstar, the inevitable would happen and I would end up bricking it through a random error (namely user failure) and would need a quick and reliable connector that I could use to quickly connect and disconnect the JTAG port as needed during restore and development.

I checked out EPO and managed to find several 2.0mm spaced connectors however these were in groups of three and while they would work, would require significant effort to harden the connectors to something that could stand the test of repeated connections and disconnections. So let’s get started.

Checking the connectors to make sure they would work

This is a shot of the connectors standing out of the Dockstar.  Since I had four connectors with 3 pins each, this means that I had two pins that hung over the connector block on the Dockstar.  Since these two wires were not needed, I cut them and removed the metal connector from inside the plastic, leaving 10 wires for 10 pins of the dockstar’s JTAG port.  We’ll deal with the two vacant holes later.

Little known fact: The pin spacing on the Dockstar’s JTAG port is identical to that of a laptop hard drive (which is why this part of the process is optional.)  In a pinch, you can use a laptop IDE adapter similar to this one (in fact I own several exactly like this).  If you decide to use a laptop IDE adapter, use the part of the adapter opposite the power connector.

Since the goal is to harden the four little connectors to one single connector, I used a dead laptop hard drive and superglued the four connectors together. USE THE SUPERGLUE SPARINGLY!! You do not want to superglue your connectors to a hard drive so only put a tiny amount. It also helps to put a dab of glue on one connector, then put the connectors together as you’re pushing them onto the laptop HD pins.  Make sure they are completely seated so they will be even as possible.  If you see the pins of the laptop HD, you’re not down far enough.

Glued 2.0MM connectors curing on a laptop HD.

Once you get all four connectors onto the laptop HD and properly aligned, let it cure for at least an hour.  This will ensure that the superglue bonds correctly and the connector doesn’t fall apart later.

Glued connectors after the superglue set.

Now that the superglue has set, check that it still fits in the Dockstar. On the connectors used here, my wires were quite long. To alleviate yet another mass of cable snakes on my desk, I cut them down to about three inches, which should be big enough to handle, but small enough to not get in the way. You can cut your wires to any length desired.

In order to solder to the 10 pin header and ensure that the wires would not seperate from use, I chose to use a small piece of PCB as shown below.

Header and Breadboard

Keep in mind that if you cut your own, you’re soldering 10 wires into a 10 pin header, so you will need a 20 hole piece of PCB (5 holes by 4 holes).  The idea here is that the wires will come in on the component side of the PCB and wrap around it then go further down to the 2.0mm connector we just glued together.   Go ahead and solder the header into the center two rows of the PCB as shown below(Leave one row of 5 on each side of the header).

Header and PCB soldered together

Strip off a 1/8 inch off of each wire on one side of the glued connector and solder to the PCB. Keep your pinout the same and do not cross the wires.   Below, you can see that the first half of the PCB and the wires has been soldered.

Header with one side soldered.

Now comes the fun part.  Trying to solder the other side of the PCB without burning yourself or the other wires and without creating unnecessary solder bridges to other pins.  Below is a shot of my connector, partially soldered.

Second set of wires to solder

Protip: If you don’t already have a pair, I highly recommend you get a pair of Helping Hands for soldering like this. Available at Radio Shack and many other electronics outlets.  Below is a picture of the completely soldered PCB.

Completed PCB soldering

Now that the PCB is soldered, go ahead and check your wiring!  Don’t do any pin swaps, make sure that pin 1 on the 2.0mm connector is pin 1 on the header, pin2 on the 2.0mm connector is pin 2 on the header and so on. Also make sure that you didn’t bridge between pins on the PCB. Before you slip on the shrinkwrap, we’re going to reinforce the body of the adapter.  Get your hot glue gun ready and shoot a large bead of glue down the length of the wire. Once that is done, shoot some more hotglue around the connector to reinforce the wires coming out of the connector. Below is a picture of the hotglue process.

Wires hotglued together and header is wrapped in hotglue.

The hotglue on the wire-side of the plug will make sure that the wires don’t wiggle around inside the heatshrink tube and fail later on.  After you’ve properly applied the hot glue, put the tip of the hotglue gun over the two holes that we vacated earlier.  Keep consistent pressure on the hotglue gun and press the trigger.  This will inject hot glue into the holes left behind when the excess pins were extracted and ensure that the connector is “keyed” and will prevent a one-off connection (and prevent further headache).  This is what the hotglue injected connector looks like.

Key-glued header.

Take one moment and check your cable one last time.  Make sure that the pins are wired one to one.  Once you’re ready, get the heatshrink tube and cut it to a little bit less than the length of your adapter.  Below, you can see the heatshrink and adapter lengths I used. (This image was taken before the hot glue was applied.)

Header adapter and shrinkwrap.

Slip over the heatshrink wrap over the connector (it may not fit over the PCB) and leave just a little bit so that it overlaps the 2MM connector end.  Apply even heat to the 2MM connector end first so that it will shrink and hold the heatshrink wrap in place as you apply even heat to the rest of the connector. When completed, you should have a connector resembling the below image.

Heatshrink wrapped adapter.

Now take the hotglue gun and fill in the gap between the heatshrink wrap and the bottom of the PCB. If your gluegun has a fine tip, also shoot some hot glue into the open end of the shrinkwrap.  This will further harden the connector and ensure that it doesn’t flex and damage the connections.  You may have something looking like the below image.

Header Top with glue bead.

For a final touch, wrap and distribute hot glue around the wiring from a little bit over the heatshrink wrap all the way to the black part of the header wiring.  It’s ok to use a large amount of glue as this will make sure that the connector is properly protected.  As a last step, connect it to the Dockstar and make sure it fits.  Once finished, you should have something resembling the below image.

Completed Smokestack adapter on Dockstar.

Now, you have a completed Smokestack adapter.  You can use this for any device that has 2.0MM connector pitch and for any purpose.  Since the header on top is a 1 to 1 representation of the connector on bottom, you can use this anywhere where you need to use breadboard connectors for a temporary connection to these headers.

Section 2: Wiring it all up.

With a completed smokestack adapter, now you can wire it all up together  but before we begin, it is highly recommended to solder in a ground pin.  This ground pin will be used to ensure that the ground used by the JTAG adapter’s reference ground will be the same as the ground used by the Dockstar.  While it may not be required, it is recommended as a difference in ground may end up corrupting data being sent and received as part of the update.  To do that, we can use any of the ground planes, shields or open spots on the PCB.  I preferred to use one of the three USB shields as the shield’s purpose is the same as the GND connection that we are trying to establish.  For this, we’ll use a jumper pin with no plastic on it.  Start off by applying a small bead of solder to the USB shield as shown below.

Dockstar USB shield pin prepped for header pin.

Apply the heat from the soldering iron to the bead again and drop in the jumper pin.  Remove heat and do not touch the jumper pin until the connector has cooled.  Do not apply heat for a long period of time otherwise you may damage the USB port itself.  Below is the completed ground pin installation:

Dockstar Ground pin installed.

Now, we have a properly installed Ground pin that is easy to connect and remove and we also have our smokestack JTAG adapter.  At this point, we can start wiring up the JTAG connector up and prepare for recovery of our dead dockstar.  If you went with my suggestion and ordered the TIAO Parallel JTAG adapter, you should have received the following items.  JTAG board (blue with DB25 connector), Short jumpers (left of  JTAG board) and Long Jumpers (above board) as shown in the picture below.

TIAO Parallel JTAG kit.

The below image is the entire wiring diagram for the Dockstar JTAG adapter.  As long as you keep pin 1 on the dockstar as pin 1 on the smokestack adapter, you should have no problems with the connection.  As mrbill and Klingon and several others pointed out in the PlugApps forums, the nSRST line (orange) and the DINT(purple) leads are both not connected.  Pin 1 on the Dockstar/Smokestack are also left unconnected as we will use the Dockstar’s power supply to power the board while it is connected to the JTAG adapter.  Additionally, it is crucial to plug the USB cable into the JTAG adapter and into a PC to power the onboard buffer chip.  Without the USB cable connected, the adapter will not function.  There is also an LED on the JTAG adapter that will light when the device has sufficient power. Click on the below image to get a much larger image.

Dockstar/TAIO JTAG connection table.

The Dockstar layout diagram on the right hand side of the image is bundled together to provide a reference.  Pin 1 of the JTAG port is on the LED side of the jumper and is towards the center of the board and is designated by a black dot in the image and a white triangle on the dockstar board itself as shown below.  The picture of the Dockstar is rotated 90 degrees clockwise to the layout diagram in the image above.

Dockstar JTAG port showing pin 1

You can use the following images as a reference that your dockstar is connected properly.  The below image is a picture of my CA-42 adapter’s serial header as discussed in the serial port post. Also, since the serial port post discussed soldering to the header, if you haven’t done so already, remove the existing serial port wires so that your smokestack adapter will fit.  In the image below, the three jumpers coming off of the pins are colored as they would be if you had just cut and stripped back the CA-42′s cable. Remember that your CA-42 cable may be different!

Serial Port jumpers from CA42 USB cable.

The below image shows the top of the smokestack adapter and the respective colors.  You can see that the black wire for GND is attached to the USB shield pin we installed earlier. Remember, pin 1 and pin 7 on the smokestack are left not connected!

Top of smokestack adapter with jumpers.

The below image shows the JTAG adapter, properly wired and ready to go.  You can see the device is powered by the USB connector and that the orange and purple wires have been spared off.   Although the flash from my camera drowned out the red power LED, you will need to make sure that your LED is lit.  Please note, the JTAG adapter does require power however it will not show up as anything in Windows as we are using the USB port strictly for the power lines for the JTAG buffer.

TIAO JTAG wired up and ready.

An aerial view of the whole mess.     Yes, I know my desk is still messy.

C:\Program Files\OpenOCD\0.4.0

Wow, what a rats nest.

Now that all of the required connections have been made, it’s time to get busy with the software. Plug in the power cable to your dockstar and proceed to the next section.

Step III: Software

If you haven’t already, go back up to the Parts list and download Kragorn’s dockstar.cfg, OpenOCD and the uBoot image.

Install the OpenOCD software and accept the defaults.  Once completed, unzip the dockstar.zip and copy dockstar.cfg to C:\Program Files\OpenOCD\0.4.0\board and then copy your uboot image to C:\Program Files\OpenOCD\0.4.0  It would be recommended to rename it to just “uboot.bin” so that way you won’t have to retype that complicated line later on.

Now that we have all the proper software in place let’s discuss what all is going to happen.  When you start OpenOCD in a DOS window, it will in turn start a telnet server on localhost, port 4444.  You will use PuTTY to connect to the telnet server process and issue commands to OpenOCD.   In conjunction with that, you will need a second PuTTY session established to COM1 (if your windows machine has the CA-42 cable plugged into it) or to SSH to the machine you have the cable connected to. The reason is that once you enter specific commands on the telnet window, you need visibility to the other window (serial or SSH) to see if your dockstar is booting. Timing is critical! From here on out, commands and things to look for in output are in bold with other important text in bold, italics and underline.

In my configuration, my windows computer is what will run OpenOCD and the telnet session, and a nearby Linux box will have the SSH session with an application called minicom.

Start off by opening a DOS window (Start -> Run -> “cmd” )

Type the following command in exactly as shown: 

openocd -f board/dockstar.cfg

You should get output similar to the below image.  If you get what I have, then you can proceed to the next step.  If you get any errors, check your wiring. Make sure only those pins shown in the above images are what you have hooked up. Also, you may get a  Windows Firewall exception error.  If you do, just hit “Allow” otherwise you won’t be able to talk to OpenOCD.

OpenOCD successful startup

If OpenOCD is running without errors, minimize the DOS box and start PuTTY. Use the below configuration to establish a connection to the telnet process that OpenOCD started.

PuTTY Telnet settings

When you connect, you should get a window that says “Open On-Chip Debugger” with a caret “>” prompt.  Before we continue, if you haven’t already pulled up your serial session to the dockstar, you will need to do that now.  The issue is that from here on out, we will either be communicating with OpenOCD via Telnet, or communicating with the Dockstar via serial.

Now that you’ve established your connection to OpenOCD, perform the next two steps.

• Type the command “init” into the telnet session and hit enter.
• Type the command “sheevaplug_init” into the telnet session and hit enter.

Now, here is the hard part. The routine sheevaplug_init from above will attempt to halt the processor.  The Marvell chip has two types of halt, one of which labelled “ARM” and one labelled “Thumb”.  If your output resembles the below output (processor halted in Thumb state), you will need to perform the next steps otherwise skip down to the next section. When in doubt,  continue with the instructions below.

Thumb State Halt is no good!

If you got “Target halted in Thumb State”: There is some additional trickery that must be performed.   The issue is that the processor must be halted in ARM state as this allows OpenOCD to communicate with the processor properly.

• Hit Ctrl-C in your OpenOCD session. Your PuTTY session will break and generate an error. Dismiss the error and restart OpenOCD.
• Hold down the reset button and keep it held down with one hand and with the other, type “sheevaplug_init” and hit enter.  Ignore the error messages.
• Type in the command “halt” . DO NOT HIT ENTER YET!
• Release the RESET switch and simultaneously hit Enter.
• You should see that the processor was halted in ARM state.
• Type in “sheevaplug_init” and hit enter. No output should be generated from this command.

Check your telnet session output with my output in the screenshot below.  Make sure your output matches the screenshot before proceeding.

Properly halted dockstar

Now for the ultimate test.  We need to probe the NAND flash to make sure that the processor can communicate with it. Type in “nand probe 0” (zero) and hit enter.  If everything is correct, you should get text returned similar to “NAND flash device ‘NAND 256MiB 3,3V 8-bit’ found“.  If you get any other message ESPECIALLY anything about Unknown Manufacturer, restart OpenOCD and try again.  Here is my output so far:

Nand Probe Successful!

Now that the processor has been correctly identified by OpenOCD and the processor has properly identified the flash memory, we can now load the image into the Dockstar’s RAM and tell the processor to execute it. Type in load_image uboot.bin 0×800000 (zero, letter x, 8 and five zeros). If you renamed your uboot file something other than “uboot.bin” then substitute as needed.  This will take a couple of minutes as the image is transferred. Here is the output of what I have after the image loaded into RAM:

Load_Image successful!

When you get the caret prompt back “>”, type in the command “resume 0×800200” and check your serial connection for activity.  At this point, you can minimize the telnet session.  Now we will be dealing expressly with the serial connection.  Depending on your connection method, you may have a different window, but the text is the same.  As soon as you hit enter on the resume command, you should notice that the LED on your once dead dockstar is now blinking. Immediately switch over to the serial connection and hit a key to disrupt the boot process. If you did it right, you should see that the command prompt now shows Marvell>> as shown in the screenshot below:

Interrupted boot sequence

DO NOT DISCONNECT POWER FROM THE DOCKSTAR YET! WE ARE NOT DONE. The Dockstar has successfully loaded and ran the uboot commands in RAM however if we hit the reset switch or powercycle the dockstar, the device will return to it’s zombie state, and we will have to do it all over again. The only thing left to do is to prepare and write the image to flash.

If you were like me and you accidentally typed in ‘nand erase” and bricked your dockstar, you will need to re-erase the flash to reload it.  If you bricked your dockstar by another method, skip this step and go on to the next paragraph. To do this, type in “nand erase“.  This will erase the entire flash chip.  Now to write the working uboot to flash, use the command “nand write.e 0×800000 0×0 0×80000“  (zero x eight then 5 zeroes, zero x zero, then zero x eight then four zeros). You should get a message that the nand write was successful similar to the below screenshot.

Successful flash write.

If you did not brick your dockstar by an errant nand erase command, you will want to use “nand erase 0 0×0 0xa0000” (zero, zero x zero, zero x a then four zeros).  The reason for this difference is that if you didn’t erase your flash, this command will preserve the u-boot environment variables, otherwise you would have to recreate them later on.

Now, it’s time for the moment of truth.  Don’t start disconnecting wires just yet, simply tap the reset switch to load the uboot from the flash and test your recovery.   You will notice two key things:  Your uboot will be stuck in a permanent loop (assuming you didn’t interrupt autoboot) and the LED on the dockstar will alternate between flashing green and flashing orange as uboot cycles through.  This is because the dockstar can’t find a valid kernel or filesystem to boot from.  If you used the same version of the uBoot I listed above then you will notice that this uboot will attempt to boot off of USB key drives unlike the original factory image which opens up a LOT of opportunity.

To clean up, simply exit the various windows you have open, and exit OpenOCD by hitting Ctrl-C.  Remove power from the Dockstar, then remove the smokestack adapter and the ground wire on the USB shield.  If you want to make sure (because you’re as paranoid as I am, reapply power after all the jumpers have been removed and make sure that the Dockstar’s LED continues to blink orange then blinks green and repeats.  This means that your dockstar is confirmed as running off it’s own flash.

Now get to hacking!

Section IV: Notes and Credits

This article was assembled using information and help from various sources.  I want to thank everyone listed below for your assistance in helping me with getting the Dockstar JTAG figured out.  It was definitely not easy for someone new to JTAG however it was an enjoyable learning experience once I got the bugs worked out,  even if I did scratch my head a lot.

From the PlugApps forums, I’d like to thank Admin, Kragorn, bzboi, klingon, ygator, mrbill, and jtagfun.

A special thanks to bzboi for the initial howto that most of the OpenOCD instructions were used from and to Admin for the starting post with the Dockstar’s JTAG diagram.

I’d also like to thank mrbill for getting me involved with these things. It’s all his fault that I even have a dockstar to break.

Thanks goes to Kragorn for finding out the proper settings in his dockstar.cfg so that all of us could unbrick after the inevitable “Oops…” moment.

Last, but not least, thanks goes out to Jeff Doozan for his work with uBoot and compiling in needed features into the bootloader so that we can use USB sticks as boot devices.

Where do we go from here?

The answer is “Where do you want to go?”  In my relatively short time with the Dockstar, I was working on getting OpenWRT compiled and installed on it.  OpenWRT is the same OS that they use for the Linksys and other branded routers and is pretty much it’s own distribution.  There are also processes on how to install Debian onto the dockstar, using a laptop drive and USB sled to run the OS.  There is a lot of people doing research and finding out other warranty voiding things to do with their dockstars so take a look around.

As far as me personally?  I have three of them and while one of them is going to be a small NAS fileserver, one of the more esoteric things I was planning on doing with mine is making it into a roving USB camera with wifi.  The idea is that the Dockstar’s mainboard would be the brains of the rover and could send commands to a Parallax BOE-BOT via a usb to serial converter.  Since the entire thing would be wireless off of a USB dongle, I could use the IP based connection to deliver video and commands via a custom written application.

I sincerely hope that you are able to recover your dockstar using the above process.  It’s no fun when you accidentally destroy something you have put so much work into however now you should be able to work on the Dockstar without fear that you’re going to damage it and prevent it from booting.  Also, if you decide to try custom boot loaders, you can do so worry free.

Happy Hacking!

FIRESTORM_v1

Dockstar box

This is the box that the Dockstar came in.  Having not bought a non-OEM seagate drive in ages, I was pleasantly surprised that they used normal cardboard instead of some plastic case for this device.  Seagate is really pushing their “Go Green” incentive by changing the entire box (even the box inside) with easy to recycle cardboard instead of that translucent plastic “tray” that normally accompanies electronics.  While not necessarily an indication of product performance, it does show that they care about the environment.

Dockstar contents

Inside the box, aside from the little “Getting Started Manual” is the following items:  A Universal power brick pre-fitted with the US style prongs, a shielded ethernet cable and of course, the dockstar itself.

universal plug sticker

Here’s a closeup of the universal plug and all it’s various warnings and certifications.  I have seen a shift towards these universal plugs and away from the more proprietary plugs that manufacturers would normally use as a cost saving process. Since there is no one world-wide standard on power for every country that Seagate does business with, why spend that money building 20+ different power adapters when all you need is one with different prongs to fit whatever country’s plugs you’re going to be selling to.

Universal Plug details

And, just because I’m a sucker for details (and I keep losing the power bricks), here’s the voltage and amperage rating of the power brick.  Output is 12vDC 2Amps with a positive tip.

Dockstar front

Finally, we get to the dockstar to find what secrets it holds.  The front panel has one LED for device status and the USB mini-B port for the Freeagent drive to sit in.  Unlike most older-style USB devices, the Seagate Freeagent is powered entirely through the USB port, eliminating the need for two cables to power one device.  Overall it’s a simple presentation of what looks to be a fairly complex device.

Dockstar Back

The back of the dockstar has two USB ports, the Gigabit Ethernet port and the power port on it.  I would like for there to have been a link and an activity LED for the Ethernet port, but unfortunately this was not implemented.  I guess I’m a sucker for LEDs.

Right side of dockstar

The right side of the dockstar features another USB port and the reset switch for the device.  The left side of the dockstar (not pictured) only has cooling vents on the side.

Dockstar Bottom

This is the bottom of the dockstar which has a large sticker that shows the serial numbers and MAC address of the device.  Of note, there was one number on this sticker which is formatted like some kind of product activation key and is formatted as follows:  six alphanumeric characters,  hyphen, six alphanumeric characters, hyphen, two alphanumeric characters, hyphen, six alphanumeric characters, hyphen, six alphanumeric characters.   At first glance, I thought these were hexadecimal numbers however the letters used were not between A-F and so it’s currently unclear what this number is for.  There is no mention of what this number is for in the documentation.

Gaining access to the insides

Typically on a device like this and most small consumer devices, there are four screws on the bottom (usually under the black slip-resistant dots) however the Dockstar doesn’t have any.  In order to gain access, I used a metal spudger to work the bottom away from the top half of the body.  There are two notches on each side of the square base, so you may need to use something flat like a spudger, small flathead screwdriver or a expansion slot blank to pry it open.

Cracked the case

Once you cracked the case open (hopefully without breaking it), you should see the small cable that connects the top USB port to the dockstar’s mainboard.  Carefully disconnect this cable and the two halves should now be seperated.

Mainboard top view

This is the dockstar in all it’s nude glory. The front of the device is to the right in this photograph. The small black square is Nanya 1Gb (comes out to ~128 megabytes)  DDR-2 RAM in a BGA package. Datasheet available here and the large square is the device’s main processor.  From research I have performed, this appears to be a Marvell 1.2GHZ processor (just like the sheevaplug devices that Marvell is also selling. I tried to pull some more datasheets from plugcomputer.org, but their datasheet listing is quite lacking.  For now, just know that it’s an arm compliant processor and when I post an update article, I will have more juicy details on the capabilities of the processor.  Also of note, just below and to the right of the processor is a small ten pin header.  Presumably this can be used for a serial port however I do not have the cable for that.  Once I get it in and test it, I will update this article with a pinout diagram for you. Since this device is so low-level I would not recommend trying to connect a regular serial port to it directly as it more than likely requires a level shifter like a MAX232 to bring the -12/+12VDC down into something that won’t blast the components.

Mainboard bottom

This is the bottom of the dockstar’s mainboard.  Unfortunately, the board is now oriented that the front of the dockstar is now at the bottom of the picture. (Bad cameraman, no cookie.)  There’s not really much to note here as the board layout is jam packed with passive components.  The large black square on the lower right is the NAND storage for the device and while I couldn’t pull up the datasheet for it, the guys over at PlugPBX already had a forum post that showed the Dockstar’s hardware specs for us.  According to their chart, the dockstar’s storage is 256MB. which should be more than adequate for general Linux fun.  The small chip just under the black tape in the upper right hand corner of the board is presumably the ethernet NIC however googling the chip numbers came up with nothing.

Just looking at the hardware overall, it would appear that the Seagate Dockstar is a very capable device that just needs to be altered to run whatever we choose to run with it.  While the software on the device (stock) comes with a filesharing service called Pogoplug, I do not intend on using that software and will be looking to get this device as far away from stock as possible.  Here is a list of some things I’ve been thinking of doing with it so far:

• Home NAS (without Internet file sharing)
• multihomed router (I have a stack of pegasus USB modules)
• semiportable network notification device (USB to parallel port, HD44780 LCD display)
• realtime data acquisition device (USB logger and serial ports?)
• Apple MT-DAAPd server for streaming music to iTunes installations on your local network

Some sites I’ve seen while doing research have mentioned things from a in-home webserver with databases, to even a PBX server (take a look at www.plugpbx.org)

The big question is:  What would you do with it? Feel free to leave a comment as to what you’d do with this device, suggestions, information, etc.

FIRESTORM_v1

BIG FAT OBNOXIOUS WARNING!:

Because of the Dockstar’s affinity to want to “phone home” thanks to the Pogoplug software,  I would not recommend plugging this into your live network just yet.  In all of the research I have done for this device, just about every site I have seen has posted some kind of warning about this.  The dockstar was originally designed to run with pogoplug which is an internet filesharing service that allows you to access your files from anywhere with Internet connectivity.  I don’t exactly trust an outside third party to have access to my files on a device that is only going to be used on a local network so I have not connected mine up to even test it.  If you are going to do any work with this device, I recommend that you use a dedicated mini-hub or switch and that it not be allowed to connect to the Internet until you have a complete understanding of what all it wants to do.

You can download the update from Sprint at http://shop.sprint.com/en/software_downloads/pda_smartphone/samsung_moment.shtml

Please note: According to the instructions available at the link above, you will need to use a Windows PC to apply the update to your phone.  I will be posting a mirror shortly and it will show up in the “Download Files” page at the top of this page.

I have recently gotten my hands on a new Samsung Moment on the Sprint network. Within the next few days, I will post all the gory details from this Android n00b and will be offering a comparison against the other smartphone I have, the Palm Pre.

(Ok, innuendo aside…)

Well, the Christmas/Yule break is over with and it’s time to get cracking.   If you were like me this holiday season, you were either placed in the position if needing to do a hard drive upgrade for someone else or you received a new hard drive of your own that warrants upgrading.  The CloneZilla site didn’t contain very clear instructions for what to do so I decided to write this howto documenting the process. In this howto, I will cover using the free application “CloneZilla” to perform a hard drive upgrade on a test installation of Windows XP from 4GB to a 10GB drive.

Foreword:

Of course, it’s Christmastime/Yule and I took pity on my girlfriend’s laptop which had two things going against it.  Firstly, it had vista and secondly it had a 80GB hard drive.  I’m not sure why Toshiba in their infinite wisdom only gave it a 80GB HD, but they did. Thankfully I had just completed an upgrade to another machine and had a 250GB hard drive to spare.  So I set out to upgrade her hard drive and fix at least one of the two reasons that her laptop was evil.

A lot of research turned up various solutions however none of them were very viable or were free.  Most of them required two hard drives in one computer and although her laptop did have the solder traces for the second SATA hard drive connector I’m not about to take a soldering iron to her laptop, she’d kill me.  So with that said and with my head still attached to my body, I kept searching.  I found a Live CD application called CloneZilla which had Cloning abilities much like a certain Symantic product but was free and didn’t require extensive configuration to get to work.  Unfortunately the instructions were not very clear at all and after spending a nailbiting hour trying to start the copy, I finally got it done and decided to document the process in case someone else got stuck in the same need that I did.

In this HOWTO, I will be upgrading a 4GB Virtual Disk in VMware with that of a 10GB Virtual disk.  Aside from the fact that it’s all virtualized, this is indeed a true upgrade and is exactly how you would do an upgrade for a real “physical” computer.

Prerequisites

You will need the following items for a successful transfer:

1. The CloneZilla CD available from http://clonezilla.org/ I’m using Clonezilla Live version 1.2.2-31.
2. A Windows computer that has a hard drive with free space greater than the size of the original disk you are upgrading.  (If you’re upgrading a 40GB HD, then this machine must have at least 40GB free on it.) This will be the WIndows Image Server.
3. The hard drive to upgrade
4. A working network where your machine to upgrade can browse the other windows machine’s file shares. (This is CRITICAL, as the other machine will store your disk image for the upgrade.)
5. A case of beer, rum, vodka, etc…

The “other machine” in #2 will be the image server.  This is where CloneCD will copy the files to that make up the disk image.  I will review how to set up a fileshare in Windows for this however any machine that does SMB filesharing can work.  There are other options available however SMB sharing works the easiest.

Process Overview

In this HOWTO, we will be upgrading a Windows XP Virtual Machine with a 4GB HD to a 10 GB HD.  Although I’m using VMware Server to capture the screenshots, this same method can be used to upgrade almost any home Windows computer.  I’m not sure if Windows 7 or if Windows Server 200* will work but in all theory they should too.  The process for upgrading will go something like this:

1. Examine the existing system to upgrade and get existing disk size
2. Configure Windows Image Server to accomodate images
3. Boot system to upgrade with Clonezilla, configure and start copy process
4. Swap out hard drives, reboot with Clonezilla and configure to start the restore process
5. Take whatever OS steps are needed to take advantage of new space. (OS Dependent)

Step 1:  Examine the existing system

This one’s easy.  Just fire up the existing machine and take a look at the hard drive.  In my example system, there’s only one hard drive.  All I did in this screenshot was open My Computer and Right Click on Local Disk C: then go to “Properties”:

Test system to upgrade

If a machine has more than one partition, you might need to go to Local Disk Managment (Start -> Run -> diskmgmt.msc ) Here’s a screenshot of what our test system looks like through Disk managment:

System To Upgrade (Disk managment view)

Based on this information and according to disk managment, the minimum free space we need on our windows image server will be 4GB.  I would recommend an extra GB just in case. Now that we know how big the disk is and how much space we need, let’s get the image server configured.

Step 2:  Configuration of the Windows image server

This section covers how to set up the Windows Image server for the new image.  We will need to create a new directory for the image files, create a new user on the server and then assign that user with full permissions to that directory over the network.

Step 2a: Add the user

Right click on the My Computer Icon and go to Manage

"Manage" option in Rt Click menu, Easy way to get to users and Groups

This will bring up the Computer Managment Console.  Click on the “+” next to “Users and Groups”, then click on Users.  This will show you all of the currently installed users on the system and should resemble something like below:

Users view in Computer Managment

Right click on the right side of the window and click on “New User…”

Users and Groups Right Click Menu

In the “New User” dialog box that pops up, you want to set the following options:  Username = clone Description = CloneZilla user”, Password = clone  “User Cannot Change Password” and “Password Never Expires” should both be checked. “Account Is Disabled” and “User Must Change password at next login” should be cleared (unchecked).  See below for the reference screenshot:

New User Settings

Click “Create” and then click “Close”.  You can see the new user in the screenshot below highlighted in a red box.

Our new Clone user

Step 2B: Configure the file share and add the user to the share.

Now that we have the user in the system, we need to create the file share. In this case, I’m using a directory inside my “D:” drive to store the images.  MAKE SURE THAT WHERE YOU STORE YOUR IMAGES EXCEEDS THE CAPACITY OF THE DRIVE TO BE COPIED! In our case, we found that the system to upgrade is 4GB, so we need at least a 5GB disk to copy to.

Go ahead and locate a suitable place for your clone files.  In this case “D:” is completely blank except for the system files that Windows generates for partitions.  Right click and create a new folder called “clone”

My clone directory

Right click on the clone folder and go to “Sharing and Security”.  Fill out the form and name the share “Clone” however don’t click OK just yet.

clone directory sharing properties

We need to make sure that the “clone” user we created earlier has full access permissions to this directory.  Click on “Permissions” and add the “clone” user to the directory with full permissions.To do this, click “Add” on the Permissions screen, type in “clone”, type in “Check Names”, then hit OK.  In my case, it added “ZEUS\clone” which is still correct.  ZEUS is the name of the image server.

Adding clone to sharing permissions

Now, I have “clone” added to the permissions window and set the proper access permissions for that username as shown below.  Go ahead and click OK to the Permissions window and to the sharing properties window.

Permissions are set

If all works well, you should see a “waiter’s hand” appear below the directory icon.  This hand icon shows that this directory is shared across the network and is available for access be it read-only or read/write.  At this point, we are done with configuring the server.  We’ve added the “clone” user to the server, added a suitable “clone” directory for Clonezilla to store and retrieve the disk image’s files from and we have added proper permissions to the directory for the clone user.

Step 2c:  Test it out!

Go back to our initial machine to upgrade.  You should be able to find your image server by browsing “My Network Places”.  In my case, the image server was named “zeus” and showed up only after I clicked on “View Workgroup Computers” as shown in this screenshot.  You should get a similar password prompt when you try to access your image server:

Clone share testing

Login with the user credentials we created in 2A, (username and password of “clone”) and you should be presented with a directory listing like the one shown below:

directory listing

We have proven that our clone user works, but let’s test to make sure that we can write to it.  Double click on the clone share and try to create a text file.  (Right Click -> New -> Text File)  If it creates a “New Text File.txt” like shown below, this means that your permissions are correct and you’re good to go.  If you get any kind of read/write error, check your permissions on the image server.

Write test for clone user

If you’ve gotten this far, then congratulations, you’re ready to do the copy.  Go ahead and shut down the system you’re upgrading and get ready for the next step:

Step 3:  Boot system to upgrade with Clonezilla, configure and start copy process

Go ahead and boot the upgrade system with the CloneZilla CD. You will be presented with a boot menu like the one below. Go ahead and select the first menu option “Clonezilla live (Default Settings, VGA 1024×768)”:

Clonezilla Boot Menu

It will then take a bit and flash a lot of linux based stuff at you.  Finally you should be directed to choose a language.  The prompt should look like this now:

Choose a language menu

You will then get a prompt about keymaps.  When in doubt, just leave it alone.

Keymap prompt

More console stuff will flash past and then you’ll get the prompt you’ve been waiting for.  Unless you’re very very advanced, you will only use the “Start Clonezilla” menu option:

Start Clonezilla

Now we’re at a screen that is really confusing.  We want to work with the disks but we also want to work with images to create partitions.  In this instance, we’re going from the disk to an image file on our windows image server then back to disk again.  In our instance, we will need to use option 1, Device-Image.

Image/Disk option menu

In this screen, it’s asking where are we storing the image.  The answer is “samba/Network Neighborhood server” however if we needed to, we could use a local SSH server as well.

Image Server Type dialog

Now it’s asking how we connect to our network.  99% of the time this will be “dhcp” as you will know if you’re using static for anything.  If you have a Linksys router or similar router/firewall device, select DHCP.

network type dialog

After you get a successful IP address, CloneZilla needs to know what IP address your windows image server is.  In my example, the windows image server (zeus) is 192.168.0.5.

IP address dialog

Next, Clonezilla needs to ask for the Domain.  If you are not using a domain, then tab to “Cancel” and hit Enter.  I’m not using a domain here, so I just hit Cancel.  This is reserved for corporate networks that use a special server called a Domain Controller.

Domain prompt

Now Clonezilla needs to know the username of the account to connect to the server.  This will be the username and password you created in Step 2 above.  For our test, we put clone as the username

user prompt

Clonezilla prompts us for the location (the share name) of where to put the images.  In the steps above, we used “clone” as the share name.  This is the location we give to Clonezilla so it can store its images. Be sure to leave the leading / at the beginning of the directory name.

directory name for images

Next, it’s time for the password.  When prompted, type in the password.  Although this prompt looks different than the others, this is not a sign that something has gone wrong so relax.

password dialog

If all of the information you entered was correct, you will get a filesystem mount listing similar to what is shown here.  If something went wrong, you’ll get an error message outlining the possible error and a chance to re-enter the information.  If it doesn’t give you the option to reenter or something isn’t right, just hit the power switch..  In this screenshot, you can see that the last line starting with //192.168.0.5……  is our image server and that it is mounted correctly!

mount listing

Since we have successfully mounted our image storage as part of the liveCD’s filesystem, it’s time to start the copy.  You will be prompted for which mode to run Clonezilla in.  I recommend the “Beginner” method as it makes the entire copy easy.

Mode select dialog

Now we are prompted on what to do.  We will start off by selecting the first option “savedisk” as we want to save the existing disk to the image server.  We will use “restoredisk”  later.

Function Select

If you are wanting to manage multiple images, you have the option to name them with something more descriptive .  For now, I selected the default name which is in YYYY-MM-DD-HH format.

Image Name Select prompt

Now we tell CloneCD which hard drive to copy.  In most systems, there will only be one hard drive, however make sure you have the right one if not.  You can select and deselect by using the space bar to toggle the asterisk.  An asterisk in the brackets “[*]” means that the item is selected however the brackets alone “[ ]” means the item is deselected.

Drive Select prompt

One last word from Clonezilla before it starts copying.  If we wanted to run in console mode (which I will never do. ) we could do it all with one command.  Just hit enter to get past this prompt and start the copying.   This also tells us that it has successfully found and identified the drive we selected to copy and shut down Linux’s logical volume manager to allow direct access to the disk to copy.

Pre-copy ready

One last final confirmation that the information we have entered is correct.  Remember that making this image does NOT make any filesystem changes to the original hard drive and in fact, no changes to the original hard drive are ever made.  This is especially good in case you need to revert your upgrade, you can just swap out hard drives and you’re back where you started from.  If everything is correct in the yellow text, go ahead and type “Y” and hit enter.  This will start the copy process.

confirmation prompt

Finally, the copy begins.  Go ahead and grab a soda, watch a movie or something as this will take a considerable amount of time depending on the size of your hard drive.  In my test example transferring a 4GB hard drive, it took roughly 16 minutes to complete.  My girlfriend’s 80GB hard drive took several hours to copy.

Copy Started

At last, the file copy is complete and we are ready to exit Clonezilla:

Copy complete.

Hit “Enter” then hit 0 for power off.  After a few seconds, you will get the message “Please remove the disc, close the tray (if any) and press Enter to continue. Hit enter and your computer should now turn off.  Go ahead and perform the drive swap now. We’re halfway there!

Step 4:  Swap out hard drives, reboot with Clonezilla and configure to start the restore process

Before continuing, you want to make sure that your hard drive is recognized by the BIOS.  In my test setup, I have swapped out the original 4GB VMware disk with a 10GB Vmware disk and it is displayed in the BIOS here:

BIOS showing new hard drive

Just like before, we will use the same options to create the disk image to restore the disk image.    Use all of the instructions in step 2 all the way until you get to the Mode screen shown below.  Instead of selecting “savedisk” like we did at the last screen, we want to use “restoredisk” instead.

Select Mode dialog, revisited

Now we select the image to restore to disk. Since we only have one image listed, this is the one we use.

Select Image dialog

Once we have selected a viable image, now we are prompted to select the target device.  Again, it’s the only hard drive, so it’s the device we want:

Select Target dialog

Just like before, it will tell us that we can rerun this restore using a single command from command mode:

clone command line

This time, the warning needs to be read.  This is just prior to performing any filesystem changes to the new hard drive.   If you are absolutely sure, go ahead and answer “y” to start the restore process:

restore confirmation text

One last time, it asks to make sure you are sure about your restore decision.  If everything is correct, answer “Y”.

Final restore prompt

A good bit of text will go across the screen and you will ultimately end up at a partclone screen like the one below.  The text that you saw earlier is the partition application creating the destination partition for the image.  Once created, partclone takes over and starts restoring the data from the image. Again, grab another drink, (I’ve got a margarita) and wait a few hours for the image to restore.

Partition restore in progress

Once the restore process completes, you will be prompted to power off.  Hit Enter, select option 1 and remove the CD from the CDROM tray when prompted.

restore completed

Once the system reboots, it should automatically start Windows.  If it does, you’re ready to go to the last step!

Step 5: Take whatever OS steps are needed to take advantage of new space. (OS Dependent)

Now these steps depend on which OS you’re using. At this point, we have made an image of the old drive, saved that image to another server and restored it to a new blank drive that is larger than the original image.  As shown earlier, we have a 10GB disk in our machine to upgrade and we have just restored our 4GB image to it. We have successfully booted windows however our disk properties show that the disk image is still 4GB.  (Ignore the disk space used, as I was shutting down the disk image it decided to install 50 windows updates…)

Disk space still the same?

Here is the same shot of the disk managment window after the upgrade/restore.  You can see that it is a 10GB drive, but is still a 4GB partition.

disk managment

Attention Vista Users!!: If you are running Windows Vista, you can use Disk Managment to expand the disk size.  All you have to do is right click on the C: partition shown above then go to “Expand Disk”.  This will walk you through the process for expanding the disk to take up the entire space of your new drive.  I’ll add new instructions to this as soon as my girlfriend lets me use her laptop again.

For those of you not running Vista, keep reading. At this point, we have validated that our restored image works properly.  Now all we need to do is resize the partition to take up the entire disk.  Thankfully clonezilla has a solution for that.  Reboot using the CloneZilla CD. Answer the same questions regarding keymap like you did before except instead of starting clonezilla, we want to enter the Clonezilla shell.

Go to Clonezilla shell

You will get dropped to a text prompt that presents you with several options.  You will want to select option 2, “Enter Command Line Prompt”.  Once done, you will be at a user@debian prompt as shown here:

command prompt

We are going to use the utility “ntfsresize” in order to increase the size of the partition that we restored to the new disk but first we need more information.  Before we get started, run the command “su -” to get to the “root” user. This will allow us to modify the drive’s layout.    At the above menu prompt, hit the digit 2 for “Enter command line prompt” and then type “su -” at the “user@debian ~$” prompt.  The screen should then look like the screen below.

SU to root

Then we will use “fdisk” to get the disk’s full size.  I ran the command “fdisk -l /dev/hda” to get the drive size:

fdisk disk size

This is important as we are going to delete the partition, then recreate the partition.  First off let’s run “fdisk /dev/hda” and use “p” to get the partition size.  In this screen, we see that the partition starts at 1 and ends at 521.  We want it to extend to the rest of the disk.  We’ll start off by using “d” to delete the partition, (FDISK will assume partition 1) and then create a New partition using the defaults as shown below (Use the commands “N” for New partition, “P” for primary partition, and give it partition number 1).  Once we have created the new partition, we will need to set the “System” back to HPFS/NTFS otherwise NTFSresize won’t work properly.  Below is the FDISK responses to these commands we’ve used so far.

FDISK resizing

Now that we’ve create the new partition, we have to reset it’s type.  Use the “t” command and set it to ID of 7 (HPFS/NTFS) and then use “a” to toggle it’s bootable state.  We want to be able to boot into Windows after all.  Use the “w” command to write the partition data to the hard drive and exit.  Now that we have reset the partition size, we can use NTFSResize to expand the NTFS data.  Cross your fingers and run “ntfsresize /dev/hda” and it should produce output like what is shown here.  When run with no additional parameters, NTFSResize should automatically find the beginning and the end of the partition and expand the existing NTFS data to take the entire drive as shown:

NTFSResize

With our newly resized partition we should be able to reboot and get into our Windows environment.  To do that, just type “reboot” and remove the CD when prompted.  Note: The above screenshot missed me using the “a” and “w” commands to toggle bootable status.  Here’s what it looks like:

Bootable flag now set, sorry guys.

Ok, so now that I have fixed my grievous error, it’s time to reboot.  With any luck, your computer will boot Windows and go staight into a chkdsk environment.  THIS IS OK!, this means that Windows sees the new partition size and that it needs to run a consistency check.  DO NOT PANIC!!!  Let the consistency check run, then it will reboot your computer again.  After it boots for the second time, it might prompt to restart because it found new hardware (the new HD).  This is OK as well.  Let the windows installation reboot.  Once it has completed rebooting for the third time,  get your disk properties by right clicking on C: drive and going to Properties.  As shown below, we have successfully resized our partition to take up the entire drive and are now sitting at 10GB (well 9.99GB according to windows.):

Windows XP's new filesize

Here is a screenshot from Windows XP’s Disk managment to show that we used the entire drive:

Disk managment with new partition sizes

At this point, we have successfully finished the migration!  Here’s a rundown of what all we did in this step:

1. We restored the partition to the new drive
2. We verified that the restore worked properly when booted into, e.g windows booted properly and without errors.
3. We then deleted the existing partition, recreated a new partition and then set the partition type and bootable flag using Linux’s FDISK on the Clonezilla CD.
4. We used NTFSResize to expand the NTFS data to take up the entire new resized partition.
5. We then booted into Windows and let it do a filesystem check
6. When Windows was restarted again, we validated through Properties and “Disk Management” that the new disk was used fully.

This was the most complex part of the migration as CloneZilla only goes about 90% of the way to migrating to a new, larger hard drive.  I hope that this howto provides the last 10% that you are looking for.  With this howto and a copy of CloneZilla, you can then upgrade almost ANY hard drive that Linux supports and can even go from IDE to SATA or SATA to IDE if need be.

Afterword:

I sincerely hope that this helps someone out there trying to make sense of a hard drive upgrade.  I know that I learned a lot about partitions and filesystem structures by attempting an upgrade of my girlfriend’s laptop and this Windows XP installation.  I know that working with partitions is a scary thing as you could potentially lose data but keep in mind that your “original” hard drive still has all the original data on it, as does the image that was stored on the windows image server.

The items in this howto can potentially be a life saver especially if you have a family member that keeps messing their computer up.  You could create an image after you have performed all needed windows updates and software installations and then retain it for if something goes wrong.  Rather than having to manually do an OS reload, you can run though this HOWTO in an hour and have their system up and running again, fully patched and ready to go.

I hope that you had a great Christmas/Yule  with your family and look forward to keep going strong in 2010.  As always, thank you for your continued patronage, you are always welcome here at YourWarrantyIsVoid.com!

FIRESTORM_v1