Suman's courses

This assignment will give you some good hands-on experience with 802.11 configuration and experimentation. Since this assignment requires you to access multiple machines at the same time we will be assigning you time slots to access the machines. Please sign up for a schedule in class. This is a very good opportunity for all of you to get your feet wet in working with practical wireless networks. Hope you enjoy the process.

For questions/doubts regarding TASK0 contact mblodget AT cs and direct the rest of the questions regarding the assignment/set-up to shravan AT cs. Please use “CS707:” in the subject of the email.

To get full points you have to complete the following tasks:

Schooner is a networking testbed located in WAIL, the Wisconsin Advanced Internet Laboratory. The testbed consists of a large number of computers, routers, switches, storage arrays, and other specialty gear. Through the web interface you are able to request access to these resources and connect them in a topology you design. The first thing you will need to do is request an account on the testbed.

Step 1: Go to http://www.schooner.wail.wisc.edu
Step 2: In the left nav bar click “Request Account”
Step 3: Click 'Join an existing project“
Step 4: Fill out the form, make sure to use 'CS707' as your 'Project Name'

After you request an account it will go through some verification procedures, and notify the testbed administrators your account is waiting for approval. Once approved you will be notified via email and will be ready to start experimenting.

To create an experiment you must first come up with an experimental description. The testbed uses the same format and syntax as NS2, a well known network simulator. After using the testbed for awhile you would learn how to write NS directly or at least know which parts to cut/paste to get what you want. A second way is to use the graphical editor, a java based app which lets you draw out your topology. While the graphical editor is easy to use for simple experiments, you don't have the full power of the NS language (TCL) available to you. Also you can go hybrid, draw the topology, and then manually add some NS to fully automate your experiments. The third way and this is the easiest, we'll just give you an NS file.

Step 1: Login to the Schooner web interface
Step 2: On the left in the 'Experimentation' box, click 'Begin an Experiment'
Step 3: Fill out the form, project is CS707, name is your experiment name which the namespace is shared across the class, so name your experiment <username>-lab1, for the NS file enter /proj/CS707/lab1.ns, do NOT select batch mode and it's best to click the box for “Do Not Swapin”.
Step 4: Submit

If things went correctly it will drop you into the experiment web page, your experiment is now in the Schooner system, but it has not been swapped in. You can have thousands of experiments saved in the system at one time, but they won't actually be running until you “Swapin”. Basically creating the experiment sets up the database and a number of things in the filesystem, swapping in, goes out and reserves the resources you requested and connects them together. If the picture looks like what you want go ahead and click 'Swap Experiment In' from the experiment web page.

You'll notice a large scrolling log, you can watch the experiment go through various steps of experiment setup. After about five minutes it should have successfully logged in, and you will receive an email to that fact. To return to the experiment web page, above the log where it say 'Experiment CS707/<your username>-lab1' just hit <your-username>-lab1. Now on that page click the 'Details' tab. This is basically the contents of the email you received. The first thing you'll look for is the 'Physical Node Mapping' in here you will how your virtual nodes, being the node names you used in the NS description, were mapped to physical nodes of the testbed, which are names like pc-i5-46-a.

Now open a window and ssh to ops.schooner.wail.wisc.edu, this machine is your SSH gateway to the experimental nodes, it also hosts your home directory and has a number of command line tools to interact with the testbed. From ops you should be able to SSH to the phyical node name you found in the last experiment. When your experiment swaps in, it also sets up a number of DNS mapping, in the status page you'll also see a 'Virtual Node Info' box which will give you the fully qualitified domain name.

Before you begin: In this assignment, you would be needing a total of 3 wireless nodes. By now, you should now have access to two machines in the WAIL lab (see above). You can find the hostnames of these machines in the .tbssh files on the schooner web interface. Let us call them node0 and node1. Make sure you are able to ”ssh -X“ into them. Note that most of the commands we will use below have to be run in 'super user mode', therefore you would have to use sudo when running them. The third node (es1) to be used in the experiment is placed in the WiNGS lab. Information on the login details of this node would be provided to you in the class.

Step 1: Login into one of the nodes (say node0).
Step 2: Run iwconfig. You should see something like this:

lo        no wireless extensions.
eth0      no wireless extensions.
eth1      no wireless extensions.
eth2      no wireless extensions.
eth3      no wireless extensions.
wifi0     no wireless extensions.

If for some reason you see interface of type “athX” (where X is some number), then you need to run the initialization script at the root prompt by typing /proj/CS707/init.sh . This will delete all existing virtual interfaces. (Ignore the error messages of type ”ERROR: Module <mod-name> does not exist in /proc/modules“ when you run this script)

Step 3: Create a virtual master interface (access point) by using wlanconfig tool (use wlanconfig ath create wlandev wifi0 wlanmode ap ) and bring the interface up by typing ifconfig athX up.
Step 4: Set the essid to cs707. Use the iwconfig tool for this.
Step 5: Set the frequency band to 802.11g by typing iwpriv athX mode 3.
Step 6: Give your AP an IP address : Run ifconfig athX <AP-IP> up (e.g., AP-IP can be 192.168.25.1)
Aha! you have created an access point

Step 1: Login to es1. (Information about the login credentials would be provided in the class). Change directory to CS707. Run the initialization script init.sh at the root prompt.
Step 2: Now create a station mode interface using the wlanconfig tool. (Use managed for wlanmode) Bring the interface up.
Step 3: Set the essid to cs707. At this point, for the first few seconds, when you type the iwconfig command multiple times, you should see the Frequency: parameter in iwconfig changing. This implies that your client is scanning different channels to lock onto the frequency of your access point. After a while when you type iwconfig the Frequency: parameter should show the same frequency on which your AP is and Access Point: should contain the MAC address of your AP.
Step 6: Give your client an IP address : Run ifconfig athX <client-IP> up (e.g., client-IP can be 192.168.25.2)
You can now run ping tests to verify that your client is indeed connected to the cs707 AP.

This is the first step to making you true hackers in the wireless domain. Configuring wireless cards in monitor mode allows you to see all wireless packets in the air. If a wireless user's session is unencrypted, you can sniff some important information (passwords,emails??) from these wireless packets. However, our objective here is to understand the functioning of 802.11 protocol by sniffing wireless packets.
Step 1: Login to other node in the WAIL lab (say node1) and run the initialization script.
Step 2: Create client interface as in task 2. (Let us call this interface ath0).
Step 3: Now run the wlanconfig command to create another monitor mode interface. (Figure out how!). Let us call this interface ath1. Bring the interface up.
Step 4: To check that the monitor interface ath1 is working, run tethereal -i ath1. You should be able to see packets (beacons, ACKs etc) being received.

In this experiment we will understand the correlation between the wireless data rates and the incurred wireless losses. We will use iperf tool to transmit data from the AP to the client, and alongside use the monitor node to capture the wireless trace. We will then analyze the wireless trace to compute the loss rates.

Step 1: Fix the transmit power at the AP to the maximum using iwconfig tool. (E.g., iwconfig athX txpower 18). You can view the list of possible transmission powers using iwlist athX txpower.
Step 2: Fix the data rate of the AP to 6 Mbps using iwconfig athX rate 6M fixed.
Step 3: Create a UDP iperf-server on the client-node using iperf -s -u
Step 4: Start capturing the packets into a file on the monitor node using tethereal -i athX -w <trace-file-name>
Step 5: Run the UDP iperf-client on the AP for about 20 seconds using iperf -c <Client-IP> -u -b <SendRate> -t 20. We will set the SendRate equal to the data rate used at the AP (E.g., 6 Mbps)
Step 6: Stop the capture after the iperf exits. Note down the achieved throughput reported by iperf. (Make sure you use the 'Server Report' for this)
Step 7: Compute the loss rate. You can find information on how do to this in the “Analyzing the wireless traces” section.

Repeat the above experiment for different data rates: 6 Mbps, 12 Mbps, 24 Mbps, 36 Mbps, 54 Mbps and try to answer the following questions: (1) How do the throughput values compare? At what data rate do you achieve the highest throughput? (2) How the does the wireless loss rate vary with the data rate?

We will repeat the above experiment, using the SampleRate rate-adaptation algorithm. For this, follow the steps in the Experiment 1, with the exception of using the following command in step 2: iwconfig athX rate auto. This will trigger the usage of SampleRate. Use a SendRate of 20M.

Now analyze the wireless trace and plot a histogram for the SampleRate algorithm with the percentage of packets sent at a given data rate (by the AP) on y-axis vs. data rate on x-axis.

In this experiment we will understand the correlation between the transmit power and the incurred wireless losses. We will use iperf tool to transmit data from the AP to the client, and alongside use the monitor node to capture the wireless trace. We will then analyze the wireless trace to compute the loss rates.

Step 1: Fix the data rate at the AP to the data rate which gave you the maximum throughput in Experiment 1.
Step 2: Fix the transmit power of the AP to the maximum (18 dBm) using iwconfig athX txpower 18. You can view the list of possible transmission powers using iwlist athX txpower.
Step 3: Create a UDP iperf-server on the client-node using iperf -s -u
Step 4: Start capturing the packets into a file on the monitor node using tethereal -i athX -w <trace-file-name>
Step 5: Run the UDP iperf-client on the AP for about 20 seconds using iperf -c <Client-IP> -u -b <SendRate> -t 20. We will set the SendRate equal to the data rate used at the AP
Step 6: Stop the capture after the iperf exits. Note down the achieved throughput reported by iperf.
Step 7: Compute the loss rate. You can find information on how do to this in the “Analyzing the wireless traces” section.

Repeat the above experiment for different transmit powers: 18 dBm, 14 dBm, 10 dBm, 6 dBm. How the does the wireless loss rate vary with the transmit power?

Your captured trace has packets sent by multiple wireless nodes. You need to first filter out the packets sent by the AP. To do that use the wireshark tool (Open using wireshark <trace-file-name>). For this set the filter to (ip.src == AP-IP && udp). Count the total number of UDP packets (TOTPKTS) sent by the AP. Now, in order to compute the wireless loss rates, find out how many of these packets have retry bit set in them. For this set the filter to (ip.src == AP-IP) && udp && !(wlan.fc.retry == 0) and count the number of retries (RETX-PKTS). We can now compute the wireless loss rate using RETX-PKTS/TOT-PKTS