[CUWiN-Dev] CUWiN 1.0 wishlist?

[David Young]

On Mon, Jun 27, 2005 at 10:29:29AM -0500, Paul Smith wrote:
> David Young <dyoung at pobox.com> wrote on 23/Jun/05 at  5:20 PM:
> 
> > What do we need to do add/change in CUWiN before release 1.0?
> > Discuss. :-) I am especially hoping for input from Bill & Paul at CNT.
> 
> I don't think there are any features that aren't currently in CUWiN that we'd
> want to see or need before a 1.0. The key, critical issue for CNT is
> stability. What we're looking for is a freeze on new feature development and
> a focus on bug squashing and shoring up anything that could negatively impact
> long-running systems. Since commits have tapered off over the last week or
> so, maybe it's a good time to branch a release candidate. Absent an ability
> to run simulations, our testing strategy would be to deploy to our test bed,
> check for uptime and a basic suite of userland tests.
> 
> A couple of things that would help us are:
> 
> 1. An idea of what NetBSD sources to use -- is there or will there be a
> "blessed" set of sources (including possible patches not in -current)
> associated with 1.0? Should your recent net80211 commits to NetBSD-current be
> included?  If so are there any benefits associated with the net80211 changes
> we should be aware of?

I am not precisely sure what to expect from the new Atheros driver,
but it may improve the radio's operation enormously.

The new net80211 contains many bug fixes, improved .11g support, improved
crypto support, etc.  We will not see the full advantages of the new
net80211 until I have brought the 802.11 cuserland up-to-date.

If Chase is not too busy, I think we can make a release this week with
"blessed" NetBSD sources.

> 2. Guidance on how to test hslsd in a controlled way. What is your build/test
> environment like? Do you have some sort of test setup that you feed packets
> to hslsd with? How do you know when it's "ready"? We have a test bed in our
> lab but it's difficult to control for certain variables, it would be nice if
> we knew how to run hslsd like a brain in a vat to check for predictable
> outcomes.

I do not have a controlled test environment.  I have a small (6-node)
testbed inside my office that I am constantly cannibalizing and
re-building.

There's been a lot of talk about "brain in a vat" testing.  We simply
do not have the resources to do that.

> In trying to setup a multi-hop test bed we've had hslsd produce some
> non-intuitive routing tables, had issues with nodes going offline only to
> find them in the debugger when we check with the serial console (watchdog
> seems to kick in right after we check serial console), and apparent
> inconsistencies between the routing table and the routeviz output.

Please file PRs on these issues.  I need to know if hslsd is producing
"non-intuitive" routing tables (what does this mean?).  Also, nodes should
not drop into the debugger.  I need for you to send me a stack trace
(trace/u at the db> prompt) when that happens.  The watchdog is no help
if it does not fire until the serial console is attached; just disable it.

I do not trust routeviz to produce useful pictures.  You shouldn't,
either.  I don't know if that program can be rescued.  The "ball & spring"
graph visualization is unstable; the graphics library ("gd") is slooow,
and it cannot even draw simple graphic primitives like circles correctly.

> We'd like to verify that hslsd is functioning properly and learn how to
> manually check its routing decisions from log or other output.

Log output: activate logging for shortest paths first (SPF) using
one of -l spf_{any,quiet,loud}.  Activate logging of expired-LSA
purging with -l purge_{any,quiet}.  Look at the RIB updates using -l
rib_{any,bufev,quiet}.  Information provided by -l peer_{quiet,any}
will be useful.  You can find more of the -l options by grepping the .c
files in hsls/, etx/, rib/, etc., for 'LOGLIB_.*SINK' .

hslsd regularly dumps two databases to /var/db/.  In /var/db/linkstates
are all of the linkstates.  In /var/db/vizlinks, the linkstates have
been distilled into information for the visualizer.

Dave

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