[CUWiN-Dev] Post-Summit dev thoughts

[Paul Smith]

On 4/5/06, David Young <dyoung at pobox.com> wrote:
>
> On Tue, Apr 04, 2006 at 04:58:17PM -0500, Paul Smith wrote:
> > Great to see everyone at the Summit this weekend, especially Charles
> (cool
> > bamboo masts, btw) and John and other folks using CUWiNware that I
> hadn't
> > met before.
> >
> > I wanted to start a thread on fleshing out some of the ideas brought up
> in
> > the course of panels and informal chats. Here are some unorganized
> thoughts
> > mostly straight out of my Moleskin.
> >
> ...
>
> Paul,
>
> You will find no disagreement at CUWiN that we need to centralize the
> configuration, fix the persistence bugs, add monitoring, mapping, and
> captive portal, but we need manpower to do all of that.


Part of my motivation for the post was to start identifying all these
pieces, hopefully with enough resolution such that motivated developers
could tackle parts they saw as manageable. And maybe there's a chance to
capitalize on the Summit and renewed interest in CUWiNware.

(BTW, at the same time we are under pressure to add a bunch of new
> features, CUWiN needs to get several megabytes thinner.  At 9-10MB
> compressed, it is already pretty thin, but we should aim for a 4MB
> compressed system.)
>
> With the help of some OSI funding, the node configuration project
> has been resurrected.  Specifically, there is some work underway on
> configuring multiple interfaces.  A list of your requirements in this
> area will be appreciated.


Is this work visible somewhere? I'd be happy to contribute, indeed that kind
of work is more in line with my skill set than say device drivers.

Note that Metrix and others are using WiFiAdmin <
http://wifiadmin.sourceforge.net/>. It's some pretty nasty PHP code, in that
it's very Linux-specific and has no separation between logic and layout (not
a comment on PHP, just how this app was coded), but the interface exposes
most of the knobs I'd like to see. I'll enumerate them here so you don't
have to flip back and forth from the screenshots, and some others:

Some requirements:

Interfaces
- enable/disable
- enable/disable auto CUWiN address scheme (hash(MAC) == IP)
- IP address
- netmask
- gateway
- MTU

Wireless specific
- essid
- mode (hostap/backhaul/client)
- protocol (11a/11g/11b)
- channel
- rate (11 Mbps, etc.)
- RTS
- fragment
- retry limit
- enable/disable WEP (some want it!)
- WEP keys

DHCP server
- enable/disable per interface
- IP start-end range
- netmask
- router(s)
- lease time
- DNS servers
- domain

System
- hostname
- remote logging/logging host
- enable/disable SSH
- SSH public keys

Firewall
- rules
- NAT

Traffic shaping
- QoS
- rules/pipes/queues

To answer some specific remarks:
>
> > I think everyone agrees that configuration is an area that needs some
> > attention. By "configuration" we mean operator control over how
> interfaces
> > are set up, and what information services (dhcpd, etc.) are provided and
> > how. I brought up that currently configuration is spread across several
> > different files and scripts, and that things that should be "runtime"
> are
> > currently only twiddleable at build/compile time. For instance, a dhcpd
> > config template is hard-wired in /sbin/dhcpselect, and the flag for
> enabling
> > it is hard-wired in the /etc/ifconfig.*.tmpl templates. The main config
> > persistance store /etc/cuw_config is a flat-file which I prefer (as
> opposed
> > to say a sqlite db or XML document or some binary store) but is also a
> flat
> > namespace which makes adding data on multiple interfaces, for instance,
> > currently problematic. Mike K described how his wireless system keeps
> its
> > per-node config in a central Internet-addressable MySQL database and the
> > nodes pull down their runtime config at boot, and a "last good" copy of
> the
> > config is kept locally for when the Internet is down. Regardless of a
> > central RDBMS piece which may not work for some networks, at the least I
> > think a new local persistance config format should be thought up, kept
> in a
> > simple format like YAML or JSON or something else well-known and with
> > existing parse tools.
> >
> > A whole discussion could probably be had on what constitutes the
> > configurable state of a node.
> >
> > I complained I believe to Chase who just happened to be the nearest
> person
> > who would listen that the heuristics for figuring out what roles a node
> > should play at runtime are complex and break down with the introduction
> of
> > additional interfaces. It's just really hard to divine what the operator
> > intent is for a particular interface, be it backhaul, client, AP, dhcpd
> or
> > no dhcpd, gateway, etc. I think the goal of zero-config out of the box
> > community wireless node is noble and can be preserved at some level but
> > probably accounts in some small part for the current state of the
> config.
>
> The intent of auto-configuration was never to divine operator intent,
> it was to detect connectivity.  That is what dhcpselect has always
> been about.  Dhcpselect, BTW, has been very successful at detecting
> connectivity!  Hate to be so heavy-handed about it, but detecting
> connectivity is the only humane thing for a router to do: it does it so
> much more effectively and tirelessly than a person.
>
> I expanded the set of ifconfig.X templates to express different interface
> roles (backhaul, AP, client, ...), in order to enable somebody to step
> up and write a web configurator.  (Nobody ever did.)  I never intended
> for everybody to rely on my heuristics for assigning roles to interfaces.
> Obviously a node's choice between AP and backhaul roles for each of two
> identical wireless interfaces can only be arbitrary....
>
> > So there is the configuration "backend" and then there is exposing those
> > knobs to an operator via a limited interface like a Web or ncurses form.
> > Bryan C had begun an update of the Web interface that looked super cool
> at
> > some point in the recent past but that effort is where right down? Can
> it be
> > resurrected? Also, should it be in light of a retooling of the backend
> > architecture. Which brings up a good point which is that it would be
> nice to
> > have the Web interface have more or less an API that can be extended for
> > other platforms, hooks for calling the platform-specific calls like
> > ifconfig(8) with its particular options.
>
> As we discussed at the summit, we are in need of a CUWiN MIB, some API for
> Web/ncurses configurators to change the MIB, a MIB persistence mechanism,
> and a system for triggering reconfiguration following MIB changes.
>
> If we move the configuration that is spread over the filesystem to a
> central repository (file, database, whatever), I believe that central
> repository will come to resemble a UNIX filesystem over time: it will be
> hierarchical, with directory-like "container" objects, file-like "leaf"
> objects, and methods for adding/modifying/deleting containers and leaves.
> It will grow a persistence mechanism, and a facility for repository
> clients to observe changes to the repository.  Finally, there will be an
> editor for the repository.  I know that was the development trajectory
> for a router configuration manager I wrote for a client.  It seems to
> me that the development trajectory for the Windows Registry must have
> been the same.  Rather than duplicate the UNIX filesystem, I am inclined
> to keep using the filesystem to store configuration, but to centralize
> the "raw" configuration in a directory called, say, /etc/config.d/,
> with one or more file for each interface, a file for nameservers, etc.
> I would use pax(1) for persistence, and add some daemon to listen or
> scan for changes under /etc/config.d/ and call scripts under /sbin/ to
> "cook" the raw configuration, creating /etc/ifconfig.* /etc/resolv.conf,
> hslsd configuration, etc.  The "editors" are the web UI, the ncurses
> interface, the SNMP client, and vi.


+1 for not reinventing the storage wheel, and vi.

How does the need for a CUWiN MIB reconcile with persistence on the file
system? I'm not very intimate with MIBs beyond some basic SNMP.

-Paul

--
Paul Smith
Center for Neighborhood Technology
Manager, Wireless Community Networks
Chicago IL, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.chambana.net/mailman/archive/cu-wireless-dev/attachments/20060406/730e0cf4/attachment.htm