Differences between revisions 73 and 74
Revision 73 as of 2005-12-10 18:09:03
Size: 6376
Editor: 69
Comment: touch NodeBuffaloGap and NodeUrbanGrind - CalebPhillips
Revision 74 as of 2005-12-13 18:58:35
Size: 6375
Comment: touch NodeLuckyLab
Deletions are marked like this. Additions are marked like this.
Line 72: Line 72:
 || NodeLuckyLab || 2005-11-14 || WiP ||  || NodeLuckyLab || 2005-12-13 || OK ||

Introduction

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:

  • SSID (www.personaltelco.net)
    • If the ESSID doesn't contain this, it's not really a node, according to the NodeStandards.

  • Node Name (i.e. SouthParkBlocks, CrowBar) and Number (i.e. 597)

    • Not all nodes have numbers.
  • Node Address
  • [Contact: phone number, email address?]
    • Get the name of the person to talk to also.
    • It's best to get both a phone number and an email address.
    • Some nodes prefer to remain anonymous, and I think it's a good idea to respect that.
  • Channel (1-11)
    • There are quite a few more channels in 802.11a.
    • It might be nice to document whether an AP supports 802.11g or state exactly what types of interface are supported.
  • BSSID (this is the MAC address of the AP radio.)
  • IP address space (see NetworkAddressAllocations)

  • Public IP (Static/DHCP) / Routing Information
  • DNS server addresses
  • Features/Description of Node Location (i.e. coffee house with good lattes)
    • Try and keep these objective...
  • Last Audit Date, By Whom? Did it work?

Methodology

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.

  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" and "Last Status").

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

  • OK: Everything is working ideally.

  • Functional: Works, but not PTP Managed, so this is a little different.

  • Inaccessible: May work, but is not accessible from the internet (for remote Administration).

  • Inaccessible/OK: Does work, but is not accessible for remote administration.

  • Down: Not functional, See node page for why

Discussion

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

Data

Credits

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.


[CategoryDocumentation]

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