[Cu-wireless] wireless development needs

[David Young]

People have asked, so here are some important development needs for the
wireless network.

* 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
  <http://www.linuxfocus.org/English/July2002/article239.shtml>.

* 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
  a proposal?

* 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
  is important....

* 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.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933