NE200
From Sfvlug
m |
|||
| Line 1: | Line 1: | ||
[[image:NE200_working.jpg|thumb|300px|Working on the NE200]] | [[image:NE200_working.jpg|thumb|300px|Working on the NE200]] | ||
| - | This box is a small desktop thin-client machine Sak and [[user:dualdflipflop|DualD] found at [http://www.hopenumbersix.net/ HOPE 2006], which the people who brought it could not get to work. The following notes where compiled by Sak and DualD based on the information gathered by online references, the people who brought the devices, and trial-and-error. | + | This box is a small desktop thin-client machine Sak and [[user:dualdflipflop|DualD]] found at [http://www.hopenumbersix.net/ HOPE 2006], which the people who brought it could not get to work. The following notes where compiled by Sak and DualD based on the information gathered by online references, the people who brought the devices, and trial-and-error. |
==A LITTLE ABOUT THIS MACHINE== | ==A LITTLE ABOUT THIS MACHINE== | ||
Revision as of 23:00, 28 January 2007
This box is a small desktop thin-client machine Sak and DualD found at HOPE 2006, which the people who brought it could not get to work. The following notes where compiled by Sak and DualD based on the information gathered by online references, the people who brought the devices, and trial-and-error.
Contents |
A LITTLE ABOUT THIS MACHINE
Our Introduction to the NE200
The first night of the HOPE conference, Sakuramboo was walking around the second floor and decided to check out the NC200's that they had setup as Public Access Terminals for anyone not so fortunate enough to bring their own computers. DualDFlipFlop was working away at some ANSI art while all of Sak's curiosities hit him. He sat down at one client and after reading the help output from the boot prompt, he managed to boot into X, something that was later to be believed as false.
The next day, Sakuramboo and DualDFlipFlop were hanging around the owners of the clients/servers and DualD mentioned that Sak had booted into X. They, then received a lecture on how that was NOT possible, then pointed at some dangling twisted-pair claiming that was where all the wiring lead to. This prompted Sakuramboo to sit down at the client and boot into X. After some discussion, we found out that the client Sakuramboo picked happened to be the only one that had a ROM installed (go figure). This gave us many different things that we could try...
And we did.
Hardware Layer
The NCD NE200 is a thin-client which runs off of a 100MHz NEC R4300 CPU, similar to the one found in an N64 (which is the VR4300 @ 93.75MHz). The system has two slots for RAM, these systems only had one 8MB stick. There is an optional ROM module that resides next to the RAM Slots, the system we worked with was the only one with this ROM with version 3.2 firmware. Video is supplied by a Cirrus Logic, audio and MPEG 1 support as well. There are three expansion slots for extra network interfaces, hardware MPEG decoders, and other various options.
Interfaces
The NC200 being an X thin-client obviously has VGA support as well as PS/2 mouse and keyboard. It also has two serial ports; serial port 1 supports up to 115.2K baud rate, and serial port 0 which supports up to 57.6K baud rate. This is unusual in my experience. There was an RJ45 for a 10baseT network interface. None of the systems we worked with had any expansion cards.
We tried connecting to the serial ports with no success, however after the fact we read up on ways that we could have tried, however didn't have the correct gear to accomplish the suggested applications.
INSIDE THE SYSTEM
After hitting the power switch, the monitor comes to life with the boot configuration screen. Once booted, the NC200 boots to a BIOS like prompt which has very limited functionality, just enough for it to be able to boot from a remote network server which can hold a binary for the firmware we found on the one and only ROM we had access to. Every boot requires the configuration to be reconfigured. There is an option to save the settings to allow you to just load the settings with one command.
BOOT>
from the boot prompt, you need to configure everything by hand.
Command Reference
IADDR – IADDR ip_address //IP address of the client IHOST – IHOST ip_address //IP address boot host IMASK – IMASK ip_subnet_mask //subnet mask IGATE – IGATE ip_address //IP address of the gateway BPATH – BPATH path and filename //the location of the boot file on the host server DNODE – DNODE decent_address //specifies the DECnet node address of the network computer BMETHOD – BMETHOD ROM or MOP or TFTP or NFS n //the type of service used to boot BDELAY – BDELAY DISABLED or RANDOM or n //amount of time specified between the connecting and transfer of boot file BAFROM – BAFROM NVRAM or DHCP or BOOTP or RARP or NETWORK //specifies how/where the boot file is located
Other useful commands.
CLIENT_ID – CLIENT_ID ON or OFF //specifies if the client identifier field is used during the DHCP boot. ETHERSTAT //displays statistics information on the clients connection on the network. NVFACTORY //sets the boot settings to factory settings. NVSAVE //saves boot settings. NVLOAD //loads saved boot settings. PING - PING ip_address timeout //sends a ping request to specified IP addresses. SELFTEST //perform tests on the client. SELFTEST MONSET – SELFTEST MONSET monitor_resolution_number //change the display resolution.
ROM Issues
In total there where about 32 terminals but only about 7 where set up. It seemed to be a fluke that there was only one with an actual ROM option installed. The people who supplied the systems did not test these machines prior to HOPE, and by chance, their image of the ROM was corrupted somehow. DualD checked what he could on the DEC server which was running OpenVMS. BOOTP was the way they tried to boot everything, however that was not going to work seeming how the binary was hosed.
Unfortunatly, there was not much in the way of solving the issue through that avenue of approach. So one of the people in charge of the "Terminal Cluster" thought that some how we could get the firmware off the ROM and upload it to a machine running Fedora, which we where using to host remote applications for the one system we did get working. What we essentially wanted to do is get access to the files on the client such as [os.500] then trying to send data through TFTP so we could repair the broken firmware on the server. However all attempts failed.
Getting Into X
BOOT> BOOT ROM // This booted the client off the installed ROM and, after a quick nap, boots into X
Settings While In X
After loading X, CTRL + ALT + BREAK brings up a system menu
Setup Console Lock Screen TekHostMenu Host Connections Window Manager Quit
Setup //This was for configuring all the different services, network settings and client settings. Console //Event monitor. Lock Screen //Does just that. TekHostMenu //4 different remote clients. XDMCP VMS TCP/IP TELNET WinDD Host Connections //3 quick links for remote clients. Navio TELNET WinDD Window Manager //2 different GUIs. TWM XPWM Quit //Does just that.
In all, this was a fun hack... even though we didn't get the rest of the 32 other boxes running, we still managed to get further in functionality and learn more about the system in general than the people who brought it. Now when we come upon a terminal similar to this, we'll have a better idea of what steps to take when approaching a problem.
