Emulab Tutorial - Using Wireless Networking
Some Emulab nodes contain 802.11 a/b/g wifi interfaces (Atheros 5212 chipset),
and are scattered around at various locations. To find out where they
are located and what their node IDs are, see the wireless floormaps page.
When you click on one of the colored dots, you will be taken to a page
describing the node and what type of interfaces the node has installed
in it.
Before using a wireless network interface in an experiment,
please read the following
Acceptable Use Policy (AUP) regarding wireless interfaces.
By using our wireless nodes, you agree to be bound by this AUP.
- Receiving:
You may listen to and monitor anything you like. If you happen
to observe "private" information such as plaintext Web passwords,
you will not exploit that information, and you will take
care not to let it leak out publicly, e.g., in log files.
- Transmitting (1):
Do not transmit on channels that another experiment on the
testbed is using, unless it's your own. You can find out which
channels are currently in use by looking at the top of the wireless floormap.
Where possible, choose channels that have the least frequency overlap
with other experiments. (channel/freq table coming.)
- Transmitting (2):
Do not flood a wireless network with non-responsive traffic for
any significant period of time. The following channels are
"production networks" used by others at this location, so are
more restricted. You may not send "large" amounts of traffic on
them, and may send only low rates of non-responsive traffic.
Protocol | Channels |
A | 36, 38, 45, 52, 56, 60, 64 |
B/G | 1, 3, 5, 6, 7, 9, 11 |
- Question and Exceptions: send to
Testbed Ops
if you're not sure, or want an exception.
Creating an Experiment with Wireless-Capable Nodes:
To use a wireless network in an experiment, you must provide a few Emulab
specific NS directives in your NS file, which are illustrated in the
following small example:
source tb_compat.tcl
set ns [new Simulator]
# Allocate the nodes. Their "wifi-ness" is determined later,
# by the type of networks you request to be set up on them.
set nodew1 [$ns node]
set nodew2 [$ns node]
set nodew3 [$ns node]
set node4 [$ns node]
# A wireless lan connecting the first three nodes.
set lan0 [$ns make-lan "$nodew1 $nodew2 $nodew3" 54Mb 0ms]
# A regular duplex link from a wireless-capable node to a plain node.
set link0 [$ns duplex-link $nodew1 $node4 100Mb 0ms DropTail]
# Choose the wireless lan protocol.
tb-set-lan-protocol $lan0 "80211g"
# You must choose which node acts as the access point.
tb-set-lan-accesspoint $lan0 $nodew1
# Choose some other settings.
tb-set-lan-setting $lan0 "channel" 2
tb-set-node-lan-setting $lan0 $nodew1 "txpower" "auto"
# Currently you must use Redhat 9.0 on wireless nodes.
# Let the other node default to RHL-STD (currently 7.3).
tb-set-node-os $nodew1 RHL90-WIRELESS
tb-set-node-os $nodew2 RHL90-WIRELESS
tb-set-node-os $nodew3 RHL90-WIRELESS
# Turn on static routing.
$ns rtproto Static
$ns run
A few points should be noted:
- lan0 is created with standard make-lan
directive, but with a bandwidth that reflects the typical speed of a
wireless link (54Mb for 80211a and 80211g, 11Mb for 80211b). Note that
you may not use duplex links of wireless interfaces; just lans.
We assign each lan a unique ssid.
- After you create the lan, choose the protocol for the lan
with the tb-set-lan-protocol directive. Currently, you can
set the protocol to one of 80211a, 80211b, or 80211g.. If you
fail to set the protocol, the lan will consist of wired links, most
likely with delay nodes inserted!
- link0 is a plain duplex link. You may create plain links
as long as the nodes have enough wired interfaces. If you try to
create an experiment that uses more links (wired or wireless) on a
node than are available in Emulab, the experiment will fail to map.
Of the current 28 wifi nodes, the 18 pc3000w wifi nodes
(pcwf1-18) contain two wifi cards and one wired experimental interface,
the four pc600 nodes (pc2,9,31,40) contain one wifi card and four
experimental interfaces, and the four pc2Uwifi (pc180,182,183,184)
nodes have one wifi card and no wired experimental interfaces.
- In the example above, we let Emulab decide what wireless nodes to
use for the lan. This is not an ideal approach, as Emulab does
not currently track the connectivity of nodes, and so might pick
a set of nodes (randomly) that cannot communicate with each
other. See the section below on choosing
your nodes for more information on how to overcome this
problem.
- You must specify which node is to act as the access point for
the lan. Rather then using dedicated access points, Emulab's
implementation of wireless lans uses the interface's capability to
become an access point for a lan. The node that is chosen to be the
access point should obviously be within range of all of the nodes in
the lan. There is currently no automated mechanism to pick the access
point for you, but one is planned for the future.
We also plan to support ad-hoc mode;
unfortunately the proprietary layer under the Linux driver for our
Atheros cards does not currently support it.
- Wireless lans allow a number of configuration parameters to be
specified, either for the lan as a whole, or for individual members of
a lan. There are two Emulab specific directives that you can use;
tb-set-lan-setting sets a configuration parameter for the
entire lan. In the example above, we set the channel to be used for
the lan to channel five. Per-node settings can be specified with the
tb-set-node-lan-setting directive. In the example, we set the
transmit power for nodew1 to auto; all other nodes will
default to an interface specific setting.
- You must use Redhat 9.0 to take advantage of wireless interfaces. Be
sure to set the OSID for all of your wireless nodes to
RHL90-WIRELESS.
- The wifi nodes contain Netgear WAG311 cards, which use the
Atheros 5212 802.11a/b/g chipset. This chipset is quite flexible
since most of the 802.11 MAC layer is handled in software. Emulab
provides the standard madwifi Atheros driver by default, but
there are alternatives such as the madwifi stripped driver from
the MIT roofnet project and SoftMAC from the Universtiy of
Colorado at Boulder. Here are some useful links:
Netgear WAG311 product info
Madwifi Atheros driver
Stripped madwifi driver - Primarily for use with
click
Numerous interface settings are possible using tb-set-lan-setting
and tb-set-node-lan-setting. These mostly correspond to options
that are available using the iwconfig command on Redhat 9.0. Not
all options are accepted by all cards, and the format of the value you
provide for the option must be acceptable to iwconfig. At some point in the
future we hope to make this more explicit so that know exactly what options
are available each type of card, and what their legal values are. For now
you have to be something of an expert. Here is a rough guide to what you
can currently specify:
- channel - Set the channel for the lan to either a
channel number or a frequency. If you do not set the channel one
will be choosen for you, and thats probably just as bad as
setting it yourself without knowing what other people are using!
- rate - Some interfaces support setting a bit rate
different then the default. The default is to tell the interface
to use "auto" mode (varies the rate according to RF conditions),
but you can specify a specific rate for either the entire lan or
for just one node. The value should be in bits per second with no
units (11000, 54000, etc). See the iwconfig man page for more
details on the format of this option.
- txpower - Some interfaces support setting the transmit
power to something different then the default. The default is to
tell the interface to use "auto" mode. See the iwconfig man page
for more details on the format of this option. Not all interfaces
support this option.
- sensitivity - Some interfaces support setting the sensitivity
to something different then the default. The default is to
tell the interface to use "auto" mode. See the iwconfig man page
for more details on the format of this option. Not all interfaces
support this option.
After your experiment is swapped in, the above settings (including the
accesspoint) can be changed on the fly, using either the
link_config script on users.emulab.net, or with the
XMLRPC interface. For example, if you want to change the accesspoint
of a lan, first determine the MAC address (dotted or undotted notation
is fine) of the interface you want to be the accesspoint, and then use
link_config:
link_config myproj myexp lan0 accesspoint=00:09:5B:94:26:AF
Or you can use the XMLRPC interface from
your desktop or from users.
sshxmlrpc_client.py link_config proj=myproj exp=myexp
link=lan0 "params={'accesspoint': '00:09:5B:94:26:AF'}"
You may also change the settings for an individual node in a wireless
lan (although in some cases this could make the lan unusable if you
were to change a setting on just a single node). To do this, use the
-s option to link_config or the src argument to the
XMLRPC interface:
link_config -s nodew1 myproj myexp lan0 txpower=50
sshxmlrpc_client.py link_config proj=myproj exp=myexp
src=nodew1 link=lan0 "params={'txpower': 50}"
To enable and disable the interface for individual
nodes on the lan:
link_config -s nodew1 myproj myexp lan0 enable=no
link_config -s nodew1 myproj myexp lan0 enable=yes
sshxmlrpc_client.py link_config proj=myproj exp=myexp
src=nodew1 link=lan0 "params={'enable': 'no'}"
Note this currently operates by bringing the interface up/down with
the ifconfig command.
Choosing Physical Nodes:
As mentioned above, Emulab's default mapping of nodes in your virtual
topology, to physical nodes with wireless interfaces, does not
currently take into account physical connectivity (walls, floors,
electrical conduits, etc. all conspire to make it possible that two
wireless nodes 50 feet apart from each other will not actually be able to
communicate with each other). We are planning to add this
capability in the future, but in the meantime it is mostly up to you
to choose nodes that make sense for your topology. You might end up
having to make some trial and error runs, trying to find the right
set of nodes (including setting the accesspoint to different nodes in
a lan) before you get a working set.
To assist in this chore there are two Emulab specific NS extensions
you can use in your NS file. The first approach is to use the
tb-use-physnaming extension.
tb-use-physnaming 1
set pc222 [$ns node]
set pc223 [$ns node]
set pc224 [$ns node]
which says that whenever a node is named by an existing physical node
in the testbed, do an implicit fix-node. This saves a little bit of
typing, and in some cases might be easier to manage then the second
approach, which is to use tb-fix-node for all (or some) of
the nodes in your lan. Using the
wireless floormaps
choose which nodes you want, and then in your NS file:
set nodew1 [$ns node]
set nodew2 [$ns node]
set nodew3 [$ns node]
tb-fix-node $nodew1 pc222
tb-fix-node $nodew2 pc223
tb-fix-node $nodew3 pc224
Keep in mind that the physical nodes you choose must be free when you
swap in your experiment!