Logo

Wyse 3150SE: Development 

Overview

This outlines my local system and how to configure things to enable new code to be downloaded to the WT3150SE.

Whilst it is possible to just do things on a single Windows computer, having a separate Linux system does have its benefits. 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. Alternatively you can use VMware or the Microsoft Virtual PC to run more than one operating system on your main PC.

Unlike the earlier Wyse thin clients the WT3150SE uses Wyse's WSI (Wyse Simple Imager) system rather than Netxfer for system management. (NB: WSI is now 'retired' and the recommended management tool is WDM - the Wyse Device Manager). I couldn't find any on-line explanation as to exactly how WSI works, but the WT3150SE does start by trying to boot from the network (PXE). My options appeared to be to find another computer and install Windows and WSI on it or to slightly extend my existing development setup. I chose the latter route. (However I did try the former route - but only briefly and without success).

With PXE booting the WT3150SE needs to be provided with the name of a file to load and run. This is provided by the DHCP server along with the unit's IP address in response to a DHCP request. In my particular setup the DHCP server on my local LAN is embedded in a Netgear router and doesn't offer such options in its administration menus. Also my searches did not reveal any special key combination that would make the WT3150SE use alternative ports for its DHCP requests. This meant that I'd have to create a separate LAN for WT3150SE so that I could set up my own DHCP server and management environment. Luckily my Linux box already had a second ethernet port fitted, and digging in my box of cables I found I had an ethernet cross-over cable and so could connect the WT3150Se directly to the second port. (The alternative would have been to have found a simple ethernet hub and a couple of conventional cables).

The setup is shown in the diagram on the right. network

This also has the side benefit that I could run the network monitoring program Wireshark on my Linux box to directly monitor the network traffic between the WT3150SE and my DHCP/TFTP server.

Gateway

A quick attempt to set something up was not very successful. To start with the DCHP daemon bombed out with a misleading message about my failure to define a subnet in its config file. This was a blatant lie and the cause was actually that the eth1 interface was not enabled. (Both eth0 and eth1 seemed to enable/disable themselves at will...). After a few other hiccups I decided to be more methodical about it.

Essentially what I did was to set up a gateway between two LANS - my normal home LAN and the new 'WSI' LAN. There are various guides on the net about how to set up a gateway machine, but most are overly complex as they assume you're setting up a gateway between your home network and the big bad world of the Internet. In this case it's all within the same trusted environment and so there is no need for any complex firewalling.

What follows is what I did for a Fedora Core 11 system. Other systems may (or may not!) have similar configuration files, but at least it should show you the steps you need to take. It turned out to be remarkably simple!

Addressing

My main subnet is in the 192.168.10.xx range. I decided to set up the new network in the 192.168.1.xx range.

Hardware

I already had a second (unused) ethernet port on a PCI expansion card. You may have to fit such a card. My existing network has eth0 connected to my local LAN and so I used eth1 for the new LAN. You can either use the management tools to set this up or edit the configuration file directly. I set the eth1 interface to a fixed IP address of 192.168.1.1. (If you play with WSI or WDM on a Windows system this interface apparently has to be set to an IP address of 10.1.1.12).

As I progressed with the set up I found that I'd managed to lose Internet connectivity. On checking what the kernel was up to I found that the internal routing tables were:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.10.1    *               255.255.255.255 UH    0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     1      0        0 eth1
192.168.10.0    *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     1002   0        0 eth0
default         192.168.10.1    0.0.0.0         UG    0      0        0 eth1

Note: Just type route at a system prompt to see this information.

After spending a little while trying to sort out what was going on and what series of commands I needed to get the routing right I discovered that the solution was actually very trivial - just untick the configuration box that said that interface eth1 was managed by Network Manager! With that small change all my problems went away. The main routing table stayed as it should be, and an extra entry appeared for the 192.168.1.0 subnet on eth1.

At this stage the routing table looked like this:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
192.168.10.0    *               255.255.255.0   U     0      0        0 eth0
default         www.routerlogin 0.0.0.0         UG    0      0        0 eth0

where www.routerlogin is how my Netgear router (@ 192.168.10.1) identifies itself.

This is fine for the initial tests as with it you can run the DHCP server on the eth1 interface and also use TFTP to deliver the kernel files. However the local LAN 192.168.1.0/24 is isolated from the main network and some further configuration is needed in order for the WT3150SE to be able to see the Internet. You don't need to set this up immediately. It may be better to get the fundamentals working first and then come back at the end to set up this bit up.

Forwarding and NAT

Whilst we can set the Linux box up to pass packets between the two ethernet interfaces, this doesn't get us very far as the network router ignores packets from addresses that do not lie in its own subnet. To get round this we need to set up the Linux box to perform a simple task for us - Network Address Translation (NAT). Essentially it will forward packets from the WSI LAN to the main LAN, but replace the originating address by its own (in the 192.168.10.0 subnet) and does the opposite in the reverse direction - replaces the destination address with that belonging to the WT3150.

Step 1 is to enable IP forwarding. You can see if it is already on using the sysctl command:

# sysctl net.ipv4.ip_forward
sysctl net.ipv4.ip_forward = 0

It returns 0 if its is off or 1 if it is on. You can turn it on with the command:

# sysctl -w net.ipv4.ip_forward=1

Or to make it permanent you need to edit the file /etc/sysctl.conf and add (or edit) the line:

sysctl net.ipv4.ip_forward = 1

Any time you play with network settings you'll probably need to restart the networking sub-system so that they take effect. In Fedora it's the command /etc/init.d/network restart that does this:

# /etc/init.d/network restart
Shutting down interface eth0:                               [  OK  ]
Shutting down interface eth1:                               [  OK  ]
Shutting down loopback interface:                           [  OK  ]
Disabling IPv4 packet forwarding:  net.ipv4.ip_forward = 0
                                                            [  OK  ]
Bringing up loopback interface:                             [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0... done.
                                                            [  OK  ]
Bringing up interface eth1:                                 [  OK  ]

Finally you need to set up the forwarding Rules in IPTables:

iptables -A FORWARD -i eth1 -o eth0 -s 192.168.10.0/24 -m state --state NEW -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE

I added the above lines to my startup script for the WT3150 development environment.

Software

We need to run a DHCP server and TFTP server. I covered the basic installation of this software on my Evo T20 pages.

DHCP

By default the DHCP server uses the configuration file /etc/dhcpd.conf. I copied my existing file to /etc/dhcp/dhcpd-eth1.conf and changed it to:

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#   see 'man 5 dhcpd.conf'
#

default-lease-time 120;
max-lease-time 120;
server-name "ptowers";
option domain-name "wsi.local";
option domain-name-servers 192.168.10.1;

log-facility local7;

subnet 192.168.1.0 netmask 255.255.255.0{
 range dynamic-bootp 192.168.1.200 192.168.1.240;
 option routers 192.168.1.1;
 filename "bootp.bin";
next-server 192.168.1.1;
}

Note: The option domain-name-servers is pointing at my Netgear router. This cannot actually be reached until the port forwarding/NAT is set up.

With PXE booting there are a whole host of options that you can set up. I've ignored them all and the simple configuration above works for me.

TFTP Server

There is nothing new that we need to do for this.

Starting the servers

Once again I use a very simple script to start the servers. We need to tell DHCP where its files are and which interface to run on and TFTP needs to know where the root directory is for the files its going to serve. The full script is:

#!/bin/sh

# Ensure the leases file exists
touch /tmp/leases-eth1

# Start the DHCP server and TFTP server

dhcpd -cf /etc/dhcp/dhcpd-eth1.conf -lf /tmp/leases-eth1 eth1
in.tftp -l -s /home/thin/tftp/

# Setup forwarding and NAT between the interfaces.

iptables -A FORWARD -i eth1 -o eth0 -s 192.168.10.0/24 -m state --state NEW -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE

You may like to expand on the above and for example insert checks to ensure you don't start multiple instances of the servers. It's not a bullet-proof script - but it works for me!

 


Any comments? email me.    Last update May 2010