building dtn

Dave's guide for DTN has been quite useful. A lot of the patches actually already appear in the later revision of the gumstix though. I had to add -ltcl8.4 to the LIBS in Rules.make in oasys to get liboasys to compile, thus getting dtn to compile. Everything else seems to compile fine.

DTN2

Since AP and OLSR appear to be running as expected, I was looking into how to setup store and forward. It appears that the route to take is to try to setup DTN2. After reading RFC4838, I realized that DTN runs on top of the transport layer, which means that OLSR can still do the routing and a DTN daemon on top can handle broken/disconnected links and store the data if a link is not available. I found a few explanations as to how to set it up and I will try to have DTN setup today.

dhcpd and dyn_gw

I have setup DHCPd on the verdex board and it appears I can communicate with the board fine. I have one more test to see if I can setup a simple two hop network and check if I can see the dhcp clients on a different subnet, which are not running OLSR. Hopefully, it will work fine. For dynamic gateway operation I used the dyn_gw_plain plugin, which seems to work fine. We have to toggle the interface manually, i.e. bring it up and down, but it detects such changes. The script to scan for access points and verify connectivity seems to be working fine now as well.

Ad-Hoc

Ok, Ming pointed out that running nodes in Ad-Hoc mode will make a lot more sense, since OLSR will take care of loops and can use signal strength to find the best route to a node. The script to scan for access points and associate with them was almost finished, but then I found linux-wlan-ng support wireless extensions if "options p80211 wlan_wext_write=1" is added to modprobe.conf. I will modify the script today and see if it works correctly. The next step is to get the dynamic gateway plugin to work. Last time I tried to use it, it segfaulted, but I have not looked into why too much. Worst case scenario I think I can put together a hack to do the same thing.

OLSR power consumption on gumstix

We set up a small circuit (thank you Matt) to measure the power consumption of the verdex board while running OLSR. We put a small, .5 Ohm resistor in series between the DC voltage generator and the board and measured the voltage drop. From my calculations the power consumed by the board at different stages is as follows:

	Voltage	Current	Power
Compact flash in	0.04	0.08	0.42
Connected USB	0.05	0.09	0.46
Loaded the PCMCIA driver	0.04	0.08	0.39
Loaded the USB driver	0.04	0.08	0.39
Started AP	0.06	0.13	0.64
Associated with an AP. Started OLSRd	0.09	0.17	0.86

Thus, our consumption with OLSR running is roughly .9W, which is not terrible and I will talk to Jeremy about getting solar panels to support this. We still need to duty cycle and have a way to scan for APs and to set the association and links appropriately. I will start writing the script today and I'm meeting with Deepak, Jeremy, and Devesh to figure out how this will be packaged.

more olsrd news

Well, it definitely works now! I'm browsing the web through the two gumstix OLSR nodes I set up. I still think that the D-Link card was flaky and right now I'm using the Linksys WCF-11 Card. For the 2.6.18 kernel a small patch has to be added to linux/drivers/net/wireless/hostap/hostap_cs.c. Essentially, add PCMCIA_DEVICE_MANF_CARD(0x0274, 0x3301) to static struct pcmcia_device_id hostap_cs_ids[]. I created a patch to do it for that particular kernel if anyone's interested, but like I said, it's very easy.

Now, I have multiple topics to choose from for possible directions:
1. I could start writing the "brain" script in something like perl or as a shell script
2. I could start working on duty cycling with tiny nodes

I think I'm gonna get some hot chocolate first to celebrate and then talk with Deepak about the direction.

Last thing, to reduce packet loss I used the firmware TX rate control. You can set it with iwpriv iface txratectrl 1 (0 is to use driver's tx control). You can also find more information about the driver online: http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/hostap/Attic/README.prism2?rev=HEAD

let there be mesh

Finally got mesh networking to work, if only for a short while. The configuration I setup was as follows: node A was a verdex board with a netstix and a usb hub connected to it. I put in a D-Link CF card and a D-Link usb card. Node B was a connex board with a CF Linksys card and connected to a router with internet access through ethernet. The last piece in the setup was my laptop which connected to node A. Both of the CF cards acted as access points, with different ESSIDs. The usb card acted as a client connecting node A to B. I ran OLSR on both of the nodes and successfully telnetted to 128.119.101.5 (umass page) and retrieved index.html, which apparently did not exist, so I retrieved a 404 message :). The connecting was done of my laptop. To configure the routes OLSR took maybe 2-3 seconds. I had to specify the AP as a default gateway for all traffic on the laptop, but that seems a natural step either way. The subnet configuration was as follows: Laptop and node A AP were on 192.168.1.0/24, node A to node B on 192.168.2.0/24, and node B to the router on 192.168.4.0/24. The router ran a dhcp server. The rest of IPs were configured manually but a DHCP server could be setup with each access point.

This setup worked until I called Deepak to check it out, of course that's when it stopped working. The moment I would try to reach the D-Link access point, I would be disassociated from the AP. I will go back and try to figure it out tomorrow. Overall though, OLSR was very easy to set up, and we should've used it to begin with.