Skip to content
GitLab
Menu
Projects
Groups
Snippets
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
emulab
emulab-devel
Commits
76ad3c41
Commit
76ad3c41
authored
Feb 18, 2005
by
Jay Lepreau
Browse files
Documentation tweaks, including fixing a few html typos.
parent
248c22b3
Changes
6
Hide whitespace changes
Inline
Side-by-side
www/doc/mobilewireless.html
View file @
76ad3c41
...
...
@@ -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"
>
webcam
s
</a>
for viewing the robots in their
habitat.
</ul>
...
...
www/tutorial/elabinelab.php3
View file @
76ad3c41
...
...
@@ -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
be
en
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
View file @
76ad3c41
...
...
@@ -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 differen
ce
services on the boss and ops nodes. At the current time,
lot of differen
t
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
i
s implemented using OS-provided routing
</b>
.
<li><b>
The firewall
wa
s 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
i
s not firewalled
</b>
.
<li><b>
Intra-Emulab traffic
wa
s 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
View file @
76ad3c41
...
...
@@ -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
, y
ou 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
. Y
ou 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 webcam
s
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 900
H
Mz band, so see the TinyOS
of our motes have radios in the 900M
H
z 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
View file @
76ad3c41
...
...
@@ -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 vi
sa
-versa.
want to restrict access from the Internet to experimental nodes and vi
ce
-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 ga
u
ge the performance
impact of placing a firewall node between you
r
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 3
0 minutes
<emph>
Please note that this configuration currently takes
over 2
0 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
View file @
76ad3c41
...
...
@@ -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=
"<NEW>"
>
<li>
<a
href=
"mobilewireless.php3"
>
Using Mica2 motes on mobile robots
</a>
<img
src=
"../new.gif"
alt=
"<NEW>"
>
<li>
<a
href=
"docwrapper.php3?docname=secure.html"
>
Running an experiment in a ''secure'' environment
</a>
<img
src=
"../new.gif"
alt=
"<NEW>"
>
...
...
@@ -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=
"<NEW>"
>
<li>
<a
href=
"mobilewireless.php3"
>
Using Mica2 motes on mobile robots
</a>
<img
src=
"../new.gif"
alt=
"<NEW>"
>
<li>
<a
href=
"docwrapper.php3?docname=secure.html"
>
Running an experiment in a ''secure'' environment
</a>
<img
src=
"../new.gif"
alt=
"<NEW>"
>
<li>
<a
href=
"docwrapper.php3?docname=firewall.html"
>
Experiment Firewalling in Emulab
</a>
<img
src=
"../new.gif"
alt=
"<NEW>"
>
<img
src=
"../new.gif"
alt=
"<NEW>"
>
<li>
<a
href=
"elabinelab.php3"
>
Running an instance of Emulab inside Emulab
</a>
<img
src=
"../new.gif"
alt=
"<NEW>"
>
</ul>
<p>
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment