Most of the actions I describe herein result in the voiding of
the device’s warrantee. I take no responsibility for any damage which might result
from anyone attempting to duplicate my work. In other words, you bear all responsibility
for your own actions. If you break your 3C19504 then it’s your own fault. I do not recommend
you reproduce my work! This information is offered for entertainment purposes only, no
warrantee is offered or implied.

The Gory Details

I started by plugging in and booting the 3C19504 as per the owners manual. I set it up to run
on my home network, as though I was only going to use the file server and web server functions.
Once I had verified that everything was OK (i.e., that it was DOA) I proceeded with my
experimentation.

The first change I made was to remove the cover from the VGA port. The cover was held in place
with Torx screws and was easily removed. I then booted the 3C19504. The following three screen
shots—taken with a digital camera—show the start of the boot sequence (click to expand the
photos):

from this shot we can
see that the 3C19504 is using an AMI BIOS, version UC612C.

in this
shot we can see the Fujitsu MPG3102AT E hard drive being detected

in this shot we see
the BIOS summary screen and the LILO prompt

here we also see that the system only contains 32 meg of RAM; suggesting that if
performance suffers later, some extra RAM might be in order

Making The Box Accessible

In order to facilitate ongoing support of the box by me, I want to be able to telnet into it
from the home LAN side of the server (when it’s operating as a firewall, one NIC is on the
Internet/WAN side, and the other NIC is on the LAN side). I would like to be able to telnet into
the device and then su to root in order to make configuration changes. It turns out that if one ticks
the “Enable Remote Management using permanent Internet connection” option on the 3C19504’s
System ®
Admin Access section in the configuration tool then the device will start the telnet
service.

Once telnet is running, the next step is finding a userid/password combination that will give
you access to the box. In order to get access, I found it necessary to remove the hard drive from
the 3C19504 and mount it on another Linux machine. Since my home PCs run MS Windows 2000
and NeXTSTEP, I needed to get creative: I downloaded an ISO image of a bootable Linux CD and
booted my home PC (a Dell) from that.

To create the bootable CD I used the Red Hat v6.2 bootable ISO image called SuperRescue CD; maintained by H. Peter Anvin. I used his version 1 release as it
was closest in version to the 3C19504’s Linux version; however, his version 2 looks
absolutely fabulous. The CD just worked, first time out, no trouble. What better recommendation
can I make?

On the 3C19504’s drive I found 5 partitions (I’ve also listed the device path used to
mount that partition under SuperRescue):

The boot partition [/dev/hda1]

A skeletal directory structure [/dev/hda5]; it looks like the other partitions are
ultimately mounted into this one

The system files [/dev/hda6]

The user files directory structure, and some other supporting files [/dev/hda7]

Swap space [/dev/hda8]

I initially mounted the partitions in read-only mode to ensure I didn’t mess something up.
Then I mounted /dev/hda6 in read-write mode and edited the /etc/password file: I
removed the password crypt for root’s entry, and I added an extra entry of my own with user and
group ids of 0 (i.e., I made it a clone of root). Then I put the drive back into the 3C19504
(after unmounting and shutting down, of course).

I then found that while I still could not log in as root or login using my new userid, I could
ftp in using my newly added userid. Thus I now had a way of changing any file on the system; which
means there would be no further necessity to mount the drive on another system in order to hack
its files.

Toward Access Via Telnet

Now that I was able to log into the 3C19504 using FTP, this facilitated working on it using XEmacs and EFS
mode. An exploration of the system configuration files in /etc showed that Pluggable Authentication Modules (PAM)
are being used for security, and not just default UNIX security.

Notice how authentication is only to be done using the the Password Database Library; thus explaining why I
was unable to login to the device even after I had created an entry in the /etc/passwd
file. The puzzling thing is that no password database appears to exist on the system, and no
/etc/shadow file exists. I rectified by patching these two PAM /etc/pam.d
files as follows (highlighted lines are new, the trailing lines of the files have been truncated):

The net result of this change is that I was finally able to telnet into the 3C19504 using my
new userid.

Installing A Larger Drive

These days, a 10 gig drive is not very big. Since the 3C19504’s OS consumes 2 gig, that
leaves 8 gig as user-usable. I have received correspondence from one individual who has
swapped out the original hard drive for a 20 gig drive. I have myself attempted to
install a 40 gig drive, and that causes the POST boot-up test to hang; which appears to
validate the manufacturer’s claim that the largest drive supported by the BIOS is 32 gig
(as noted in the next paragraph).

I emailed the tech support contact provided on the FIC homepage asking what the largest hard
drive supported by the AMI UC612C BIOS is. FIC tech support responded within 48 hours to say
that 32 gig is the drive limit for that BIOS. I wasn’t happy with the manner in which
I had posed my question to the FIC tech., because I had mentioned the 32 gig limit in my
question. So, I dug deeper.

I queried a couple of
individuals more knowledgeable than I about BIOSes and Linux. One of them turned up the
following information on IBM’s website: Getting beyond the ATA 8.4 GB limit.
I spent a few minutes looking at the various drive types supported by the BIOS, but none of them
is useful in out current world of multi-gigabyte drives. The screenshot to the right shows
one of those drive settings.

My own experience shows that a 40 gig drive will not work with the BIOS (it hangs the
POST). Since conducting this initial investigation, I have upgraded the drive.

To be sure that one is able to use a drive larger than 8.4 gigs, it is probably necessary
to ensure that the Linux boot partition is fully contained within the first 8.4 gigs of the
disk.