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
Friday, June 29, 2007
Thursday, June 28, 2007
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 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.
Monday, June 25, 2007
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.
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.
Tuesday, June 19, 2007
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.
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.
Saturday, June 16, 2007
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).
Friday, June 15, 2007
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.
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.
Subscribe to:
Posts (Atom)