Documentation tweaks, including fixing a few html typos.

www/doc/mobilewireless.html

@@ -23,15 +23,15 @@
 
 The mobile wireless testbed integrates robots and motes into the standard
 Emulab testbed.  If you want to know how to create experiments utilizing these
-resources, check out the <a href="/tutorial/mobilewireless.php3">tutorial</a>.
-This document is intended to provide a more in-depth description of what makes
-up this part of Emulab.
+resources, check out the detailed <a href="/tutorial/mobilewireless.php3">tutorial</a>.
+This document you're reading is intended to (eventually) provide a more
+in-depth description of what makes up this part of Emulab.
 
 <p>
 <li> <a NAME="HARDWARE"></a>
      <h3>Hardware</h3>
 
-The hardware systems that make up the mobile wireless testbed are:
+The hardware systems that currently make up the mobile wireless testbed are:
 
 <ul>
 <li>Four Acroname <a
@@ -42,7 +42,7 @@ board computers for each robot.
 motes</a> attached to each stargate.
 <li>Four overhead cameras for <a href="#VISION">visual tracking</a> of the
 robots.
-<li>A <a href="/webcam.php3">webcam</a> for viewing the robots in their
+<li>Two <a href="/webcam.php3">webcams</a> for viewing the robots in their
 habitat.
 </ul>
 

www/tutorial/elabinelab.php3

@@ -48,13 +48,6 @@ ensures that the node in question is actually part of the inner Emulab
 ElabInElab serves several purposes:
 
 <ul>
-<li> Allows testing and development of Emulab itself in a controlled
-     environment, without needing a dedicated testbed. New features
-     can be tested without affecting users of the main testbed.
-     In fact, multiple independent inner Emulabs can be constructed
-     with each one being used for the testing and development of
-     different features. 
-
 <li> Can be used to provide an isolated environment (in conjunction
      with firewalling) for running "dangerous" experiments that
      include the use of worms and other malware. Instead of running
@@ -62,6 +55,13 @@ ElabInElab serves several purposes:
      inner Emulab, and thus has access to all of the Emulab's
      services, but in a context that does not put the outer Emulab at
      risk from attack. 
+
+<li> Allows testing and development of Emulab itself in a controlled
+     environment, without needing a dedicated testbed. New features
+     can be tested without affecting users of the main testbed.
+     In fact, multiple independent inner Emulabs can be constructed
+     with each one being used for the testing and development of
+     different features. 
 </ul>
 
 <p>
@@ -80,7 +80,7 @@ There are a few things to keep in mind about ElabInElab:
 
 <li> All of the nodes consume one of their experimental network
      interfaces to use for the innner Emulab "control" network.
-     Therefore, inner experimental nodes have one less experimental
+     Therefore, inner experimental nodes have one fewer experimental
      interface to use in experiments.
 </ul>
 
@@ -139,8 +139,8 @@ Another example:
 In this example, we have included a <tt>tb-set-inner-elab-eid</tt>
 directive, which says to automatically launch an experiment within the
 inner Emulab once it is set up. The "myexp" experiment must already
-exist in the same project; an experiment called "myexp" should already
-be created, but not swapped in. The system uses the NS file associated
+exist in the same project; it must have already
+been created, but not swapped in. The system uses the NS file associated
 with the "myexp" experiment to construct an experiment on the inner
 Emulab and swap it in. You will be notified via email, first when the
 inner Emulab has been fully swapped in, and then again when the inner
@@ -180,6 +180,14 @@ boss. The proxy on the outer boss checks to make sure that the actions
 are allowed (and make sense), and then proceeds to do them itself. 
 
 
+<br><br>
+<b>Setup time</b>: Largely due to dynamic construction of extensive
+parts of the inner Emulab environment, it currently takes about 20
+minutes to set up ElabinElab on pc850s.  In the future we will reduce
+this time considerably by more caching of pre-built components.
+Some faster nodes (2 and 3 GHz) will soon be available, which will also help.
+
+
 <?php
 #
 # Standard Testbed Footer

www/tutorial/firewall.html

@@ -135,7 +135,7 @@ But this one probably crosses the line:
 <ul>
 <li><b>The firewall exposes more of the infrastructure than it should</b>.
 The Emulab node self-configuration and monitoring infrastructure uses a
-lot of difference services on the boss and ops nodes.  At the current time,
+lot of different services on the boss and ops nodes.  At the current time,
 we allow all those through.  Moreover, many of these, such as TFTP, cannot
 be pinned down too precisely in firewall rules, so the rules are more open
 than we would prefer.  Additionally, we also currently preserve the shared
@@ -232,20 +232,20 @@ and <code>ntp2</code>, are Emulab infrastructure related.
 <a NAME="YeOleImpl"></a><h2>The deprecated <code>ipfw</code> firewall</h2>
 <p>
 An earlier, less secure, firewall implementation did not require support
-from the switching infrastructure.  This "software" firewall solution,
+from the switching infrastructure.  This "software" firewall solution
 still allocated an extra node to act as an IP firewall.
 This node was then set as the default route for all other nodes in the
 experiment.  Thus, all outgoing, non-experimental traffic was passed through
-the node.  Inbound traffic directed to the nodes did not pass through the
+the firewall node.  Inbound traffic directed to the nodes did not pass through the firewall.
 So in addition to <a href="#Limitations">the limitations above</a>
-you can add the following:
+you can add the following for this deprecated version:
 <ul>
-<li><b>The firewall is implemented using OS-provided routing</b>.
+<li><b>The firewall was implemented using OS-provided routing</b>.
 Specifically, every node has its default route changed to point to the
 firewall node.  Sufficiently powerful applications could accidentally
-or intentionally change the default route back to the Emulab router
+or intentionally change the default route back to the Emulab router,
 thus circumventing all protection.
-<li><b>Intra-Emulab traffic is not firewalled</b>.
+<li><b>Intra-Emulab traffic was not firewalled</b>.
 Traffic between nodes over the control net
 (155.98.36.x addresses) is not filtered since the shared control net is a LAN
 and all other nodes are directly reachable.

www/tutorial/mobilewireless.php3

@@ -95,7 +95,8 @@ function NLCEMPTY()
     <i><font size="-1">
 
     Note: This part of the testbed is in the prototype stage, so the hardware
-    and software may behave in unexpected ways.
+    and software may behave in unexpected ways.  
+   
 
     </font></i>
 </center>
@@ -114,19 +115,33 @@ function NLCEMPTY()
 <?php NLCBODYBEGIN() ?>
 <!-- Center -->
 
+
+<b>Preface</b>:
+We have deployed and opened to public external use a tiny version of
+what will grow into a large mobile robotic wireless testbed.  The
+small version (4 Motes and 4 Stargates on 4 robots, all remotely
+controllable) is in an open area within our offices; the big one will
+be elsewhere.
+
+
+<h4>How to Use It</h4>
+
 In addition to <a href="docwrapper.php3?docname=wireless.html">fixed wireless
-nodes</a>, Emulab also features wireless nodes attached to robots that can move
+nodes</a> (currently predominantly 802.11), Emulab also features wireless nodes attached
+to robots that can move
 around a small area.  These robots consist of a small body (shown on the right)
 with an <a href="http://www.xbow.com/Products/XScale.htm">Intel Stargate</a>
 that hosts a mote with a wireless network interface.  The goal of this "mobile
 wireless testbed" is to give users an opportunity to conduct experiments with
-wireless nodes in configurable physical locations and while in motion.  For
+wireless nodes that are truly mobile
+<!-- in configurable physical locations and while in motion. -->
+For
 example, mobile nodes could be used to realistically test and evaluate an
 ad-hoc routing algorithm in a fairly repeatable manner.  This document is
-intended as a tutorial for those interested in making use of this testbed,
+intended as a tutorial for those interested in making use of this testbed;
 there is also a short <a href="<?php echo
 $TBBASE?>/doc/docwrapper.php3?docname=mobilewireless.html">reference manual</a>
-available that gives details about the workings of the system.
+available that gives a few details about the workings of the system.
 
 <br>
 <br>
@@ -151,13 +166,16 @@ The current features of the mobile wireless testbed are:
 <li>Four <a href="http://www.acroname.com">Acroname Garcia</a> robots
 <li><a href="http://www.xbow.com/Products/XScale.htm">Intel Stargate</a> single
 board computers for each robot.
-<li><a href="http://www.xbow.com/Products/productsdetails.aspx?sid=72">Mica2 
-motes</a> attached to each stargate.
-<li>Four overhead cameras for visual tracking of the robots.
-<li>A <a href="<?php echo $TBBASE ?>/webcam.php3">webcam</a> for viewing the
+<li><a href="http://www.xbow.com/Products/productsdetails.aspx?sid=72">900MHz Mica2 
+motes</a> attached to each Stargate.
+<!-- <li>Some non-mobile Mica2 motes nearby. -->
+<li>Roaming an area about 8 x 3.5 meters with a sheetrock-covered steel pillar in the middle.
+<li>Four overhead cameras for vision-based position tracking of the robots.
+<li>Two <a href="<?php echo $TBBASE ?>/webcam.php3">webcams</a> for viewing the
 robots in their habitat.
 <li>An <a href="<?php echo $TBBASE ?>/robotmap.php3">abstract map</a> of the
 current locations of the robots.
+<li>Open for public use weekdays 8am-6pm MST, with operations support.
 </ul>
 
 <?php NLCBODYEND() ?>
@@ -179,14 +197,14 @@ limitations you should be aware of:
 <li>Before you can use the mobile testbed, your project must be granted the
 appropriate privileges.  You can request access by sending mail to <a
 href="mailto:testbed-ops@flux.utah.edu">Testbed Operations</a>.
-<li>Availability is reduced to weekdays between 8am and 6pm mountain time,
-so there is staff available to assist with problems.
-<li>There is no space sharing, only one mobile experiment can be swapped-in at
+<li>The mobile testbed is currently open on non-holiday weekdays between
+8am and 6pm mountain time, so we have staff available to assist with problems.
+<li>There is no space sharing; only one mobile experiment can be swapped-in at
 a time.
 <li>Batteries must be replaced manually by the operator when levels are low.
 </ul>
 
-We hope to overcome these limitations over time, however, we are also eager to
+We expect to overcome these limitations over time; however, we are also eager to
 introduce external users to the mobile testbed early on so we can integrate
 their feedback.
 
@@ -287,8 +305,9 @@ The values specified above are measured in meters and based on the map located
 <a href="<?php echo $TBBASE ?>/robotmap.php3">here</a>, where the origin is in
 the upper left hand corner, with positive X going right and positive Y going
 down.  You can also click on the map to get a specific set of coordinates.
-Note that any coordinates you specify must not be in an obstacle, or they will
-be rejected by the system.
+Note that any coordinates you specify must not fall inside an obstacle, or they will
+be rejected by the system.  A Java applet that updates in real time is linked
+from
 
 <p>
 With this NS file you can now create your first mobile experiment.  Actually
@@ -309,10 +328,12 @@ for use, you can swap-in your experiment and begin to work.
 
 <?php NLCBODYBEGIN() ?>
 
-Now that you have a node allocated, lets make it mobile.  During swap-in,
-Emulab will start moving the node to its initial position, you can watch its
+Now that you have a node allocated, let's make it mobile.  During swap-in,
+Emulab will start moving the node to its initial position.  You can watch its
 progress by using the "Robot Map" menu item on the experiment page and checking
-out the <a href="<?php echo $TBBASE ?>/webcam.php3">webcam</a>.
+out the <a href="<?php echo $TBBASE ?>/webcam.php3">webcams</a> or
+the <a href="<?php echo $TBBASE ?>/robotrack.php3">applet version of the map</a>
+that updates in real time.
 
 <p>
 <table width="100%" cellpadding=0 cellspacing=0 border=0 class="stealth">
@@ -361,7 +382,7 @@ match your project and experiment IDs.</font>
 
 <!-- mention that one setdest will override the previous. --> 
 
-Then, check back with the map and webcam to see the results of your handiwork.
+Then, check back with the map and webcams to see the results of your handiwork.
 Try moving it around a few more times to get a feel for how things work and
 where the robot can go.  Note that the robot should automatically navigate
 around obstacles in the area, like the pole in the middle, so you do not have
@@ -565,7 +586,7 @@ tb-fix-node $transmitter $node(1)
 This code creates two mote nodes and "attaches" each of them to one of the
 mobile nodes.  The OSs to be loaded on the mote nodes are the receiver,
 TinyOS-RfmLed, and the transmitter, TinyOS-CntRfm.  These are standard
-TinyOS kernels supplied by Emulab - uploading your own is covered below.
+TinyOS kernels supplied by Emulab; uploading your own is covered below.
 The receiver kernel will
 listen for packets containing a number from the transmitter and display the
 number, in binary, on the mote's builtin LEDs.  The transmitter kernel will
@@ -588,7 +609,7 @@ normally (ie. '<code>make mica2</code>').  Then, upload the binary that gets
 placed in <code>build/mica2/main.srec</code> to our
 <a href="<?php echo $TBBASE ?>/newimageid_ez.php3?nodetype=mote">mote image
     creation page</a>.  This page will ask you for a 'descriptor'.  This
-descriptor can then be used in <code>tb-set-node-hardware</code> lines in your
+descriptor can then be used in <code>tb-set-node-os</code> lines in your
 NS files, and your app will be automatically loaded on the appropriate mote(s).
 
 <p>
@@ -596,7 +617,7 @@ At this time, we don't have a TinyOS installation on the Emulab servers, so
 you'll need to have a TinyOS installation to build from on your desktop
 machine, or some other machine you control.  We hope to provide a way for you
 build TinyOS apps on Emulab in the near future.  Also, at the current time, all
-of our motes have radios in the 900HMz band, so see the TinyOS
+of our motes have radios in the 900MHz band, so see the TinyOS
 <a href="http://www.tinyos.net/tinyos-1.x/doc/mica2radio/CC1000.html">CC1000
 radio document</a> to make sure you're tuning the radios to the right band.
 

www/tutorial/secure.html

@@ -27,11 +27,11 @@ were used, the threat model being addressed was accidental "attacks" on
 isolation; e.g., a misconfigured interface causing flooding of another
 experiment's network.
 We are now building up the Emulab infrastructure to allow experimentation
-with more potent threats, in particular ''malware'', which attempts to
+with more potent threats, in particular ''malware,'' which attempts to
 actively exploit weaknesses on nodes and in the network.
 </p><p>
 Since Emulab is intended for use by researchers, we did not unnecessarily
-want to restrict access from the Internet to experimental nodes and visa-versa.
+want to restrict access from the Internet to experimental nodes and vice-versa.
 Thus the central Emulab firewall is fairly permissive.  For high-risk
 experiments, this is not acceptable.  To address this, we have added
 <a href="docwrapper.php3?docname=firewall.html">per-experiment control net
@@ -66,8 +66,8 @@ Hence all nodes are still on the shared control network.
 <li>Blue.
 An <a href="docwrapper.php3?docname=firewall.html#Styles">open style</a>
 firewall is allocated.  This is largely worthless since you cannot add
-any rules to the firewall.  However, you can use it to gage the performance
-impact of placing a firewall node between you experiment and the outside
+any rules to the firewall.  However, you can use it to gauge the performance
+impact of placing a firewall node between your experiment and the outside
 world.
 <li>Yellow.
 A <a href="docwrapper.php3?docname=firewall.html#Styles">basic style</a>
@@ -84,7 +84,7 @@ You can explicitly combine a per-experiment Emulab with an "Orange" experiment
 to get the highest level of protection we currently offer.  It further
 restricts access from the experiment to the "real" Emulab infrastructure
 (e.g., no NFS allowed to the real "fs" node).
-<emph>Please note that this configuration currently takes about 30 minutes
+<emph>Please note that this configuration currently takes over 20 minutes
 to setup, regardless of the size of the experiment!</emph>
 </p>
 <a NAME="Limitations"></a><h2>Limitations</h2>
@@ -120,7 +120,7 @@ the firewall example</a> except that there are no additional firewall
 rules to allow <code>traceroute</code>.
 </p><p>
 To setup a high-security prison for running a
-<a href="docname=windows_in_emulab_user.html">Windows XP experiment</a>
+<a href="../doc/docwrapper.php3?docname=windows_in_emulab_user.html">Windows XP experiment</a>
 you could do:
 	<code><pre>
 	source tb_compat.tcl
@@ -154,7 +154,8 @@ Here <code>winxpnodes</code> might look like:
 	set lan [$ns make-lan "$win1 $win2" 100Mb 0ms]
 
 	$ns run
-	<code><pre>
+	<code></pre>
 </p>
+
 See the <a href="elabinelab.php3">''Emulab in Emulab''</a> section for
 more details.

www/tutorial/tutorial.html

@@ -40,6 +40,12 @@
     	   Multiplexed Virtual Nodes</a>
     <li> <a href="docwrapper.php3?docname=ixp.html">
     	   Using IXP network processors</a>
+    <li> <a href="docwrapper.php3?docname=wireless.html">
+           Using wireless 802.11 links</a>
+	   <img src="../new.gif" alt="&lt;NEW&gt;">
+    <li> <a href="mobilewireless.php3">
+	   Using Mica2 motes on mobile robots</a>
+	   <img src="../new.gif" alt="&lt;NEW&gt;">
     <li> <a href="docwrapper.php3?docname=secure.html">
     	   Running an experiment in a ''secure'' environment</a>
 	   <img src="../new.gif" alt="&lt;NEW&gt;">
@@ -572,8 +578,18 @@ Again, please feel free to contact us.
 <li> <a href="docwrapper.php3?docname=nse.html">Hybrid Experiments with Simulation and Emulation</a> 
 <li> <a href="docwrapper.php3?docname=vnodes.html">Multiplexed Virtual Nodes</a>
 <li> <a href="docwrapper.php3?docname=ixp.html">Using IXP network processors</a>
+<li> <a href="docwrapper.php3?docname=wireless.html">Using wireless 802.11 links</a>
+	<img src="../new.gif" alt="&lt;NEW&gt;">
+<li> <a href="mobilewireless.php3">Using Mica2 motes on mobile robots</a>
+	<img src="../new.gif" alt="&lt;NEW&gt;">
+<li> <a href="docwrapper.php3?docname=secure.html">
+	Running an experiment in a ''secure'' environment</a>
+	<img src="../new.gif" alt="&lt;NEW&gt;">
 <li> <a href="docwrapper.php3?docname=firewall.html">Experiment Firewalling in Emulab</a>
-     <img src="../new.gif" alt="&lt;NEW&gt;">
+        <img src="../new.gif" alt="&lt;NEW&gt;">
+<li> <a href="elabinelab.php3">
+    	Running an instance of Emulab inside Emulab</a>
+	<img src="../new.gif" alt="&lt;NEW&gt;">
 </ul>
 <p>