This page will (hopefully) become a place for people to communicate and post information in an attempt to audit most of the known PersonalTelco nodes. Once before a project with a similar purpose existed, called AdoptANode. For a list of nodes look to the NodeMap or NetworkAddressAllocations.

For each node we hope to collect:



To "audit" a node, follow these steps:

  1. Determine what node you are auditing. If it is in the (alphabetized) list below, find it. If not, find it's node page in this Wiki. Usually node pages follow the convention of Node<Name> or Node<Number>. Some nodes may not have wiki pages at all; in these cases, go ahead and create one.

  2. Update the node page (if needed) to include the above data points. Use NodeTemplate as a guide. Verify that the actual network configuration matches what is on the node page, and what is in NetworkAddressAllocations.

  3. If the node is functional/non-functional/screwy, log this on the node page, in the "Maintenence and System Log" section. Also, log that you have reformatted the page in compliance with this page (NodeAudit).

  4. If it is not already on the (alphabetized) list below, add it (with current values for "Date Last Audited", "Last Status", and "NOT Managed").
  5. Import and/or update info for this node in Adhocracy

  6. Make sure it is on NodeLocations, and if it isn't, add it.

Regarding status. Here are some (conventional) meanings of words you might use:


I don't want to have duplicate data lying around, and a lot of this information is stuff we've already collected, so I've gone ahead and updated NodeTemplate to make it clear what pieces of information are relevant and updated a couple of node information pages to match that template. - KeeganQuinn

This is a good point: specific node information probably belongs in the node pages so that we don't duplicate effort/information. That said, the system probably should be for "auditors" to make sure the node page is accurate, and then log when they last checked on the node with a simple status like: functional, nonfunctional. That information could go on this page, and could be what we use to color the pins on the nodemap (if that ever happens). Thoughts? -- CalebPhillips

Sure, that sounds reasonable. I'm working on a more coherent system for all of this (see Adhocracy), but that works fine in the interim. I haven't been logging the last update date because the wiki does that for me, but if you feel that it would be specifically useful I'm not strongly opposed. - KeeganQuinn

Okay. I've made some stylistic changes and documented the 'steps' required to audit a node. -- CalebPhillips

Many of the nodes listed below are still missing contact and location info. I don't really have the time or inclination to fill these out right now, so if someone else feels like it, that would rock. Update: it has recently occurred to me that it would be very useful to collect BSSIDs as well as the channel and exact ESSID information from deployed APs. These also fall into the set of data which I don't really have the time or inclination to fill in on a large scale, so help is appreciated. - KeeganQuinn

One thing that might be useful to collect is the location of hardware, specifically the antenna(s). For nodes that have a staff, this can be found out pretty easily (albeit inconsistently). For other nodes, this might require a little recon, like asking the installer(s). Any opinions on this? Any reason not to add it (besides the work it entails)? - CalebPhillips



Updated and annotated by KeeganQuinn, CalebPhillips and hopefully everyone else. Original notes by CalebPhillips, based on a fairly ancient concept primarily supported by TomHiggins and RobertPetersen. RussellSenior is responsible for the first formal NodeAudit workday, NodeAudit2006.


NodeAudit (last edited 2007-11-23 18:01:25 by localhost)