Making a WANRay

The basic problem that I had was to get my SunRay client working from home. With this is place, I could simply take my smart card and resume work at home. Plus, I would get the added benefit of appearing to be on-campus and would avoid all of the headaches of transferring files/etc. In other words, make the rumored WANRay from Sun without actually waiting for Sun to come out with a WAN-friendly thin client.

My setup has included WAN access at home via both ComCast? and AT&T. A typical setup at home includes a wireless router (NetGear? , Belkin, etc.) with multiple computers, a TiVO? , and now a Wii all connected internally across a local network.

Problem 1: Helping the SunRay find the SunRay server

The first problem to overcome is how to get the SunRay to figure out about the server. With the SunRay having not only overcome a NAT but also being considerable hops away from the server, the standard bootp/discovery option was just plain out. Hence, I would need to set up a DHCP server to fan out the SunRay options correctly. Unfortunately, the SunRay server manual is a bit less than clear on how to do this. It lists the options but basically states in a nutshell that ?Encapsulated options are hard, good luck." Future versions of the SunRay manual have not offered too much of an improvement since my original discovery of these magic options. For my case where I only admin my own cluster of boxes in my lab, this left quite a bit to be desired.

After a bit of searching, I finally located an example dhcpd.conf that would properly distribute the SunRay client info. While the firmware revision is of course off, this is a huge step in the right direction, leaving me only to fill in my server IP address.

=== Example dhcpd.conf for SunRay client ====

ddns-update-style none;
deny unknown-clients;
allow bootp;
subnet 192.168.1.0 netmask 255.255.255.0 {
    authoritative;
option routers 192.168.1.1;
option default-ip-ttl 32;
     host SunRay-NDSS-2 {
          hardware ethernet XX:XX:XX:XX:XX:XX;
          fixed-address  192.168.1.180;
          netmask 255.255.0.0;
     }
}
option space SUNW-NewT;
option SUNW-NewT.AuthSrvr code 21 = ip-address;
option SUNW-NewT.AuthPort code 22 = unsigned integer 16;
option SUNW-NewT.NewTVer code 23 = text;
option SUNW-NewT.LogHost code 24 = ip-address;
option SUNW-NewT.LogKern code 25 = unsigned integer 8;
option SUNW-NewT.LogNet code 26 = unsigned integer 8;
option SUNW-NewT.LogUSB code 27 = unsigned integer 8;
option SUNW-NewT.LogVid code 28 = unsigned integer 8;
option SUNW-NewT.LogAppl code 29 = unsigned integer 8;
option SUNW-NewT.FWSrvr code 31 = ip-address;
option SUNW-NewT.Intf code 33 = text;
class "vendor-classes" {
  match option vendor-class-identifier;
}
subclass "vendor-classes" "SUNW.NewT.SUNW" {
  vendor-option-space SUNW-NewT;
  option SUNW-NewT.AuthSrvr XXX.XX.XX.XXX;
}

The key points that you would need to customize are:

• The netmask/subnet and the Ethernet address of the client.
• Authoritative must be present to override any other DHCP clients.
• Change the AuthSrvr? and Routers option appropriately.
• Make sure your SunRay is in the DMZ for your local network

To get a DHCP server running, you can choose a couple of options. I used the stock RedHat? Linux DHCP server for testing:

%dhcpd -d

The -d flag puts you into debug mode (quite helpful). I also got DHCP running under Cygwin in Windows. This is a bit trickier as you need to apply a patch but this also worked just fine. The key is that the SunRay simply needs to find the server, once it knows about the server, it will do just fine. Keep in mind that you will likely need to do a bit of firewall-foo on your SunRay server to allow the SunRay device to connect.