Commit 76ad3c41 authored by Jay Lepreau's avatar Jay Lepreau

Documentation tweaks, including fixing a few html typos.

parent 248c22b3
......@@ -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>
......
......@@ -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
......
......@@ -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.
......
......@@ -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.
......
......@@ -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.
......@@ -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>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment