Mininet Wifi - Mininet SDN Network Emulator | Virtualized wifi
Mininet-WiFi is a fork of the Mininet SDN network emulator. The Mininet-WiFi developers extended the functionality of Mininet by adding virtualized WiFi stations and access points based on the standard Linux wireless drivers and the 80211_hwsim wireless simulation driver. They also added classes to support the addition of these wireless devices in a Mininet network scenario and to emulate the attributes of a mobile station such as position and movement relative to the access points.
The Mininet-WiFi extended the base Mininet code by adding or modifying classes and scripts. So, Mininet-WiFi adds new functionality and still supports all the normal SDN emulation capabilities of the standard Mininet network emulator.
In this post, I describe the unique functions available in the Mininet-WiFi network emulator and work through a few tutorials exploring its features.
IMPORTANT NOTE
(Updated October 20, 2017) Since I wrote this post two years ago, the Mininet-WiFi developers have continued to add a lot of functionality to Mininet-WiFi. Some of the information in this post may be outdated and no longer accurate. Please refer to the Mininet-WiFi documentation for up-to-date information about this project. At the top of that page is a link to the Mininet-WiFi manual, which is currently hosted at: https://github.com/ramonfontes/manual-mininet-wifi/raw/master/mininet-wifi-draft-manual.pdf.
Topics covered in this post
In this post, I present the basic functionality of Mininet-WiFi by working through a series of tutorials, each of which works through Mininet-WiFi features, while building on the knowledge presented in the previous tutorial. I suggest new users work through each tutorial in order.
I do not attempt to cover every feature in Mininet-WiFi. Once you work through the tutorials in this post, you will be well equipped to discover all the features in Mininet-WiFi by working through the Mininet-WiFi example scripts, and reading the Mininet-WiFi wiki and mailing list.
I assume the reader is already familiar with the Mininet network emulator so I cover only the new WiFi features added by Mininet-WiFi. If you are not familiar with Mininet, please read my Mininet network simulator review before proceeding. I have also written many other posts about Mininet.
I start by discussing the functionality that Mininet-WiFi adds to Mininet: Mobility functions and WiFi interfaces. Then I show how to install Mininet-WiFi and work through the tutorials listed below:
Tutorial #1: One access point shows how to run the simplest Mininet-WiFi scenario, shows how to capture wireless traffic in a Mininet-Wifi network, and discusses the issues with OpenFlow and wireless LANs.
Tutorial #2: Multiple access points shows how to create a more complex network topology so we can experiment with a very basic mobility scenario. It discusses more about OpenFlow and shows how the Mininet reference controller works in Mininet-WiFi.
Tutorial #3: Python API and scripts shows how to create more complex network topologies using the Mininet-WiFi Python API to define node positions in space and other node attributes. It also discusses how to interact with nodes running in a scenario with the Mininet-WiFi CLI, the Mininet-WiFi Python interpreter, and by running commands in a node’s shell.
Tutorial #4: Mobility shows how to create a network mobility scenario in which stations move through space and may move in and out of range of access points. It also discusses the available functions that may be used to implement different mobility models using the Mininet-WiFi Python API.
Mininet-WiFi compared to Mininet
Mininet-WiFi is an extension of the Mininet software defined network emulator. The Mininet-WiFi developer did not modify any existing Mininet functionality, but added new functionality.
Mininet-WiFi and Mobility
Broadly defined, mobility in the context of data networking refers to the ability of a network to accommodate hosts moving from one part of the network to another. For example: a cell phone user may switch to a wifi access point when she walks into a coffee shop; or a laptop user may walk from her office in one part of a building to a meeting room in another part of the building and still being able to connect to the network via the nearest WiFi access point.
While the standard Mininet network emulator may be used to test mobility1, Mininet-WiFi offers more options to emulate complex scenarios where many hosts will be changing the switches to which they are connected. Mininet-WiFi adds new classes that simplify the programming work required by researchers to create Mobility scenarios.
Mininet-WiFi does not modify the reference SDN controller provided by standard Mininet so the reference controller cannot manage the mobility of users in the wireless network. Researchers must use a remote controller that supports the CAPWAP protocol (NOTE: I’ve not tried this and I do not know if it will work without modifications or additional programming), or manually add and delete flows in the access points and switches.
802.11 Wireless LAN Emulation
Mininet-wifi incorporates the Linux 802.11 SoftMAC wireless drivers, the cfg80211 wireless configuration interface and the mac80211_hwsim wireless simulation drivers in its access points.
The mac80211_hwsim driver is a software simulator for Wi-Fi radios. It can be used to create virtual wi-fi interfaces that use the 802.11 SoftMAC wireless LAN driver. Using this tool, researchers may emulate a Wi-Fi link between virtual machineslab, thesis, hostapd, wpa-supplicant, docs-1, and docs-2" rel="footnote">2. The 80211_hwsim driver enables researchers to emulate the wifi protocol control messages passing between virtual wireless access points and virtual mobile stations in a network emulation scenario. By default, 80211_hwsim simulates perfect conditions, which means there is no packet loss or corruption.
You can use Wireshark to monitor wireless traffic passing between the virtual wireless access point and the virtual mobile stations in the Mininet-wifi network scenarios. But, you will find it is difficult to capture wireless control traffic on standard WLAN interfaces like ap1-wlan0 because The Linux kernel strips wireless control messages and headers before making traffic on these interfaces available to user processes like Wireshark. You will have to install additional tools and follow a complex procedure to enable monitoring of WiFi traffic on the ap1-wlan0 interface. An easier method is available: look for the hwsim0 interface on an access point, enable it, and monitor traffic on it. The hwsim0 interface replays communications sent onto the access point’s simulated wireless interface(s) such as ap1-wlan0 without stripping any 802.11 headers or control traffic3. We’ll see this in the examples we work through, below.
Mininet-WiFi display graph
Since locations of nodes in space is an important aspect of WiFi networks, Mininet WiFi provides a graphical display showing locations of WiFi nodes in a graph. The graph may be created by calling its method in the Mininet-WiFi Python API (see examples in the tutorials below).
The graph will show wireless access points and stations, their positions in space and will display the affects of the range parameter for each node. The graph will not show any “wired” network elements such as standard Mininet hosts or switches, Ethernet connections between access points, hosts, or switches.
Install Mininet-WiFi on a Virtual Machine
First, we need to create a virtual machine that will run the Mininet-WiFi network emulator.
It the example below, we will use the VirtualBox virtual machine manager because it is open-source and runs on Windows, Mac OS, and Linux.
Set up a new Ubuntu Server VM
Install Ubuntu Server in a new VM. Download an Ubuntu Server ISO image from the Ubuntu web site. See my post about installing Debian Linux in a VM. Follow the same steps to install Ubuntu.
In this example, we will name the VM Mininet-WiFi.
Set up the Mininet-WiFi VM
To ensure that the VM can display X applications such as Wireshark on your host computer’s desktop, read through my post about setting up the standard Mininet VM and set up the host-only network adapter, the X windows server, and your SSH software.
Now you can connect to the VM via SSH with X Forwarding enabled. In the example below, my host computer is t420 and the Mininet WiFi VM is named wifi. And, in this case the userid on the Mininet-WiFi VM is brian.
t420:~$ ssh -X brian@192.168.52.101
wifi:~$
Install Mininet-WiFi
In the Mininet-WiFi VM, install a few other tools and then download and compile Mininet-WiFi. The Mininet-WiFi developers created a helpful install script so the process is automatic.
wifi:~$ sudo apt-get update
wifi:~$ sudo apt-get install git make
wifi:~$ git clone https://github.com/intrig-unicamp/mininet-wifi
wifi:~$ cd mininet-wifi
Mininet WiFi is installed by a script. Run the script with the -h help option to see all the options available.
wifi:~$ util/install.sh -h
In my case, I chose to install Mininet-WiFi with the following options:
- W: install Mininet-WiFi dependencies
- n: install Mininet dependencies + core files
- f: install OpenFlow
- 3: install OpenFlow 1.3
- v: install Open Vswitch
- p: install POX OpenFlow Controller
- w: install Wireshark
So I ran the install script as follows:
wifi:~$ sudo util/install.sh -Wnf3vpw
Mininet-WiFi Tutorial #1: One access point
The simplest network is the default topology, which consists of a wireless access point with two wireless stations. The access point is a switch connected to a controller. The stations are hosts.
This simple lab will allow us to demonstrate how to capture wireless control traffic and will demonstrate the way an OpenFlow-enabled access point handles WiFi traffic on the wlan interface.
Capturing Wireless control traffic in Mininet-WiFi
To view wireless control traffic we must first start Wireshark:
wifi:~$ sudo wireshark &
Then, start Mininet-WiFi with the default network scenario using the command below:
wifi:~$ sudo mn --wifi
Next, enable the hwsim0 interface. The hwsim0 interface is the software interface created by Mininet-WiFi that copies all wireless traffic to all the virtual wireless interfaces in the network scenario. It is the easiest way to monitor the wireless packets in Mininet-WiFi.
mininet-wifi> sh ifconfig hwsim0 up
Now, in Wireshark, refresh the interfaces and then start capturing packets on the hwsim0 interface.
Start capture on hwsim0 interface
You should see wireless control traffic. Next, tun a ping command:
mininet-wifi> sta1 ping sta2
In Wireshark, see the wireless frames and the ICMP packets encapsulated in Wireless frames passing through the hwsim0 interface.
Wireshark capturing WiFi control traffic
Stop the ping command by pressing Ctrl-C. In this default setup, any flows created in the access point (that’s if they’re created — see below for more on this issue) will expire in 60 seconds.
Wireless Access Points and OpenFlow
In this simple scenario, the access point has only one interface, ap1-wlan0. By default, stations associated with an access point connect in infrastructure mode so wireless traffic between stations must pass through the access point. If the access point works similarly to a switch in standard Mininet, we expect to see OpenFlow messages exchanged between the access point and the controller whenever the access point sees traffic for which it does not already have flows established.
To view OpenFlow packets, stop the Wireshark capture and switch to the loopback interface. Start capturing again on the loopback interface. Use the OpenFlow_1.0 filter to view only OpenFlow messages.
Then, start some traffic running with the ping command and look at the OpenFlow messages captured in Wireshark.
mininet-wifi> sta1 ping sta2
I was expecting that the first ICMP packet generated by the ping command should be flooded to the controller, and the controller would set up a flows on the access point so the two stations could exchange packets. Instead, I found that the two stations were able to exchange packets immediately and the access point did not flood the ICMP packets to the controller. Only an ARP packet, which is in a broadcast frame, gets flooded to the controller and is ignored.
No OpenFlow messages passing to the controller
Check to see if flows have been created in the access point:
mininet-wifi> dpctl dump-flows
*** ap1 ------------------------------------------
NXST_FLOW reply (xid=0x4):
We see that no flows have been created on the access point. How do the two access points communicate with each other?
I do not know the answer but I have an idea. My research indicates that OpenFlow-enabled switches (using OpenFlow 1.0 or 1.3) will reject “hairpin connections”, which are flows that cause traffic to be sent out the same port in which it was received. A wireless access point, by design, receives and sends packets on the same wireless interface. Stations connected to the same wireless access point would require a “hairpin connection” on the access point to communicate with each other. I surmise that, to handle this issue, Linux treats the WLAN interface in each access point like the radio network sta1-ap1-sta2 as if it is a “hub”, where ap1-wlan0 provides the “hub” functionality for data passing between sta1 and sta2. ap1-wlan0 switches packets in the wireless domain and will not bring a packet into the “Ethernet switch” part of access point ap1 unless it must be switched to another interface on ap1 other than back out ap1-wlan0.
Stop the tutorial
Stop the Mininet ping command by pressing Ctrl-C.
In the Wireshark window, stop capturing and quit Wireshark.
Stop Mininet-Wifi and clean up the system with the following commands:
mininet-wifi> exit
wifi:~$ sudo mn -c
Mininet-WiFi Tutorial #2: Multiple access points
When we create a network scenario with two or more wireless access points, we can show more of the functions available in Mininet-WiFi.
In this tutorial, we will create a linear topology with three access points, where one station is connected to each access point. Remember, you need to already know basic Mininet commands to appreciate how we create topologies using the Mininet command line.
Run Mininet-Wifi and create a linear topology with three access points:
wifi:~$ sudo mn --wifi --topo linear,3
From the output of the command, we can see how the network is set up and which stations are associated with which access points.
*** Creating network
*** Adding controller
*** Adding hosts and stations:
sta1 sta2 sta3
*** Adding switches and access point(s):
ap1 ap2 ap3
*** Adding links and associating station(s):
(ap2, ap1) (ap3, ap2) (sta1, ap1) (sta2, ap2) (sta3, ap3)
*** Starting controller(s)
c0
*** Starting switches and access points
ap1 ap2 ap3 ...
*** Starting CLI:
mininet-wifi>
We can also verify the configuration using the Mininet CLI commands net and dump.
For example, we can run the net command to see the connections between nodes:
mininet-wifi> net
sta1 sta1-wlan0:None
sta2 sta2-wlan0:None
sta3 sta3-wlan0:None
ap1 lo: ap1-eth1:ap2-eth1
ap2 lo: ap2-eth1:ap1-eth1 ap2-eth2:ap3-eth1
ap3 lo: ap3-eth1:ap2-eth2
c0
From the net command above, we see that ap1, ap2, and ap3 are connected together in a linear fashion by Ethernet links. But, we do not see any information about to which access point each station is connect. This is because they are connected over a “radio” interface so we need to run the iw command at each station to observe to which access point each is associated.
To check which access points are “visible” to each station, use the iw scan command:
mininet-wifi> sta1 iw dev sta1-wlan0 scan | grep ssid
SSID: ssid_ap1
SSID: ssid_ap2
SSID: ssid_ap3
Verify the access point to which each station is currently connected with the iw link command. For example, to see the access point to which station sta1 is connected, use the following command:
mininet-wifi> sta1 iw dev sta1-wlan0 link
Connected to 02:00:00:00:03:00 (on sta1-wlan0)
SSID: ssid_ap1
freq: 2412
RX: 1853238 bytes (33672 packets)
TX: 7871 bytes (174 packets)
signal: -30 dBm
tx bitrate: 54.0 MBit/s
bss flags: short-slot-time
dtim period: 2
beacon int: 100
mininet-wifi>
A simple mobility scenario
In this example, each station is connected to a different wireless access point. We can use the iw command to change which access point to which each station is connected.
Note: The iw commands may be used in static scenarios like this but should not be used when Mininet-WiFi automatically assigns associations in more realistic mobility scenarios. We̢۪ll discuss how Mininet-WiFi handles real mobility and how to use iw commands with Mininet-WiFi later in this post.
Let’s decide we want sta1, which is currently associated with ap1, to change its association to ap2. Manually switch the sta1 association from ap1 (which is ssid_ap1) to ap2 (which is ssid_ap2) using the following commands:
mininet-wifi> sta1 iw dev sta1-wlan0 disconnect
mininet-wifi> sta1 iw dev sta1-wlan0 connect ssid_ap2
Verify the change with the iw link command:
mininet-wifi> sta1 iw dev sta1-wlan0 link
Connected to 02:00:00:00:04:00 (on sta1-wlan0)
SSID: ssid_ap2
freq: 2412
RX: 112 bytes (4 packets)
TX: 103 bytes (2 packets)
signal: -30 dBm
tx bitrate: 1.0 MBit/s
bss flags: short-slot-time
dtim period: 2
beacon int: 100
mininet-wifi>
We see that sta1 is now associated with ap2.
So we’ve demonstrated a basic way to make stations mobile, where they switch their association from one access point to another.
OpenFlow flows in a mobility scenario
Now let’s see how the Mininet reference controller handles this simple mobility scenario.
We need to get some traffic running from sta1 to sta3 in a way that allows us to access the Mininet-WiFi command line. We’ll run the ping command in an xterm window on sta3.
First, check the IP addresses on sta1 and sta3 so we know which parameters to use in our test. The easiest way to see all IP addresses is to run the dump command:
mininet-wifi> dump
mininet-wifi>
So we see that sta1 has IP address 10.0.0.1 and sta3 has IP address 10.0.0.3.
Next, start an xterm window on sta3:
mininet-wifi> xterm sta3
This opens an xterm window from sta3.
xterm window on sta3
In that window, run the following command to send ICMP messages from sta3 to sta1:
root@mininet-wifi:~# ping 10.0.0.1
Since these packets will be forwarded by the associated access points out a port other then the port on which the packets were received, the access points will operate like normal OpenFlow-enabled switches. Each access point will forward the first ping packet it receives in each direction to the Mininet reference controller. The controller will set up flows on the access points to establish a connection between the stations sta1 and sta3.
If we run Wireshark and enable packet capture on the Loopback interface, then filter using with of (for Ubuntu 14.04) or openflow_v1 (for Ubuntu 15.10 and later), we will see OpenFlow messages passing to and from the controller.
Wireshark capturing OpenFlow messages
Now, in the Mininet CLI, check the flows on each switch with the dpctl dump-flows command.
mininet-wifi> dpctl dump-flows
*** ap1 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
*** ap2 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
idle_timeout=60, idle_age=0, priority=65535,arp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,arp_spa=10.0.0.3,arp_tpa=10.0.0.1,arp_op=2 actions=output:3
cookie=0x0, duration=1068.17s, table=0, n_packets=35, n_bytes=1470, idle_timeout=60, idle_age=0, priority=65535,arp,in_port=3,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,arp_spa=10.0.0.1,arp_tpa=10.0.0.3,arp_op=1 actions=output:2
cookie=0x0, duration=1073.174s, table=0, n_packets=1073, n_bytes=105154, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=3,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,nw_src=10.0.0.1,nw_dst=10.0.0.3,nw_tos=0,icmp_type=0,icmp_code=0 actions=output:2
cookie=0x0, duration=1073.175s, table=0, n_packets=1073, n_bytes=105154, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,nw_src=10.0.0.3,nw_dst=10.0.0.1,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:3
*** ap3 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=1068.176s, table=0, n_packets=35, n_bytes=1470, idle_timeout=60, idle_age=0, priority=65535,arp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,arp_spa=10.0.0.3,arp_tpa=10.0.0.1,arp_op=2 actions=output:1
idle_timeout=60, idle_age=0, priority=65535,arp,in_port=1,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,arp_spa=10.0.0.1,arp_tpa=10.0.0.3,arp_op=1 actions=output:2
cookie=0x0, duration=1073.182s, table=0, n_packets=1073, n_bytes=105154, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=1,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,nw_src=10.0.0.1,nw_dst=10.0.0.3,nw_tos=0,icmp_type=0,icmp_code=0 actions=output:2
cookie=0x0, duration=1073.185s, table=0, n_packets=1073, n_bytes=105154, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,nw_src=10.0.0.3,nw_dst=10.0.0.1,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:1
mininet-wifi>
We see flows set up on ap2 and ap3, but not on ap1. This is because sta1 is connected to ap2 and sta3 is connected to ap3 so all traffic is passing through only ap2 and ap3.
What will happen if sta1 moves back to ap1? Move sta1 back to access point ap1 with the following commands:
mininet-wifi> sta1 iw dev sta1-wlan0 disconnect
mininet-wifi> sta1 iw dev sta1-wlan0 connect ssid_ap1
The ping command running on sta3 stops working. We see no more pings completed.
In this case, access points ap2 and ap3 already have flows for ICMP messages coming from sta3 so they just keep sending packets towards the ap2-wlan0 interface to reach where they think sta1 is connected. Since ping messages never get to sta1 in its new location, the access point ap1 never sees any ICMP traffic so does not request any flow updates from the controller.
Check the flow tables in the access points again:
mininet-wifi> dpctl dump-flows
*** ap1 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=40.959s, table=0, n_packets=1, n_bytes=42, idle_timeout=60, idle_age=40, priority=65535,arp,in_port=1,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,arp_spa=10.0.0.3,arp_tpa=10.0.0.1,arp_op=1 actions=output:2
cookie=0x0, duration=40.958s, table=0, n_packets=1, n_bytes=42, idle_timeout=60, idle_age=40, priority=65535,arp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,arp_spa=10.0.0.1,arp_tpa=10.0.0.3,arp_op=2 actions=output:1
*** ap2 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=40.968s, table=0, n_packets=1, n_bytes=42, idle_timeout=60, idle_age=40, priority=65535,arp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,arp_spa=10.0.0.3,arp_tpa=10.0.0.1,arp_op=1 actions=output:1
cookie=0x0, duration=40.964s, table=0, n_packets=1, n_bytes=42, idle_timeout=60, idle_age=40, priority=65535,arp,in_port=1,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,arp_spa=10.0.0.1,arp_tpa=10.0.0.3,arp_op=2 actions=output:2
cookie=0x0, duration=1214.279s, table=0, n_packets=1214, n_bytes=118972, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,nw_src=10.0.0.3,nw_dst=10.0.0.1,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:3
*** ap3 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=40.978s, table=0, n_packets=1, n_bytes=42, idle_timeout=60, idle_age=40, priority=65535,arp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,arp_spa=10.0.0.3,arp_tpa=10.0.0.1,arp_op=1 actions=output:1
cookie=0x0, duration=40.971s, table=0, n_packets=1, n_bytes=42, idle_timeout=60, idle_age=40, priority=65535,arp,in_port=1,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,arp_spa=10.0.0.1,arp_tpa=10.0.0.3,arp_op=2 actions=output:2
cookie=0x0, duration=1214.288s, table=0, n_packets=1214, n_bytes=118972, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,nw_src=10.0.0.3,nw_dst=10.0.0.1,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:1
mininet-wifi>
The controller sees some LLC messages from sta1 but does recognize that sta1 has moved to a new access point, so it does nothing. Since the controller does not modify any flows in the access points, none of the ICMP packets still being generated by sta3 will reach sta1 so it cannot reply. This situation will remain as long as the access points ap2 and ap3 continue to see ICMP packets from sta3, which keeps the old flow information alive in their flow tables.
One “brute force” way to resolve this situation is to delete the flows on the switches. In this simple example, it’s easier to just delete all flows.
Delete the flows in the access points using the command below:
mininet-wifi> dpctl del-flows
Now the ping command running in the xterm window on sta3 should show that pings are being completed again.
Once all flows were deleted, ICMP messages received by the access points do not match any existing flows so the access points communicate with the controller to set up new flows. If we dump the flows we see that the ICMP packets passing between sta3 and sta1 are now traversing across all three acces points.
mininet-wifi> dpctl dump-flows
*** ap1 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=10.41s, table=0, n_packets=11, n_bytes=1078, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,nw_src=10.0.0.1,nw_dst=10.0.0.3,nw_tos=0,icmp_type=0,icmp_code=0 actions=output:1
cookie=0x0, duration=9.41s, table=0, n_packets=10, n_bytes=980, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=1,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,nw_src=10.0.0.3,nw_dst=10.0.0.1,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:2
*** ap2 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=10.414s, table=0, n_packets=11, n_bytes=1078, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=1,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,nw_src=10.0.0.1,nw_dst=10.0.0.3,nw_tos=0,icmp_type=0,icmp_code=0 actions=output:2
cookie=0x0, duration=9.417s, table=0, n_packets=10, n_bytes=980, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,nw_src=10.0.0.3,nw_dst=10.0.0.1,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:1
*** ap3 -----------------------------------------------
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=10.421s, table=0, n_packets=11, n_bytes=1078, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=1,vlan_tci=0x0000,dl_src=02:00:00:00:00:00,dl_dst=02:00:00:00:02:00,nw_src=10.0.0.1,nw_dst=10.0.0.3,nw_tos=0,icmp_type=0,icmp_code=0 actions=output:2
cookie=0x0, duration=9.427s, table=0, n_packets=10, n_bytes=980, idle_timeout=60, idle_age=0, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=02:00:00:00:02:00,dl_dst=02:00:00:00:00:00,nw_src=10.0.0.3,nw_dst=10.0.0.1,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:1
mininet-wifi>
We have shown how the Mininet reference controller works in Mininet-WiFi. The Mininet reference controller does not have the ability to detect when a station moves from one access point to another. When this happens, we must delete the existing flows so that new flows can be created. We will need to us a more advanced remote controller, such as OpenDaylight, to enable station mobility but that is a topic outside the scope of this post.
Stop the tutorial
Stop the Mininet ping command by pressing Ctrl-C.
In the Wireshark window, stop capturing and quit Wireshark.
Stop Mininet-Wifi and clean up the system with the following commands:
mininet-wifi> exit
wifi:~$ sudo mn -c
Mininet-WiFi Tutorial #3: Python API and scripts
Mininet provides a Python API so users can create simple Python scripts that will set up custom topologies. Mininet-WiFi extends this API to support a wireless environment.
When you use the normal Mininet mn command with the –wifi option to create Mininet-WiFi topologies, you do not have access to most of the extended functionality provided in Mininet-WiFi. To access features that allow you to emulate the behavior of nodes in a wireless LAN, you need to use the Mininet-Wifi extensions to the Mininet Python API.
The Mininet-WiFi Python API
The Mininet-WiFi developers added new classes to Mininet to support emulation of nodes in a wireless environment. Mininet-WiFi adds addStation and addBaseStation methods, and a modified addLink method to define the wireless environment.
If you are just beginning to write scripts for Mininet-WiFi, you can use the example scripts as a starting point. The Mininet-WiFi developers created example scripts that show how to use most of the features in Mininet-WiFi. In all of the tutorials I show below, I started with an example script and modified it.
Mininet-Wifi example scripts are in the ~/mininet-wifi/examples directory.
Basic station and access point methods
In a simple scenario, you may add a station and an access point with the following methods in a Mininet-WiFi Python script:
Add a new station named sta1, with all parameters set to default values:
net.addStation( 'sta1' )
Add a new access point named ap1, with SSID ap1-ssid, and all other parameters set to default values:
net.addBaseStation( 'ap1', ssid='new_ssid' )
Add a wireless association between station and access point, with default values for link attributes:
net.addLink( ap1, sta1 )
For more complex scenarios, more parameters are available for each method. You may specify the MAC address, IP address, location in three dimensional space, radio range, and more. For example, the following code defines an access point and a station, and creates an association (a wireless connection) between the two nodes and applies some traffic control parameters to the connection to make it more like a realistic radio environment, adding badwidth restrictions, an error rate, and a propagation delay:
Add a station and specify the wireless encryption method, the station MAC address, IP address, and position in virtual space:
net.addStation( 'sta1', passwd='123456789a', encrypt='wpa2', mac='00:00:00:00:00:02', ip='10.0.0.2/8', position='50,30,0' )
Add an access point and specify the wireless encryption method, SSID, wireless mode, channel, position, and radio range:
net.addBaseStation( 'ap1', passwd='123456789a', encrypt='wpa2', ssid= 'ap1-ssid', mode= 'g', channel= '1', position='30,30,0', range=30 )
Add a wireless association between a station and an access point and specifiy link properties of maximum bandwidth, error rate, and delay:
net.addLink( ap1, sta1, bw='11Mbps', loss='0.1%', delay='15ms' )
To activate association control in a static network, you may use the associationControl method, which makes Mininet-WiFi automatically choose which access point a base station will connect to based on the range between stations and access points. For example, use the following method to use the strongest signal first when determining connections between station and access points:
net.associationControl( 'ssf' )
Classic Mininet API
The Mininet WiFi Python API still supports the standard Mininet node types — switches, hosts, and controllers. For example:
Add a host. Note that the station discussed above is a type of host nodem with a wireless interface instead of an Ehternet interface.
net.addHost( 'h1' )
Add a switch. Note that the access point discussed above is a type of switch that has one wireless interface (wlan0) and any number of Ethernet interfaces (up to the maximum supported by your installed version of Open vSwitch).
net.addSwitch( 's1' )
Add an Ethernet link between two nodes. Note that if you use addLink to connect two access points together (and are using the default Infrastructure mode), Mininet-WiFi creates an Ethernet link between them.
net.addLink( s1, h1 )
Add a controller:
net.addController( 'c0' )
Using the Python API, you may build a topology that includes hosts, switches, stations, access points, and multiple controllers.
Mininet-WiFi network with node positions
In the example below, I created a Python program that will set up two stations connected to two access points, and set node positions and radio range so that we can see how these properties affect the emulated network. I used the Mininet-WiFi example script 2AccessPoints.py as the base for the script shown below, then I added the position information to each node and enabled association control.
#!/usr/bin/python
from mininet.net import Mininet
from mininet.node import Controller,OVSKernelSwitch
from mininet.link import TCLink
from mininet.cli import CLI
from mininet.log import setLogLevel
def topology():
net = Mininet( controller=Controller, link=TCLink, switch=OVSKernelSwitch )
print "*** Creating nodes"
ap1 = net.addBaseStation( 'ap1', ssid= 'ssid-ap1', mode= 'g', channel= '1', position='10,30,0', range='20' )
ap2 = net.addBaseStation( 'ap2', ssid= 'ssid-ap2', mode= 'g', channel= '6', position='50,30,0', range='20' )
sta1 = net.addStation( 'sta1', mac='00:00:00:00:00:01', ip='10.0.0.1/8', position='10,20,0' )
sta2 = net.addStation( 'sta2', mac='00:00:00:00:00:02', ip='10.0.0.2/8', position='50,20,0' )
c1 = net.addController( 'c1', controller=Controller )
"""plot graph"""
net.plotGraph(max_x=60, max_y=60)
# Comment out the following two lines to disable AP
print "*** Enabling association control (AP)"
net.associationControl( 'ssf' )
print "*** Creating links and associations"
net.addLink( ap1, ap2 )
net.addLink( ap1, sta1 )
net.addLink( ap2, sta2 )
print "*** Starting network"
net.build()
c1.start()
ap1.start( [c1] )
ap2.start( [c1] )
print "*** Running CLI"
CLI( net )
print "*** Stopping network"
net.stop()
if __name__ == '__main__':
setLogLevel( 'info' )
topology()
I saved the file with the name position-test.py and made it executable.
Working with Mininet-WiFi during runtime
Mininet-WiFi python scripts may be run from the command line by running the script directly, or by calling it as part of a Python command. The only difference is how the path is stated. For example:
wifi:~/scripts $ sudo ./position-test.py
or,
wifi:~$ sudo python position-test.py
The position-test.py script will set open the Mininet-WiFi graph window and show the locations of each wireless node in space, and the range attribute of each node.
The position-test.py script running
While the scenario is running, we can query information about the network from either the Mininet-WiFi command line or from the Python interpreter and we can log into running nodes to gather information or make configuration changes.
Mininet-WiFi CLI
The Python script position-test.py places nodes in specific positions. When the scenario is running, we can use the Mininet-WiFi command line interface (CLI) commands to can check the geometric relationship between nodes in space, and information about each node.
Position
The position CLI command outputs the location of a node in virtual space as measured by three values, one for each of the vertices X, Y, and Z.
Posting Komentar