The Access Grid (AG) priovieds a global infrastrucutre to provide high quality audio and video conferencing using multicast networking, a Java based middle-ware, and the Internet2 backbone. Toby Ho and myself were introduced to the basic operation of the Access Grid middle-ware applications by Matt Wolf. From that introduction, we produced a simple intorduction document (see ' Access Grid Introduction' on the swiki)
After the first introduction to the AG, I worked with Matt test out the AG components on the iPAQ. The first thing needed as to test the JVM's available for the iPAQ (for the middleware applications). I did some successful basic testing with the Blackdown 1.3 JVM (available from ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/JDK-1.3.1/arm/), but furthure testing is needed, particularly with GUI applications.
Next, I was able to compile RAT (the audio tool used by the AG) successfully on the iPAQ, but was not able to get it to recognize the audio device. I am still investigating some solutions to this. Matt ran into a similar problem with RAT on OSX.
As RAT and the AG use multicast networking, the stock Familiar kernel had to be modified to support multicast. This was tricial and was added to the custom kernel I compiled with the FreeS/WAN patches (see the iPAQ Security section below).
These items remain:
In order to help administor the AG components, Matt and I discussed a monitoring application/script using the Beacon Server (a server that moitors multicast network health of participating AG nodes on a network/Internet). This script would potentialy pull network stats from a local beacon server and notify the appropriate personal in the event of any networking issues.
Due to time contraints, I was not able to do much more on this. The first step is to examine the available information output from the beacon server (flat test file output is available - from what I was told) and see if the information needed is available. If so, then a simple script to parse that output, check for vaules out of range and email the configured admins should be trivial to write.
My work with the Compaq iPAQ this Summer was focused on designing and implementing a secure infrastructure to allow the iPAQ to access NFS resources in the CoC over the 802.11b Tech campus LAWN wireless system. This involved setting up a stable environment on the iPAQ for kernel development and then augmenting that configuration to use a FreeS/WAN IPSEC tunnel. Over this tunnel, the iPAQ's will be able to access the CoC NFS resources needed for a full development environment.
The first order of business was to work with the available linux software for the iPAQ and determine what to use for the local environment. Luckily, the Familiar project took care of all the deatils and provideded a stable environment for the iPAQ. This included the 2.4.3 kernel with all the appropriate arm/h3600 patches (other versions available from cvs.handhelds.org), a writable flash file system (JFFS2 - not read only like CRAMFS), PCMCIA support w/ wavelan drivers, and a package management system (ipkg). See the Familiar project site for more details.
Familiar provided the base system for the iPAQ to run locally, but did not provide the full development environment we needed for the cs3210 class. In comes the Intimate distribution. This is a companion to Familiar and was originally disigned to run on a microdrive running off the iPAQ's sleeve. It does thie by booting into familiar and the running the 'pivot_root' command into the mounted microdrive and running 'init' from there. It is possible, however, to also run this over NFS by simply specifying an NFS mount point to 'pivot_root'. This provided a degree of flexiablity much better than the old nfsroot method and allows for the creation of a IPSECtunnel prior to NFS access.
The Intimate distrobution is essentially the debian arm distro from the unstalbe branch. It has full dpkg support with all the goodies that come with apt-get. A full development environment is then possible, along with anything else you can find a .dep for. See the Intimate project site for more details.
For the details of the Familiar and Intimate setup I used, see the following documents:
The next step was to find a way to automate the currnet LAWN authentication, which requires each user login via a HTTPS/SSL based website before allowing any network access (other than a dhcp address). As a easy and quicksolution to this problem, I tested the lynx '-post_data' option with the lawn ssl gateway and found that it checked the 'HTTP_REFERER' to make sure that the post came from the login page. Well, this through me a curve, but I looked at the lynx source and found a easy way to patch it so I could hack the HTTP_REFERER string. I am not usualy one to violate the RFC, but what can you do. This worked well and can easily be added to a script file. See my LAWN Access HOW-TO for more details.
For obvious security reasons, placing your password in a plain text file is not he best idea (especially since groups of 3 will be using the iPAQ's for CS3210). As an alternative, I am investigating alternate means of LAWN authentication using a SSL based GUI browser. The QT Palmtop Environment looks to be the most promising, with the Konqueror browser Built with QPE. This is still on the to-do list for the next few weeks. Hopefully, I can test this before school starts back for Fall to see if it will work.
Other references for Konqueror Embedded:
With the LAWN authentication out of the way, we then need to setup the IPSEC tunnel. I am working the Neil Bright with CNS to get staillion@cc setup as a FreeS/WAN gateway. The patch file I used to configure FreeS/WAN on stallion can be found in the /hl2/pebrown/done directory on stallion. This patch was needed to setup the configuraton and binary files in a different location (something else in the FreeS/WAN build system that did not work as I expected).
The iPAQ's will act as "roadwarrior" style clients using RSA digital signatures to authenticate. The diagram below show the configuration: (a better diagram is in the works)
iPAQ ..... LAWN ------ LAWN ------ stallion.cc AP GW NFS/IPSEC
In order to get FreeS/WAN working on the client side (the iPAQ's), I needed to first get the GUN MP Library compiled for the ARM processor. The GMP library is needed for Pluto's public key calculations. Cross-compliing this library is stright forward using the provided configure script. Look here for the latest ARM toolchain. The 'jacques' directory has the most up-to-date cross-tools binaries (see the README.xchain2-i386 file):
The kernel include files used are from the 2.4.6-rmk2-np1-hh4 kernel. binutils-126.96.36.199.24 gcc-20010628 (2.95.4 snapshot) glibc-2.2.2
Next, I made a patch to the FreeS/WAN build system so I could cross-complie with the kernel. You will need to modify the TOPDIR, DESTDIR and KERNELSRC variables to your liking before appliying the patch. This patch was nessecary b/c the build system did not provide an easy way to cross-compile and b/c I ran into some issues with the top level Makefile variables replaced in the sublevel Makefiles. I just added the variables to them all b/c I was in a hurry. Fell free to correct this and let me know.
The remainder of the details of getting the FreeS/WAN tunnel setup can be found in the
FreeS/WAN Setup Guide.
This explains the details above in details and describes what changes was required to
both the Familiar and Intimate NFS setups.
These items remain:
Due to time contraints, I was not able to do anything with the Crestron this summer. I did discuess with Matt Wolf the possibility of using the network port to trigger stored programs. If this is possible (this needs to be verified), then I think we should try to set up a voice recognition gateway that can trigger these programs. This would alow for voice control of the Crestron system.