[Cu-wireless] wireless development needs
dyoung at pobox.com
Thu Jun 19 22:16:38 CDT 2003
People have asked, so here are some important development needs for the
* It would be nice if we could update the software on the wireless network
over the Internet, but also ensure high reliability. One way to
do that is to keep two versions of the software on each node,
one a "fail-safe" copy, the other an experimental copy, and to
modify the standard bootloader so that it works with a watchdog
timer to reboot with the fail-safe copy if the experimental
copy fails. There is a design for a watchdog timer here
* We've had some interference problems that I think we can solve
by changing channels and by changing the carrier sense mode of our
radios from "energy detect" to "carrier detect." Even if we just
change the channel from 10 to 11, I think that the interference
source (a neighbor's 802.11 AP) will look nearly enough like noise
after de-spreading that our radios will not postpone transmissions.
Reception will be better, too. Coordinating a change of channel on a
running network is hard. Will somebody study this problem and make
* We need to be able to produce charts of throughput for each interface.
It would also be nice to see charts of signal and noise levels over
time. Also, we need to monitor link state, and it would be nice to be
able to see a graph of the network topology. If we can see all this on
the web, that's good. I think that MRTG will do this. Will somebody
study that and other open-source alternatives?
* We need to program or adapt a lightweight, easy-to-use, web-based
firewall configurator. There is a product called m0n0wall that might
be a good starting point. Compact implementations in C and/or Bourne
shell are preferred.
* We need a name service for the network. It is desirable for it to
provide names on the Internet and also names for the systems on the
community network. I would like to see some integration of conventional
DNS with Multicast DNS and DNS Service Discovery. Those are emerging
protocols for zero-configuration networking. IETF calls it Zeroconf,
Apple calls it Rendezvous.
The name service will be a daemon running on the routers. It
multicasts some name lookups to other routers, it sends other
lookups to a nameserver on the Internet, and it answers some lookups
using its cache. It would be neat if it would re-advertise certain
zeroconf services that run on a subscriber's subnet (especially
chat---Apple iChat uses Rendezvous) on the wireless network. Security
* I have some ideas for the design of a routing protocol that is
suited to multihop wireless networks, especially 802.11 networks,
which takes measures to protect against self-interference and routing
message overload. It takes a different view of a wireless network than
either OSPF or IETF's experimental ad-hoc protocols do. I will need
lots of help to develop it.
* On our network, the integrity of routing information must be ensured.
For practical and philosophical reasons, it is undesirable to rely on
a central authority for authentication. I would like for subscribers on
our network to be able to carry, e.g., a Java iButton (www.ibutton.com)
on their keychain which contains the credentials for their router.
Two people who trust each other can exchange credentials by touching
iButtons together. When they get home, they can plug their iButton
into their router, which downloads the credentials and uses them to
gauge the trustworthiness of routing information.
* The architecture and APIs of operating systems need some tweaks here
and there to support 802.11 wireless networks. The UNIX abstraction for
a broadcast network does not fit 802.11 very well. Link conditions,
data rate, and privacy options may vary considerably between an AP
and its clients. It is also useful to track statistics separately for
each client. For that reason, I think that an AP should give each
client a virtual point-to-point interface. Ditto peers in an 802.11
ad hoc network. This is pretty high on my list of things to do; NONE
of the other tasks are.
I have been putting a lot of time into getting the C-U Wireless build
environment into kit form, so that you can build your own CD-ROM or
CompactFlash. If you can setup one of your computers to run NetBSD,
you can run the kit. I think that it would not be too hard to adapt
my scripts to do a cross-build on Linux. I am going to see if I cannot
setup a fast NetBSD machine for people to do development on.
David Young OJC Technologies
dyoung at ojctech.com Urbana, IL * (217) 278-3933
More information about the CU-Wireless