OLSRd

Since getting an Atheros card on the gumstix appears to be impossible, I've been looking at other possibilities to get mesh going. Mark pointed out that if necessary we can have 2 cards in the gumstix and we can have a usb hub (so we still get storage). The new approach is to use OLSRd on the gumstix for the mesh and write a few scripts/programs to scan for APs, associate with an AP if it connects to the internet and advertise that to everyone else or connect to a mesh node AP if there are no other options. All of this can be done with shell scripts or perl (or we can do it with Ruby like the Merakis, but perl seems easier).

Today I'm putting together everything necessary and hopefully gonna get a chance to try it out. I need hostapd (to run an AP) and olsrd (to run mesh). We're gonna stick with the prism2 cards and the hostap drivers, since if we can have an interface running an AP and an interface running in Managed mode, out problem is resolved.

A useful guide I found to OLSR: http://tldp.org/HOWTO/OLSR-IPv6-HOWTO/olsrlinux.html

end of roofnet on gumstix

There is no way to get an atheros card on the gumstix. The CF bus is 8/16 bit wide and the atheros cards are all 32-bit Cardbus. The other option was to use the usb port on the verdex, but that won't work since the only available driver is NDISwrapper, which does not support any modes, but managed and ad-hoc.

The last possible solution is to put two gumstix together connected by an ethernet x-over cable and forward packets from the AP to the mesh node. The power consumption that way would be less than the meraki and we have direct control of what is turned on and can add storage to either one or both gumstix. I think it may actually be the best option at the time.

The verdex board

I tried to follow the same route to get roofnet to work on the verdex, but modifying the patches to work with linux 2.6.19 on the verdex has proven to be quite difficult. I managed to get the kernel to compile, but then errors would appear during compiling of various packages. The one I could not get around was compiling ncurses 5.5. I also tried various revisions to see if older packages would compile fine, but no such luck.

Then I took a slightly different approach and tried to modify the patches for roofnet. In the end I was able to compile a working kernel, but it did not support pcmcia. Now I'm trying to compile a revision known to support CF/PCMCIA with the click patches. I have to repatch the kernel, this time modifying the 2.6.16 patches.

roofnet is running

Finally, I was able to get roofnet to run. Editing the shell script to use the iwconfig/prism2_param was fairly straightforward. I ended up putting the card in monitor mode type 2, which resolved the issue of not being able to receive packets. Currently, when click is run, the interfaces are created and it appears that everything is set up. Next step is to test roofnet on two gumstix. I created a rootfs image to drop on them, which should make it go smoothly. I will test this tomorrow. Hopefully it will work. I would also like to have tcpdump on the stix. I'll throw that on tomorrow to see what packets are transmitted.

The only output from click currently is the notice that interfaces went into promiscuous mode and the cryptic "expensive Packet::push; have 4 wanted 32". Not sure what it refers to. Appears to be a statement about transmitting a packet.

TinyOS

Yesterday I picked up TinyOS and spent most of the day getting the environment running. Today I started working with NesC and experimenting with tutorial code. I got radio communication running between telosb motes. I started working with with a set of tinynodes to try and establish radio communication, but have run into a problem where the older v1.1 node will send and receive packets, but the v1.2.1 nodes will not receive packets. So far I haven't been able to determine the difference between the node revisions, and don't know why Rx fails. Specifically, the receive event of the two interfaces I tried (Receive and Snooper) fails to fire, even though both active nodes succeed in sending packets out.

patched kernel

I managed to compile the 2.6.19 kernel for the gumstix and apply the click patch. I ended up going manually through a number of gumstix patches for the 2.6.18 kernel and throwing out the hunks that were already patched. I then tried to run the config file and pipe the output to click. That failed miserably as it relies on the "wlanconfig" tool from madwifi to create all the devices. I tried compiling madwifi tools and putting them on gumstix, but to no avail, as wlanconfig did not work with the hostap driver. I will try to read the config script next and do all the steps with the hostap configuration tools (or wireless tools).

gumstix kernel and click

In order to get click to run on the gumstix I realized I need to patch the gumstix kernel. Forcing gumstix to use a particular kernel does not work very well, as gumstix come only with patches for particular versions. To force a version one could edit the file target/device/Gumstix/basix-connex/linux.mk.

The hostap driver does actually work with the card we would like to use (WCF12), but our card was busted. Everything appears to be working with the host ap driver (wireless tools shows it and it created an ap interface and a regular one). I'll try to figure out what, if any kernel will work.

wireless at last

Once I figured out how to compile the driver (see the edit in the previous post), things went quite a bit smoother. I created a new image of the root file system that includes the modules, threw it on gumstix, loaded the modules with modprobe and was able to associate with an AP and ping google (the ultimate test of every network connection :P). In the process I also ended up setting up NFS which was very easy on gumstix. I followed the gumstix wiki about that: http://docwiki.gumstix.org/NFS, but one thing I would suggest adding to the mount is the soft option, otherwise gumstix may lock up when there is a file request and a timeout occurs. Tomorrow I'll try to throw in the host_ap drivers and see how well roofnet/click will run on the device. After that lots of roofnet code hacking. Not looking forward to it: seems a bit daunting.

wlan-ng and wcf11/12

Well, apparently cross compiling wlan-ng for arm is not as simple as it looks. For one the configure script does not prompt for the option altogether and one can manually add it in. The trick is that apparently when making that option is ignored. After looking up errors on google I ended up compiling the damn thing with:

make ARCH=arm CFLAGS+=$(call cc-option,-mapcs-32,$(call cc-option,-mabi=apcs-gnu),) $(call cc-option,-mno-thumb-interwork,) CC=/home/timur/C++/gumstix-buildroot/build_arm_nofpu/staging_dir/bin/arm-linux-gcc LD=/home/timur/C++/gumstix-buildroot/build_arm_nofpu/staging_dir/bin/arm-linux-ld

What should be used and does not require other adjustments is:
make ARCH=arm CROSS_COMPILE=arm-linux-

This does not result in any errors, assuming kernel source and the cross compiler are available. If only it were mentioned somewhere :)
Compile with the same cross compiler as the kernel, otherwise strange errors may appear when loading the modules

gumstix and roofnet

Today we connected to the gumstix over the serial cable and figured out how to flash the device and setup a new root file system. We have compiled roofnet/click for gumstix, configured busybox to provide the necessary tools for future work and setup the image over the serial line. We have also set the wired network interface to be available on a static IP address, which should not cause any issues in the future.

fixed a small bug and found another

In the CVS version from fs.net there is a small bug in the version 1.14 of the library in the str2file function call. Essentially, the parameter to the mydirname function call was incorrect. Here is the diff file from it:
Index: str2file.C
===================================================================
RCS file: /cvs/sfs1/async/str2file.C,v
retrieving revision 1.14
diff -b -u -r1.14 str2file.C
--- str2file.C 16 Dec 2006 03:44:33 -0000 1.14
+++ str2file.C 8 Jun 2007 18:49:16 -0000
@@ -105,7 +105,7 @@
if (fd <>
return false;

- str dir = mydirname (s);
+ str dir = mydirname (file);
int dirfd = open (dir, O_RDONLY, 0);
if (dirfd <>
warn ("%s: %m\n", dir.cstr ());

I submitted the patch to the mailing list and hopefully that will be patched soon.
The other bug is in the sfsauthd daemon. When trying to register a key it quits with an EOF error. I have not been able to track down where exactly the error occurs, but hopefully it's another typo.

In the future I will be working with sensor networks rather than file systems but hopefully I will come back to sfs in the fall.

sfs adventure

Today I worked on setting up SFS. I got the client installed from the debian testing tree on my laptop and verified it works correctly.

Compiling the server side has been more difficult. The sfskey does not seem to be running correctly as it manages to generate a key but then it does not save it. I will try looking at the source code to find the issue, which I think would be pretty obvious, as the error supplied is "file not found." It seems that there is a small bug where they may be opening a wrong file(?). I hope to have this done tomorrow.

I also subscribed to the sfs mailing list and asked whether cvsweb could be fixed as it'd be much easier to browse the repository, but that will not be a big deal.

Goals for tomorrow:
1. get sfs running fine on the server
2. find the proxy re-signature version of the library
3. begin working on integrating it with the existing code.

Day 1

Today I read a paper on another way of implementing access sharing: Ciphertext-Policy Attribute-Based Encryption. The paper outlined how access trees could be used to implement user access control to content. The idea is that each user possesses a number of attributes which a publisher of the content can use to create an access list to allow only users whose attributes satisfy the tree. The tree can include gates at nodes, such as AND, OR, etc, to allow more flexibility. The scheme has the same drawback as WISPR as there is no flexible way of revocation, aside from temporally bound access trees.

I also read the paper describing the file system I will be working with: Separating key management from file system security. I began to look through the documentation available about the filesystem (SFS) in order to begin setting it up tomorrow. In order to set it up I will need to build it on cusp and then try to look into including the proxy re-signature portion back into it.