Wyse 3125SE: Development 




Development Environment | Development Process |


This is a description of the hardware setup I use for developing/testing software for Wyse thin clients that use NetXfer as their firmware upgrade method. This includes the Compaq Evo T20 and T30, the Wyse WT3125SE and the Wyse WT3235LE. (There are others).

With NetXfer, if you power-on the thin client and tap the P key on the keyboard, the client looks for a DHCP server on port 10067 and then will download a file from a TFTP server running on port 10069. The advantage of using the high numbered non-standard ports means that we can set this up on a normal local LAN and don't have to set up a special development LAN.

What you need

What's required is really quite simple:

  1. A computer to act as a development machine.
  2. The kernel source files.
  3. An initrd to go with the above.
  4. An original Compaq/Wyse firmware file for your particular model.
  5. A compiler to build a custom kernel.
  6. A DHCP server/SFTP server to download files to the thin client
  7. Software to package up the kernel/initrd.

Looking at these in turn.

(1) Life is easier (at least I think so) if you're running Linux on your development machine. If your main system is running Windows you could set something up within it (the old Wyse NetXfer software ran on a Windows platform), but I would recommend you either:

  • Install something like Virtual Box or the Microsoft Virtual PC that will let you run an instance of Linux within a virtual machine on your system.


  • Use a separate box.

Many Linux distributions will run quite happily on old computers that have been 'retired' thanks to the increasing demands on computing power that each new release of Windows seems to require. I'm currently using an old(?) IBM Thinkpad PC that is modern enough to have a dual-core processor. (Previously it was an old Shuttle computer using a P4 with Hyper Threading). At the time of writing the IBM is running Fedora Core 16. It will build a customised kernel in under 4 minutes.

For [2] & [3] I use the Tiny Core Linux distribution.

[4] can be found on either the HP or Wyse support sites.

[5] & [6] can be downloaded and installed on your development machine from that distribution's app repository.

For [7] I've written a program that greatly simplifies this task. (It's downloadable from this site)

What's nice to have

A NULL modem serial cable.

This is very useful - unless you're working on the Evo T20 which has no serial port. I use it to connect the thin client's serial port to a serial port on my development machine. My kernels are initially built with command line which includes entries of:


The serial connection is not essential but is highly recommended for use in the early stages of your kernel development cycle. At this stage you may have no screen output, or if you do, the system messages can be scrolled off the top of the screen before you have time to read them. If you don't get as far as a logon prompt you can't view the full contents of the log file.

Whilst you can configure the kernel to send debug messages over the LAN by using the 'Netconsole' feature, these messages only appear once the ethernet interface is up and running. If things go wrong before that point you see nothing - which provides zero help in finding the problem! Also you may need to sort out problems with the initialisation scripts that bring the system up. Again, without a console you'll be in trouble. Once, when I had no working console, I ended up adding a printk statement in the execve system call so that I could track the sequence of commands that init was running.

You can find 'null modem' cables on ebay for a couple of pounds - make sure that they are 'null modem' cables as some of the female-to-female cables on offer are wired straight through and are intended for use as cable extenders/gender changers.

Connecting it up

Wyse/Compaq development setup

This is simplicity itself. Just plug both in to your local LAN.


Configuration is straight forward. Essentially we have to do four things:

  • Restrict the range of our standard DHCP server.
  • Run another DHCP server on port 10067.
  • Run a TFTP server on port 10069.
  • Update the firewall rules.

Main DCHP Server

The DHCP server on my local LAN is embedded in the Netgear router that provides the interface to the outside world. All it does is serve up IP addresses and can't be configured to do anything else - like provide the name of a TFTP server. I've set it to use addresses in the range so that I'm free to use addresses from .100 upwards without fear of any conflict. It was a simple matter to configure this through the management interface.

Development DHCP Server

I used Fedora's "Add/Remove Software" option to download and install a DHCP server on the development system. By default the dhcp server uses the configuration file /etc/dhcpd.conf. We use this file to tell it:

  • the range of IP addresses it should use
  • the file name (bootp.bin) that it needs to pass to the thin client
  • the name/address of the SFTP server to download the file from.

A small problem here is that my Netgear router, whilst happily handing out IP addresses and noting the names of the machines it has handed them out to, does not actually run a DNS server. All DNS requests are passed straight out to my ISP's DNS service. This means that if we set the next-server field to hammerhead (the name of my development machine) the thin client just gets a 'not found' response to its DNS query when trying to get the address of the SFTP server. We have to use the actual IP address in the next-server field - which gives the problem of how to set the right address. (Remember the address has been handed out by the Netgear DHCP server and could be anywhere in the configured address range).

Previously I addressed the problem by running the development machine with a fixed IP address. This time I've written a script that puts the right address in the DHCP's configuration file. (See further down)

My configuration file looks like this:

# dhcpd.conf
# Sample configuration file for ISC dhcpd

default-lease-time 120;
max-lease-time 120;
server-name "hammerhead";
option domain-name-servers;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# This is a very basic subnet declaration.

subnet netmask {
 local-port 10067;
 range dynamic-bootp;
 option routers;
 filename "bootp.bin";

TFTP Server

The TFTP daemon normally runs under xinetd, but when I tried this I found I was unable to specify the ports that it uses without editing the system file /etc/services which I preferred to leave untouched. The -a switch only seems to work in conjunction with the -l switch (run a local copy) so I gave up the idea of having it started via the standard services and xinetd. It's handled using the simple script shown later.

Serial Port

You'll need a suitable communications program to use with the serial port. Whilst I used CuteCom to start off with I found it much more convenient to use Putty, the source of which can be downloaded from here. (Putty does support direct connection to a COM port as well as the more usual network connections). Unlike Putty, CuteCom is not a terminal emulator. This means the display gets a bit messy when the initialisation scripts run and spit out the various escape sequences that change the colour of the font. Putty acts as a proper console.

One final issue with Fedora is that, by default, the permissions on the serial port are such that it cannot be opened by a normal user. One more line in the startup script fixes this.

Starting the servers

I use a very simple script which lacks the sophistication of the from Karl Mowatt-Wilson. I normally work logged in as user thin and put files for download in /home/thin/ftp/ so my script is just:

# Script to start our NetXfer server

# For this to work we need to be root

if [[ $UID -ne 0 ]]; then
    echo "$0 must be run as root"
    exit 1

# As we're running with an IP address handed out by the DHCP server
# we need to ensure that the correct IP address is set in our
# dhcpd.conf file.

# First determine what IP address we've been given.

IP=${IP#*inet addr:}
IP=${IP%% *}
echo $hostname ip address is: $IP

# Update the DHCP configuration file to reflect this address

sed -i -e "/next-server/s/[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+/$IP/" /etc/dhcp/dhcpd.conf

#start the servers

dhcpd -p 10067
/usr/sbin/in.tftpd -l -a:10069 -s /home/thin/ftp

# We also need to access the serial port

chmod 666 /dev/ttyS*

I've created a local bin directory in 'thin's home directory. This is where I store the start_servers script file and various other programs I use (such as makebootp).


You either love them or hate them. If you have one in place then remember to open up the ports for the services you are using. In my case I ensured ssh was enabled and added under 'other ports':

10067 udp
10069 udp
6666 udp

The first two are for the DHCP/SFTP whilst the last is for the netconsole should you decide to use it.


Any comments? email me.    Last update January 2012