Integration of OVS in OpenWrt wireless network and investigation of SDWMN

Masters in Communication Systems and Networks
Masters Research
Integration of OVS in OpenWrt Wireless
Network and Investigation of SDWMN
By
Mohammad Nazmul Hossain
Supervisor: Prof Dr. Andreas Grebe
Technische Hochschule Köln
2nd Supervisor: Constantin Eiling
Technische Hochschule Köln
Köln, June 2018
Technische Hochschule köln
Information, Media and Electrical Engineering
FH Structure NRW Research
Project BigWa, SS2018

Integration of OVS in OpenWrt Wireless Network and Investigation of SDWMN
1 | P a g e Technische Hochschule köln

Contact details:
Author:
Name : Mohammad Nazmul Hossain
 E-mail : nazmul.hossain@engineer.com
Xing : xing.com/profile/MohammadNazmul_Hossain
Linkedin : linkedin.com/in/nazmulhossainrakib
SlideShare : slideshare.net/rakib_bd
University : Techniche Hochschule Köln

Contents
1 Abstract .................................................................................................................................................. 5
2 Introduction......................................................................................................................................... 5
3 SDWMN Project Idea .......................................................................................................................... 6
4 Network fundamentals...................................................................................................................... 8
4.1 Software Defined Network ...................................................................................................... 8
4.2 OpenFlow............................................................................................................................................. 9
4.3 OpenWrt............................................................................................................................................... 9
4.4 Open vSwitch ................................................................................................................................. 10
4.5 Address Resolution Protocol (ARP)............................................................................... 11
4.6 IEEE 802.11 MAC Sub-Layer Frame.................................................................................... 13
4.7 Wireless Ad-Hoc Network....................................................................................................... 15
4.8 Wireless Distribution System........................................................................................... 16
4.9 Wireless Mesh network: ......................................................................................................... 16
4.10 802.11s MAC frame (6-address frame)........................................................................ 17
4.11 Open Virtual Network (OVN) and Virtual Controller concept ................... 18
4.11.1 OVN............................................................................................................................................ 18
4.11.2 Chassis/ovn-controller setup................................................................................ 18
4.11.3 Virtual controller concept..................................................................................... 19
5 Experiments on OVS ........................................................................................................................ 20
5.1 AD Hoc mode: ................................................................................................................................. 20
5.2 WDS mode........................................................................................................................................... 22
5.3 Mesh Using WDS mode ................................................................................................................ 23
5.4 Software Defined Mesh mode (SDWMN)............................................................................. 24
5.4.1 The mesh control header function......................................................................... 25
6 Conclusion............................................................................................................................................ 26
7 References............................................................................................................................................ 27
8 APPENDIX ................................................................................................................................................ 32
8.1 Configure OpenWrt in routers........................................................................................... 32
8.1.1 Configuration files...................................................................................................... 34
8.2 Supported Wireless radio modes.................................................................................... 38

8.3 Download and backup all packages at once............................................................ 39
8.3.1 Download.sh........................................................................................................................... 39
8.3.2 upload.sh................................................................................................................................ 40
8.3.3 install.sh ............................................................................................................................. 41
8.4 Install and remove OpenWrt packages........................................................................ 43
8.5 Setting up OVS.......................................................................................................................... 43
8.6 Configure and use OVS ......................................................................................................... 44
8.7 Backup and clone OpenWrt firmware............................................................................. 46

1 Abstract
OpenFlow managed Software Defined Network (SDN) and Wireless Mesh Network (WMN) are being an
emerging technology for their autonomous functionality and economic feasibility. SDN is somehow defined as
next generation technology which let the network configure, optimize and heal centrally using artificial
intelligence. WMN has been adopted by several applications because of its promising functionality. In this
research, applicability of SDN on WMN has been studied as well as the decentralized controller mechanism
over SDWMN (Software Defined Wireless Mesh Network). First of all, two types of Wireless connectivity (AD
Hoc and WDS) has been researched using OpenWrt configured SDN. Then probability and availability of WMN
using SDN has been investigated. Finally, some solutions has been tried to figure out for the further future
implementation of SDWMN.
2 Introduction
From the principle of Programmable network, which will take away the packet forwarding and processing
decisions from every single physical device to a centralized logical controller, the term Software Defined
Network (SDN) has been developed. SDN enables dynamic resource allocation and flexible control over the
total network as well as network policies handling such as load balancing, access control, fault tolerance etc.
OpenStack and OpenWrt (Open Wireless RouTer) are the operating systems developed for SDN. Both use Linux
kernel while OpenWrt is a cross platform to be used for wireless routers [2]. Recently OpenWrt and LEDE
(Linux Embedded Development Environment) have been merged together on 2018, while LEDE was formed in
2016 by some OpenWrt developers due to some disagreements of OpenWrt internal process. Now the OS is
known as OpenWrt/LEDE [3].
OpenFlow is the most prominent implementation of SDN. OpenFlow, an instance of the SDN architecture, is a
communication protocol consists of a set of specifications maintained by Open Networking Forum (ONF).
Openflow protocol runs between the controller and Open vSwitch. It configures the OVS by getting
instructions from the controller [4].
This paper describes the possibilities to use OVS for different types of wireless connectivity. Also the pros and
cons to use OVS for wireless connections are discussed. This paper can also be used as a reference for future
academic references.
To this end, chapter 3 introduces some basic knowledges on some wireless communications, wireless
protocols, OpenWrt, Open vSwitch as well as 802.11 MAC sub layer frame format.
Chapter 4 covers and describes the use of open virtual network (OVN) and the virtual controller which is a part
of OVN package.
Chapter 5 shows some experiments on real testbed environments using OpenWrt and their results. The TP-
Link router of Archer c7-v2 model is used to make an OpenFlow capable switch using OpenWrt. At the end of
chapter 5 some how-to is discussed for the mesh network to be executable along with SDN on OVS.

3 SDWMN Project Idea
To execute and combine the SDN and WMN together is a complex and tough work. For this research work the
initial idea was to implement a Software Defined WMN with wireless routers. The WMN is called as software
defined because, the nodes will be self-configured, self-healed and self-optimized without any help of any
network administrator. Typical WMNs are being configured by a network administrator and are being
controlled and monitored in regular basis. The goal of SDWMN is the mesh network will be administrated via
a user defined program or a software which will run as long as the mesh nodes exists.
According to the definition of SDN the data plane must be separated from the control plane and the control
plane will monitor and take decisions for the packet forwarding rules. The process works on control plane
called as controller.
The controller for the software defined wireless network can be managed using two types of wireless channels.
In-band and out-of-band [47].
The in-band control channel uses the same channel of frequency band as data traffic. The controller maintains
a different header for network management. But creates problems like interference and lower data
throughput.
The out-of-band channel for controller needs a separate interface or channel from MIMO like frequency bands.
This separate channel will not have any interference with data traffic and also optimizes data throughput.
Figure 1: Mesh network using central controller
The controller can be a centralized server (fig 1) from where the OpenFlow protocol can be run throughout
the wireless nodes. The centralized controller can be connected to one or more than one nodes. But the thing
is each node must ask the controller travelling throughout the network before process any packet.

The controller can be decentralized (fig 2), where each node can have shared controller database in its own
memory. The control database is shared either through a separate shared channel or through a different frame
header using the same channel as the data channel. The advantage is that no node needs to depend on the
node which would connect to the central controller as if there is a single centralized controller. In this situation
each node will have a controller in it’s own memory and take packet forwarding decisions from that own
controller.
Figure 2: Mesh network using distributed controller
The important thing for the decentralized controller is that the controller database needs to be synchronized
and updated regularly. Otherwise the network will not function properly as the different nodes will act
differently and the network will be unstable.
As the wireless network could have mobility (e.g. MANET, WMN), a fixed centralized controller is not a
solution. In that case we can introduce a virtual controller on each of the wireless nodes. An OpenWrt package
named OVN can do this for the wireless nodes as it has built in virtual controller in it.
The OpenFlow database must be distributed for this case and all the wireless switches will have the database
distributed to them through the virtual controllers installed in it.
This would make the mesh network self-configured, self-organized and self-healing network with the nodes
mobility capability.
To make a path from the virtual controller to the Wi-Fi interfaces, a virtual logical switch can be used. The
Open vSwitch will make it happen (fig 3). To make a wireless network (e.g. mesh network) 5 GHz interfaces
can be used. 2.4 GHz interface can be used as Access Point for the client devices. The controller also use the
5GHz channel for control traffic.

Figure 3: Internal diagram of dual band router Including
OVS and virtual controller
4 Network fundamentals
4.1 Software Defined Network
Software Defined Network (SDN) is an artificial and automated process which takes away the packet
and frame forwarding and control mechanism from the physical network devices to the programmable virtual
control section. There is a single control section for multiple (hundreds or thousands) network devices, while
the physical network devices only performs the physical connectivity with the user devices or other networks.
Through SDN network administrators can easily and quickly respond to the change in the network and business
requirements [1].
SDN consists of a Controller, which is the brain of the network and dictates the switches about how to handle
the traffic, a Southbound API which relays information to the switches and routers from the controller and a
northbound device which relays information about the application traffic to the controller (fig 4). The reader
can get a clear idea of SDN architecture from this paper published by Open Network Foundation [5].
SDN does not need any routers. All it needs is programmable switches for the infrastructure network [7]. There
could be a question about why it does not need any router or who will do the routing thing. The answer is the
control plane will deal with packet routing.
The controllers of SDN works on a principle that match criteria and apply corresponding action. That means
the controller has a bunch of rules and match criteria. When any switch receives a packet, it asks the controller
to match the rules for that packet, and the controller tells the switch what to do for that packet [8].
The match criteria can be MAC - so it behaves as a switch - L2. It can be destination IP. So it acts as a router. It
can be source MAC or source IP. Which is a part of policy based routing. Or it can be any header field from l2-
l5. It can even determine the action by using the application layer data.

Figure 4: SDN architecture
4.2 OpenFlow
A SDN controller is the brain of the SDN and it dictates the infrastructure layer about packet activities. The
communication protocol, it uses to tell packet handling rules to the programmable switches, is called
Openflow. However there are some other communication protocols for SDN, but openflow is mostly used.
The first version of OpenFlow OF 1.0 was released on 2009 [10]. After that it has been managed by Open
Network Foundation (ONF), a user-led organization dedicated to open standards and SDN adoption. The most
recent version of OpenFlow is 1.6 which is still under development.
OpenFlow works on top of Transmission Control Protocol [9]. The controller must listen to the TCP port
number ‘6653’ for the switch it want to configure.
OpenFlow enables to configure switches flow tables remotely. This protocol can add, remove and modify
packet forwarding rules in a switch. It can also make routing decisions by matching rules, packet source and
destination and application type etc. and store those rules in the switch’s flow table.
4.3 OpenWrt
OpenWrt (Open wireless RouTer) [11], an open source embedded Linux distribution which can be
installed in replacement of vendor configured operating system (OS). As named ‘Open’ this OS is open to users
and also developers to use variety of network features like SSH server, VPN, traffic-shaping system, or a Bit

Torrent client. OpenWrt components (e.g. Linux, Busy Box) have been optimized enough to fit into the limited
storage and memory available in the home routers like (Linksys, TP-Link). There are about 3500 [12]
applications packages available with OpenWrt which are available for free in cost. OpenWrt firmware is stable
for long period of times and secured as it uses Linux distribution which is by default resistant to the common
vulnerabilities.
4.4 Open vSwitch
Open vSwitch (OVS) is a virtual switch made by software [18]. It is also called as software switch. OVS
is a layer 2 multilayer switch. It is called multilayer because it can classify packets of Wrt (Wireless RouTer) IP-
Address, transport layer (layer-4) etc. But it cannot route the packet. To route the packet one has to implement
the routing algorithm by modifying the header of the OVS or applying any customized module on it.
OVS is licensed under open source Apache 2 license [18]. It supports standard management interfaces and
also open to programmers to manage and modify the switching and packet forwarding rules. OpenFlow, a
communication protocol, enables the network controller to determine the packet flow path and take control
of the Switch’s or Router’s forwarding plane. The forwarding rules of OVS can be managed by using OpenFlow.
The operation of OVS can be controlled using user interface CLI (e.g. ovs-ofctl, ovs-vsctl).
OVS also supports Linux kernel module. For the Open vSwitch version 2.9.90 kernel module supports Linux
3.10 and up [19].
OVS has several functionalities. Here is a list of functionalities listed in Open vSwitch official webpage [21]:
 Visibility into inter-VM communication via NetFlow, sFlow(R), IPFIX, SPAN, RSPAN, and GRE-tunneled
mirrors
 LACP (IEEE 802.1AX-2008)
 Standard 802.1Q VLAN model with trunking
 Multicast snooping
 IETF Auto-Attach SPBM and rudimentary required LLDP support
 BFD and 802.1ag link monitoring
 STP (IEEE 802.1D-1998) and RSTP (IEEE 802.1D-2004)
 Fine-grained QoS control
 Support for HFSC qdisc
 Per VM interface traffic policing
 NIC bonding with source-MAC load balancing, active backup, and L4 hashing
 OpenFlow protocol support (including many extensions for virtualization)
 IPv6 support
 Multiple tunneling protocols (GRE, VXLAN, STT, and Geneve, with IPsec support)
 Remote configuration protocol with C and Python bindings
 Kernel and user-space forwarding engine options
 Multi-table forwarding pipeline with flow-caching engine
 Forwarding layer abstraction to ease porting to new software and hardware platforms
The most recent OVS is supporting upto OF 1.4 perfectly. OF 1.5 and 1.6 are being supported to OVS 2.9 with
some missing features [table 1].

Table 1: Supported OpenFlow version for different versions
of Open vSwitch [22]
Open vSwitch 1.0 1.1 1.2 1.3 1.4 1.5 1.6
2.0, 2.1     - - -
2.2       -
2.3, 2.4       -
2.5, 2.6, 2.7       
2.8       
2.9       
 : supported
 : supported; missing features
 : experimental
- : not supported
4.5 Address Resolution Protocol (ARP)
In this research an Ad Hoc network using OVS Bridge has been tried to establish. Though the Ad Hoc
has been established, the problem was to communicate with the clients or client to client. To understand the
difficulties on this issue, it is necessary to understand 2-address mac header (fig 5).
When a device tries to send any to packet to another, it sends the packet to that devices mac address not to
the IP address. IP address is used only to discover the destination or any node’s physical address. Once the
destination physical address is known, the source sends packet directly to the destination [28]. The routing is
done by the router or switch using ARP cache. To discover any device’s physical address ARP is used.
Hardware type (2 octets) Protocol type (2 octets)
Hardware address
(1 octet)
Protocol address
(1 octet)
Operation code (2 octets)
Source hardware address (6 octets)
Source IP address (4 octets)
Target/Destination hardware address (6 octets)
Target/Destination IP address (4 octets)
Figure 5: ARP frame format
When the sender do not know the receiver, it sends an ARP request (Opcode: 1) as the source to the target
using the target IP address as destination IP address and ‘ff:ff:ff:ff:ff:ff’ as target physical address which is a
broadcast address (fig 6).

Figure 6: ARP request packet; captured on Wireshark
In the ARP reply (Opcode: 2) the target include it’s physical address as the source physical address and it’s IP
address as the source IP address (fig 7). The destination addresses is filled up now with source addresses from
the ARP request header [28].
Figure 7: ARP reply packet; captured on Wireshark
The above example is true if the communicating devices are directly connected. If not, the broadcast ARP
request does not reaches to the targeted device because broadcast only works on the same subnet and by
default the router does not forward the broadcasts. In that situation if the router know the destination device
through another subnet, it sends a Proxy ARP reply to the source. The source device will then update it’s ARP
table [figure 8] with the routers MAC address as the targeted device’s IP address. From now on the source
device will sends any packet destined for the destination device using routers MAC as destination MAC
address. As the router know how to reach the destination, it forwards any packet to the destination as soon

as it receives from the source. The ARP cache in the source device looks like table below (fig 8) which indicates
the router is acting as proxy ARP reply as two IP addresses are mapped to it’s single MAC address.
IP Address MAC Address
172.16.20.100 00-00-0c-94-36-ab
172.16.10.99 00-00-0c-94-36-ab
172.16.10.200 00-00-0c-94-36-bb
Figure 8: ARP table
An Ethernet bridge (or switch) is a device for forwarding packets between two or more Ethernets so that they
behave in most respects as if they were a single network.
4.6 IEEE 802.11 MAC Sub-Layer Frame
802.11 MAC (Media Access Control) is a sub layer of OSI model locates inside Data Link layer (Layer 2)
with another sub layer named Logical Link Layer (LLC) (fig. 9). LLC is the upper sub layer and MAC is the lower
sub layer of Data Link layer [29]. MAC layer can be followed by 802.3 MAC standard for wired LAN or 802.11
MAC standard for wireless LAN. Figure 10 shows the data frame format for 802.11 MAC.
Figure 9: OSI layers showing position of 802.11 MAC sub layer
While ARP in layer 2 consists of two 6-octet MAC address field in the frame header, 802.11 MAC header
consists of four 6-octet MAC address field. The transmission behavior of 802.11 MAC frame is defined by the
2-octet Frame control field (fig. 10). We will discuss the To DS and From DS sub-fields in this report [table 2].

Octets
2 2 6 6 6 2 6 2 4 0-7951 4
Frame
Control
Duration/
ID
Address
1
Address
2
Address
3
Sequence
Control
Address
4
QOS
Control
HT Control Frame
Body
FCS
Figure 10: 802.11 MAC frame format
802.11 MAC consists of four major WLAN components.
 Stations (STA), Client or Server
 Access Points (AP)
 Wireless Medium
 Distribution System (DS)
The first three components (STA, AP and Wireless Medium) are physical component while the fourth
component (DS) is a logical component. DS has two types; To DS and From DS. Table 2 shows use of address
fields with DS fields.
For the first case with To DS = 0 and From DS = 0 [table 2, table 3] the data frame does not pass through the
Distribution system (DS). That means two wireless devices (Transmitter TA and Receiver RA) are
communicating directly without help of any AP. Address 3 holds the BSSID shows that those two devices are
associated with which AP [30].
Table 2: Use of address Fields for 802.11 MAC frame header
To DS From DS Address 1 Address 2 Address 3 Address 4
0 0 Destination Source BSSID NULL
0 1 Destination Sending AP Source NULL
1 0 Receiving AP Source Destination NULL
1 1 Receiving AP Sending AP Destination Source
To DS = 0 and From DS = 1 means [table 3] the data frame exiting the DS and destined for a receiver. Address
3 is the source device in this case. Address 2 is the Transmitter AP and Address 1 is destination device or
receiver [30].
To DS = 1 and From DS = 0 acts like exactly opposite to the previous [table 3], while the data frame is destined
for the DS [30].
To Ds = 1 and From DS = 1 means [table 3] the WDS frame being distributed from one AP to another AP [table
3]. Here address 1 and address 2 holds the MAC addresses of two APs (Transmitter and Receiver) while address
3 and 4 holds the MAC addresses of source device and destination device [30].

Table 3: Meaning of To DS and From DS values for 802.11 MAC frame header
To / From DS values Meaning
To DS = 0, From DS = 0 A data frame direct from one STA to another STA within the same IBSS, as
well as all management and control type frames.
To DS = 0, From DS = 1 Data frame exiting the DS
To DS = 1, From DS = 0 Data frame destined for the DS
To DS = 1, From DS = 1 Wireless distribution system (WDS) frame being distributed from one AP to
another AP.
4.7 Wireless Ad-Hoc Network
Wireless Ad-hoc network or Mobile Ad-Hoc network (MANET) is a peer to peer network where two
peers connect and communicate directly with each other using their wireless technology (infrared, Bluetooth,
Wi-Fi etc.) [31] without depending on routers or access points while the peers can have mobility.
Figure 11: Peer to peer wireless Ad Hoc network [Source 59]
While connected, the Ad-Hoc peers communicate and exchange data directly without using any 3rd device
(fig. 11). It is useful when two devices needs to exchange or transfer or receive any information, or a group of
devices need to establish a temporary communication private communication while they are not part of any
network infrastructure [32]. Ad hoc network is a decentralized network architecture is popular solution for
peer to peer communication for the flexibility and freedom they offer.
As the Ad Hoc network do not apply any network access control, it is vulnerable to network resource
consumption attack, packet drop or delaying attack. Though authentication can protect resource consumption
attack it is still vulnerable to packet drop or delaying attack to the intermediate nodes.

4.8 Wireless Distribution System
Wireless Distribution System (WDS) is a system which enables two or more wireless access points to
communicate and transmit frames with one another [33]. WDS system is defined and standardized for 802.11
networks. WDS is simply a mechanism for constructing 802.11 frames using the 4-address format.
To establish a WDS between two base stations, the stations must be configured with same radio frequencies,
channels, SSIDs and encryption system. WDS uses IEEE 802.11 MAC sub-layer fame which is a part of data link
layer is described below.
Figure 12: 802.11 communication using 4-address mode
To set up WDS we need wireless base station and wireless repeater [35]. The base station router acts a
parent access point which bridges traffic to and from the child repeater access point. The total WDS
connection needs at least two APs and two clients or servers (fig. 12).
4.9 Wireless Mesh network:
Wireless Mesh Network (WMN) is a Mesh network where the mesh nodes are connected with each
other through wireless interfaces. In WMN the network infrastructure is decentralized because any mesh node
is only responsible to transfer data as far as the next node is [37]. Mesh nodes are small transceivers uses the
common wireless radio 802.11 standards.
WMN is very useful for inexpensive network setup, because the nodes communicate among themselves
through wireless 802.11 transceivers without requiring any cables. Only the one node is needed a cable
connection the network where internet is available like DSL internet modems.
WMNs are self-healing, self-configuring. The nodes automatically incorporates with new nodes, if any
neighbor node is disconnected, and finds a new fastest path to send data without needing any adjustments by
network administrator.
The Basic Service Set (BSS) for mesh defined in 802.11s as MBSS (Mesh Basic Service Set). It has four different
entities. [40]
 Mesh Point (MP): MP is responsible for making a mesh network by connecting to the neighbor mesh
nodes.
 Mesh Access Point (MAP): MAP works same as MP additionally it has Access Point functionality which
can connect other 802.11 devices.
 Mesh Point Portal (MPP): Any MP when have a mesh network on one side and other network on the
other side, (e.g. 802.3 network) and acts as a transaction point between this two networks, is known
as MPP.

 Station (STA): 802.11 station outside of WMN connected to the MP.
The STA located outside of wireless mesh network (WMN). The MP connected to the STA is recognized as
proxy for the STA to the entire WMN. Any node of the WMN tries to communicate to the STA, at first
forwards the frame to the proxy MP. Proxy MP then forwards the frame to the STA. This frame forwarding
mechanism on MAC sub layer is done by 6-address frame which is an additional mesh control frame header to
the existing 802.11 MAC frame.
4.10 802.11s MAC frame (6-address frame)
802.11s is the extended version of 802.11 MAC sublayer. It defines how wireless nodes creates and
behaves a wireless mesh network. Referring to the 802.11 MAC frame format 802.11s MAC includes a new 6-
24 octets Mesh control header [39]. This mesh control header consists of 1 octet of Mesh flags, 1 octet mesh
Time to Live (TTL), 4 octets of mesh sequence number and 0 - 18 octets mesh address extension. [40]
The mesh control field starts after 802.11 frame (fig. 13) and interprets as a normal payload to the 802.11 STA.
Octets
2 2 6 6 6 2 6 2 4 0-7951 4
Frame
Control
Duration/
ID
Address
1
Address
2
Address
3
Sequence
Control
Address
4
QoS
Control
HT Control Frame
Body
FCS
1 Octet 1 4 0, 6, 12 or 18
Mesh Flags Mesh
TTL
Mesh
Sequence
Number
Mesh Address Extension
AE PS Level RSPI Reserved ADD 4 ADD 5 ADD 6
Figure 13: 802.11s frame header for mesh
Referred to WDS, where the end to end communication is successful using 4 Mac addresses, mesh networks
needed additional 2 MAC addresses, because inside a mesh network there are a number of mesh nodes which
requires two MAC address fields for starting MP and destination MP, two MAC address fields for intermediate
MPs which always changes as the data frame travels through the mesh network. The starting and destination
MP MAC address needs to fix because this two MPs are the proxies to the 802.11 STAs. Any node in the mesh
network needs to know the proxy MP for outside mesh STAs to forward any data frame to those STAs. The 5th
and 6th MAC addresses are required for the source STA and destination STA. Table 4 describes how 6-address
frame operates for end to end STA to STA communication [39].
Table 4: Meaning of To DS and From DS values for 802.11s MAC frame header
To DS From DS AE Flag Address 1 Address 2 Address 3 Address 4 Address 5 Address 6
0 0 0 RA = DA TA = SA BSSID NULL N/A N/A
0 1 0 RA = DA TA = BSSID SA NULL N/A N/A
Mesh Control Header

1 0 0 RA = BSSID TA = SA DA NULL N/A N/A
1 1 0 RA TA DA NULL N/A N/A
1 1 1 RA TA Mesh DA Mesh SA DA SA
RA = Receiver Address
TA = Transmitter Address
SA = Source Address
DA = Destination Address
BSSID = Basic Service Set
4.11 Open Virtual Network (OVN) and Virtual Controller concept
4.11.1 OVN
Open Virtual Network (OVN) is an open source project is developed to support virtual network
abstraction. The goal is to provide L2 and L3 networking, security groups virtually to the existing capabilities
of OVS. OVN can be used with Openflow protocol which enables the capability to manipulate the flow tables.
An OVN consists of following parts [41]:
 OVN/Cloud Management System is a plugin that interfaces CMS to OVN. It passes the logical network
configuration stored in the CMS’s configuration database as an intermediate representation
understood by the OVN.
 OVN Northbound database receives the intermediate representation of network configuration from
CMS and stores it. It has two clients: OVS/CMS plugin above it and OVN-Northd bellow it.
 OVN-Northd receives the intermediate representation of logical network configuration from
northbound database, translates to logical datapath flow and sends to the OVS southbound database.
 OVN southbound database is the center of the OVN system. It connects bellow to the ovn-controller
and up to the northbound database. Southbound database contains three kinds of data [41]:
o Physical Network (PN) table
o Logical Network table
o Binding table, that connects logical components to the physical network
This is the important part for this research idea. This ovn-controller populates PN table and chassis column in
the Binding table. Then it connects to the OVS’s ovs-vswitchd as an OpenFlow controller and to the local ovsdb-
server to monitor and control Open vSwitch configuration.
4.11.2 Chassis/ovn-controller setup
Each chassis must have an integration bridge (an Open vSwitch bridge) which must be dedicated for
OVN. This integration bride can be configured by system startup script or it will be created automatically by
the system itself if not exist. The default configuration for the Integration Bridge and OVN controller consists
of three kinds of components:
 Tunnel ports for the logical network connectivity to the chassis
 Virtual Interfaces (VIFs) on a hypervisor to be attached on logical networks

 The port to connect logical network to the gateway. This can be a physical port or a patch port to
another bridge.
This integration bridge (fig. 14) must not be attached to other ports (e.g. physical ports). Instead they should
be attached to another Open vSwitch bridge which should be connected to the integration bridge using patch
ports [41].
The patch ports between Integration Bridge and other Open vSwitch bridge are known as Localnet ports.
Localnet ports are defined as the point of connectivity between logical switch and physical network (fig. 14).
Figure 14: Chassis architecture for OVN
There is a blog post written by Dustin Spinhirne, described in details the implementation procedure of OVN
[42].
4.11.3 Virtual controller concept
The concept was to use OVN-controller as a virtual controller for the OVS on OpenWrt installed router. On the
Open vSwitch support section [43] part 4 (Locally Attached Networks) it is said that “OVN can also be used as
a control plane to manage logically direct connectivity to networks that are locally accessible to each chassis.”
This will require some additional configuration to the controller.
That means as shown in [fig 14] a chassis connected to any bridge which could connect any physical device can
be manage as data plane by using OVN as a control plane.
OVN has Southbound and Northbound databases which can be managed and configured by using ‘ovn-sbctl’
[44] and ‘ovn-nbctl’ [45] programs. However, it is also possible to configure any OVS switch local database
using ovs-ofctl [25] command.

5 Experiments on OVS
In this experiment as OVS is installed in router, the router is called as Switch. This experiment has two routers.
Each router has one 2.4 GHz and one 5 GHz 802.11 interface. After creating the OVS on each router they
become Switch-1, Switch-2 and the 802.11 interfaces has been connected to the OVS as described in appendix.
The 5 GHz interfaces have been used for switch to switch (Switch-1 - Switch-2) connection where 2.4 GHz
interfaces have been used to connect the client devices (Client-1 and Client-2) (fig. 15). The OpenWrt Wireless
configuration file has been edited to work as Ad Hoc or WDS mode. The OVS switch is managed by OpenFlow
protocol and controlled manually using ovs-ofctl [25] without any controller.
5.1 AD Hoc mode:
Figure 15: A peer to peer Ad Hoc connection over OVS Bridge
AD Hoc mode is set up to the routers 5GHz wireless interfaces through the wireless configuration file. The 2.4
GHz interfaces is set up as Access Points (AP). APs are connected to the clients (fig. 15).
When a ping request is sent by Client-1 destined for the destination Client-2 IP, an ARP request has been
generated from Client-1 to Client-2. The ARP Req is encapsulated to the 802.11 frame and sent to Switch-1.
The OVS running on Switch-1 broadcast the ARP req through all the connected ports as well as the transmitter
AP destined for the destination IP. The address 1 of 802.11 frame is copied with the broadcast MAC address
and address 2 is copied with the Client-1 MAC address as source address. Address 3 is copied with the
Independent Basic Service Set (IBSS).
As, the ARP request packet consists broadcast MAC address, the OVS running on Switch-2 AP will forward this
packet through all ports except the receiving port. When the target client-2 get the ARP request, it generates
the ARP reply with address 1 of it’s (Client-2) MAC address as a source and address 2 as the destination device
address (Client-1). The OVS on Switch-2 forwards out this ARP Reply through it’s wireless interface.

Figure 16: ARP communication unsuccessful for 2-address mode
The WiFi interface on Switch-1 sees the ARP Reply but does not accept and process the frame because Switch-
1 does not find the destination address as it’s own MAC address and. So, Switch-1 drops the packet (fig. 16).
root@Client-1:~# ovs-dpctl dump-flows
recirc_id(0),in_port(1),eth(src=a0:a8:cd:12:50:cf,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(si
p=192.168.100.210,tip=192.168.100.3,op=1/0xff), packets:1107, bytes:46494, used:1.460s,
actions:2,3
root@Client-2:~# ovs-dpctl dump-flows
recirc_id(0),in_port(2),eth(src=a0:a8:cd:12:50:cf,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(si
p=192.168.100.210,tip=192.168.0.1,op=1/0xff), packets:0, bytes:0, used:never, actions:1,3
recirc_id(0),in_port(1),eth(src=a4:2b:b0:dd:ff:3c,dst=a0:a8:cd:12:50:cf),eth_type(0x0806),
packets:287, bytes:12054, used:2.601s, actions:2
On Client 1 ARP req is generated and sent to the –client-2
root@Client-1:~# tcpdump arp -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:31:22.094672 ARP, Request who-has 192.168.100.3 tell 192.168.100.210, length 28
On Cient 2 ARP reply is generated and sent back to the Client-2. But the reply message is dropped and is not
accepted by wlan interface of switch 1.
root@Client-2:~# tcpdump arp -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
04:54:56.974866 ARP, Request who-has 192.168.100.3 tell 192.168.100.210, length 28
04:54:56.975009 ARP, Reply 192.168.100.3 is-at a4:2b:b0:dd:ff:3c (oui Unknown), length 28

5.2 WDS mode
After configuring all the wireless interfaces of the OVS router as WDS mode another ping test has been
executed.
This time after getting the ARP REQ from Client-1 the OVS running on the Switch-1 does the following in the
802.11 MAC layer. Address 1 is copied with the Switch 2 receiver, address 2 is copied with Switch-1 transmitter,
address 3 is copied with broadcast MAC address (ff:ff:ff:ff:ff:ff) and address 4 with Client-1 MAC address. The
To DS and From DS sub header are both set to 1 (table 5).
Table 5: Address field’s status for 4 address WDS mode
To DS From DS Address 1 Address 2 Address 3 Address 4
0 0 Client-2 (Dst) Client-1 (Src) BSSID NULL
0 1 Client-2 (Dst) Switch-1 (Transmitter) Client-1 (Src) NULL
1 0 Switch-2 (Receiver) Client-1 (Src) Client-2 (DSt) NULL
1 1 Switch-2 (Receiver) Switch-1 (Transmitter) Client-2 (Dst) Client-1 (Src)
As soon as this ARP REQ is reached to the target device a ARP Reply is generated. In the reply message address
1 is set to Switch-1, address 2 is set to Switch-2, address 3 is set to Client-1 (destination device) and address 4
is set to ARP Reply source (Client-2). When the frame reached at Switch-2 from Client-2, the OVS running on
Switch-2 forwards the frame to the Switch-1 as the address 1 is set to the Switch-1 MAC. Switch-1 receives the
frame and finds the frame is destined for Client-1. As the destined client is connected to it’s AP, Switch-1
forwards the frame to the Client-1 and the communication is successful (fig. 17).
Figure 17: Successful ARP communication for 4-address WDS mode

5.3 Mesh Using WDS mode
According to the WDS mode configuration any node configured as AP will connect to nodes configured
as STA. Two STA cannot connect together or two AP cannot connect together. So if there are several nodes
need to be configure for WDS mode it is needed a single AP node and the rest STA nodes. The AP node will
connect any STA node (fig 18).
Using this AP-STA communication method a mesh network can be created where a single wireless node must
have two wireless interfaces for WDS connectivity and a third interface for wireless clients. To get this kind of
connectivity a wireless router must have tri-band capacity.
Figure 18: Mesh like network using WDS mode
There exist tri-band wireless routers in the market but it should be make sure that the router has enough
memory to be used for OpenWrt OS and there is supported OpenWrt firmware for that model of router.
Netgear R8000 AC3200 (fig 19) is supported by the OpenWrt/LEDE OS. So, this router can be used to create a
mesh like network in WDS mode. But, one should be careful before buying this routers about the firmware
availability and support, because they are expensive than dual band routers.
Tri-band routers actually consists of one 2.4 GHz antenna and two 5 GHz antennas separated in different
channels.

Figure 19: Tri band wireless router
5.4 Software Defined Mesh mode (SDWMN)
If the Wi-Fi interfaces are configured as mesh, the Linux system take control of the packet routing from
mesh nodes to mesh nodes. By default the HWMP (Hybrid Wireless Mesh Protocol) is used for mesh networks.
But, as the idea was to use the OVS Bridge instead of Linux Bridge, and the data frame would be controlled by
the OpenFlow, the frames should also be processed by the OVS. So the Linux based routing process cannot be
used.
Figure 20: Mesh path for end to end wireless device communication
To get a successful mesh communication the 6-address mode is need to be activated. If HWMP is being
activated, the 6-address mode will be in action and the mesh will be successful. But the SDWMN cannot use
and depend on the Linux kernel routing process. The mesh network must be defined and administrated by the
software, which would be the control plane of the SDWMN.
Investigating the GIT respiratory source files written in C language it is found that
“ieee80211_new_mesh_header” in ‘mesh.c’ [46] file is responsible for the 6-address mode which is

enabled if the wireless interface is configured as ‘mesh’ and the routing mechanism is then taken over by
HWMP by default. HWMP is run on Linux kernel. This function is called and linked to several c files.
5.4.1 The mesh control header function
At the line 605 of ‘mesh.c’ file in GitHub respiratory the function ieee80211_new_mesh_header
defines the mesh control header. The data type of this function is declared as unsigned int as this
function returns only non-negative values. It has four arguments. Two struct type arguments and two
const char type arguments. The const char type pointer arguments (*addr4or5 and *addr6) are
the 1st address (addr4or5) and the 2nd address (addr6) of the ae header.
[Line 605, mesh.c]
unsigned int ieee80211_new_mesh_header(
struct ieee80211_sub_if_data *sdata,
struct ieee80211s_hdr *meshhdr,
const char *addr4or5, const char *addr6)
If the AE header contains only one address, then it copies that address to the address 4.
if (addr4or5 && !addr6) {
meshhdr->flags |= MESH_FLAGS_AE_A4;
memcpy(meshhdr->eaddr1, addr4or5, ETH_ALEN);
If this conditional if statement is true, it returns the AE header length as 12 octets i.e. twice the length of the
defined ae header length.
return 2 * ETH_ALEN;
The ETH_ALEN variable (AE header length) is defined in the ether.h file at line 31.
[https://github.com/spotify/linux/blob/master/include/linux/if_ether.h]
#define ETH_ALEN 6 /* Octets in one ethernet addr */
If the AE header contains two addresses, then this function copies 1st address to address 5 and 2nd address
to address 6.
else if (addr4or5 && addr6) {
meshhdr->flags |= MESH_FLAGS_AE_A5_A6;
memcpy(meshhdr->eaddr1, addr4or5, ETH_ALEN);
memcpy(meshhdr->eaddr2, addr6, ETH_ALEN);
If this conditional else if statement is true, then it returns the header length as 18 octets i.e. triple the length
of the defined se header length.
return 3 * ETH_ALEN;
The ieee80211_new_mesh_header function is also called in net/mac80211/tx.c file three times in between
line 2500 to line 2525.

If the mesh frame is originated locally, then the header uses ieee80211_fill_mesh_addresses function. This
function takes only four addresses (SA (source address), TA (transmitter address), RA (receiver address), DA
(destination address))
[Line 572, mesh.c]
int ieee80211_fill_mesh_addresses(
struct ieee80211_hdr *hdr, __le16 *fc,
const u8 *meshda, const u8 *meshsa)
This function needs to be operate on OVS module too, to let the control plane enable and use the 6-address
protocol by itself. Or the Open vSwitch module needs to be updated to act to mesh like packets as this function.
The thing is, as SDWMN works on principle that the data plane will be separated from the control plane, the
OpenWrt OVS Bridge also should not make routing and packet forwarding decisions processed by Linux kernel.
To implement this on OVS, further investigation and research required. It would not be an easy task to solve
and requires a bit time.
6 Conclusion
Chapter 3 described the SDWMN idea behind this research hinting the fact that a virtual controller could be
used instead of a centralized controller for the mesh network, which have raised the requirement of use a
virtual switch providing by OVS. Chapter 4 mentioned some network protocols and terms which are required
to know for this research. Important sections in this chapter are 4.4 about Open vSwitch, 4.10 about 802.11s
MAC frame and 4.11 about OVN and virtual controller concept. OVN system can also be used as control plane
for the OpenWrt operated software defined network.
Chapter 5 shows some testbed experiments on AD Hoc, WDS and wireless mesh mode. However, wireless
mesh mode was not successful according to the wireless mesh and SDN definitions. According to wireless mesh
the network should have self-configured routing algorithm and redundant capability and according to the SDN
this mesh features must be controlled and configured by the control plane. But, enabling OpenWrt configured
mesh mode the mesh routing algorithm is taken over by the Linux kernel, which does not fulfils the SDN control
plane feature.
To take over the mesh routing, frame forwarding and topology control by the control layer, it needs the OVS
to be programmed to operate for 6-address frame mechanism. This mechanism is not applied on OVS yet and
not investigated further in this research. It has been planned to investigate this situation further in future and
develop the OpenWrt scripts to be operable as software defined wireless mesh network (SDWMN).

7 References
[1] Willliam Stallings, “Software Defined Networks and Openflow – The Internet protocol Journal, Volume
16, No. 1”, March 2013. <https://www.cisco.com/c/en/us/about/press/internet-
protocol-journal/back-issues/table-contents-59/161-sdn.html>
[2] OpenWrt official homepage, <https://openwrt.org/>
[3] Wikipedia, free encyclopedia, Linux Embedded Development Environment (LEDE),
<https://en.wikipedia.org/wiki/LEDE>
[4] Open networking foundation, OpenFlow Switch Specification, version 1.4.0,October 14, 2013,
<https://www.opennetworking.org/images/stories/downloads/sdn-
resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf>
[5] Open Networking Foundation, SDN Architecture Overview, version 1.0, December 12, 2013,
<https://www.opennetworking.org/images/stories/downloads/sdn-
resources/technical-reports/SDN-architecture-overview-1.0.pdf>
[6] Wikipedia, free encyclopedia, concept behind software defined network,
<https://en.wikipedia.org/wiki/Software-defined_networking#Concept>
[7] StackExchange, Network Engineering, are routers used in Software Defined Network?,
<https://networkengineering.stackexchange.com/questions/41301/are-
routers-used-in-software-defined-network>
[8] Margaret Rouse, Stan Gibilisco, SDN controller (software-defined networking controller),
<https://searchsdn.techtarget.com/definition/SDN-controller-software-
defined-networking-controller>
[9] Wikipedia, free encyclopedia, Openflow protocol,
https://en.wikipedia.org/wiki/OpenFlow
[10] SDX Central, Protocol History, “What is OpenFlow? Definition and how it relates to SDN”,
<https://www.sdxcentral.com/sdn/definitions/what-is-openflow/>
[11] PC Mag, Encyclopedia, Definition of OpenWrt,
https://www.pcmag.com/encyclopedia/term/67267/openwrt
[12] Wikipedia, the free encyclopedia, OpenWrt is an open source project,
<https://en.wikipedia.org/wiki/OpenWrt>
[13] Git, OpenWrt/LEDE source respiratory,
<https://git.openwrt.org/openwrt/openwrt.git>
[14] OpenWrt/LEDE firmware downloads, <https://downloads.openwrt.org/>
[15] LEDE Project Forum, <https://forum.lede-project.org/>

[16] LEDE firmware downloads, <https://downloads.lede-project.org/>
[17] Open vSwitch official homepage, <https://www.openvswitch.org/>
[18] Wikipedia, free encyclopedia, Open vSwitch,
<https://en.wikipedia.org/wiki/Open_vSwitch>
[19] Open vSwitch release 2.9.90, June 01, 2018,
<https://media.readthedocs.org/pdf/openvswitch/latest/openvswitch.pdf
>
[20] Open vSwitch documentation, <http://docs.openvswitch.org/en/latest/>
[21] Linux Foundation Collaborative Projects, Open vSwitch features,
<http://www.openvswitch.org/features/>
[22] Open vSwitch documentation, “using OpenFlow”
http://docs.openvswitch.org/en/latest/faq/openflow/
[23] Open vSwitch GitHub respiratory, <https://github.com/openvswitch/ovs>
[24] ovs-vsctl, utility for querying and configuring ovs-vswitchd, “Open vSwitch user Manual”,
<http://www.openvswitch.org/support/dist-docs/ovs-vsctl.8.txt>
[25] ovs-ofctl, administer OpenFlow switches, <http://www.openvswitch.org/support/dist-
docs/ovs-ofctl.8.html>
[26] The Random Security Guy, Open vSwitch Cheat Sheet,
<http://therandomsecurityguy.com/openvswitch-cheat-sheet/>
[27] Richard kuo, Open vSwitch Tutorial,
<https://github.com/rkuo/NetworkOS/blob/master/Open%20vSwitch%20Tutor
ial.md>
[28] Gorry Fairhurst, Address Resolution Protocol (ARP), December 2005,
<http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/arp.html>
[29] Pietro Nicoletti, studioreti, IEEE 802.11 frame format, june 2005,
http://www.studioreti.it/slide/802-11-Frame_E_C.pdf
[30] 802.11 Notes, components and architecture of an 802.11 network,
<http://130.216.33.163/courses/compsci314s2c/lectures/anm/WirelessNot
es.pdf>
[31] Wikipedia, free encyclopedia, wireless ad hoc network,
<https://en.wikipedia.org/wiki/Wireless_ad_hoc_network>

[32] Martinus Dipobagio, Institute of Computer Science(ICS), Freie Universität Berlin, “An overview on Ad
Hoc Networks”, <https://www.mi.fu-berlin.de/inf/groups/ag-
tech/teaching/2008-
09_WS/S_19565_Proseminar_Technische_Informatik/dipobagio09overview.pd
f>
[33] Wikipedia, “Wireless Distribution System”
<https://en.wikipedia.org/wiki/Wireless_distribution_system>
[34] IEEE P802.11, Wireless LANs, WDS clarifications,
<http://www.ieee802.org/1/files/public/802_architecture_group/802-
11/4-address-format.doc>
[35] Netgear, “what is a wireless distribution system and hoe does it work with my Nighthawk router?”,
<https://kb.netgear.com/24106/What-is-a-wireless-distribution-system-
and-how-does-it-work-with-my-Nighthawk-router>
[36] Javier Sánchez, Wi Fi 4 address frames (DS to DS mode)
<https://pdos.csail.mit.edu/pipermail/click/2009-June/008080.html>
[37] Wikipedia, the free encyclopedia, Mesh networking,
<https://en.wikipedia.org/wiki/Mesh_networking>
[38] Michalis Faloutsos, Jakob Eriksson, Srikanth V. Krishnamurthy , “DART: Dynamic Address Routing for
Scalable Ad Hoc and Mesh Networks”,
<https://ieeexplore.ieee.org/document/4100713/>
[39] W. Steven Conner, Jan Kruys, Kyeongsoo Kim, Juan Carlos Zuniga, IEEE 802.11s Tutorial Overview of
the Amendment for Wireless Local Area Mesh Networking, November 2006,
http://www.ieee802.org/802_tutorials/06-
November/802.11s_Tutorial_r5.pdf
[40] Lamia Chaari, Rim Ayadi, Lotif Kamoun, “Conception and FPGA Implementation of IEE802.11s mesh
network MAC layer transmitter”, April 2010,
<https://arxiv.org/ftp/arxiv/papers/1004/1004.4616.pdf>
[41] Open vSwitch Manual page, ovn-architecture(7),
<http://www.openvswitch.org/support/dist-docs/ovn-
architecture.7.html>
[42] Dustin Spinhirne, The OVN Gateway Router, connecting to the “data network”, September 2017,
<http://blog.spinhirne.com/2016/09/the-ovn-gateway-router.html>
[43] OVN, Tutorial, the basic OVN features, <http://www.openvswitch.org/support/dist-
docs-2.5/tutorial/OVN-Tutorial.md.html>
[44] Open vSwitch Manual, Ovn-sbctl, utility for querying and configuring OVN_southbound data-base,
<http://www.openvswitch.org/support/dist-docs/ovn-sbctl.8.txt>

[45] Open vSwitch Manual, ovn-nbctl, Open Virtual network northbound db management utility
<http://www.openvswitch.org/support/dist-docs/ovn-nbctl.8.txt>
[46] GitHub, mesh.c source file, line 605 indicating the function of mesh control header,
<https://github.com/torvalds/linux/blob/master/net/mac80211/mesh.c#L6
05>
[47] Michael Rademacher Karl Jonas, “Software-Defined Wireless Mesh Networking: Current Status and
Challenges”, The Computer Journal, 1 October
2017, <https://academic.oup.com/comjnl/article-
abstract/60/10/1520/3959606>
[48] Table of Hardware, This is the main Table of Hardware, listing all devices that are supported by
OpenWrt, <https://openwrt.org/toh/start>
[49] OpenWrt/LEDE Downloads, The most recent OpenWrt/LEDE binary releases, development snapshots
and historical releases, <https://downloads.lede-project.org/>
[50] OpenWrt firmware snapshot version, for TP-Link archer c7 v2 router,
<https://downloads.lede-
project.org/snapshots/targets/ar71xx/generic/openwrt-ar71xx-generic-
archer-c7-v2-squashfs-factory-eu.bin>
[51] Installing OpenWrt, installation user guide, <https://openwrt.org/docs/guide-
user/installation/generic.flashing>
[52] OpenWrt system configuration file, the system section contains settings that apply to the most basic
operation of the system, <https://openwrt.org/docs/guide-user/base-
system/system_configuration>
[53] OpenWrt network configuration file, the network configuration file configures the basic network
settings including network address and subnet, <https://openwrt.org/docs/guide-
user/base-system/basic-networking>
[54] OpenWrt wireless configuration file configures wireless interfaces
and operation mode, <https://openwrt.org/docs/guide-
user/network/wifi/basic>
[55] Pica8 open networking, OVS commands reference, version 3, March 2015,
<http://pleiades.ucsc.edu/doc/pica8/ovs-commands-reference.pdf>
[56] Wireless Ad Hoc Networks Bibliography,
<http://www.wu.ece.ufl.edu/wireless/ad_hoc_networks_bib.html>
[57] Flylib.com, IEEE 802.11 MAC Sub-layer Frame Structure,
<https://flylib.com/books/en/2.799.1.27/1/>

[58] IEEE 802.11 notes,
<http://130.216.33.163/courses/compsci314s2c/lectures/anm/WirelessNot
es.pdf>
[59] Andrew C. Ros, 2nd April, 2012, Make Your Tablets and Smart Phones Smarter – Add Serial
Capability for Seriously Remote Data,
<https://www.ecnmag.com/article/2012/02/make-your-tablets-and-smart-
phones-smarter-%E2%80%93-add-serial-capability-seriously-remote-data>

8 APPENDIX
8.1 Configure OpenWrt in routers
At the beginning OpenWrt was built for Linksys WRT54G router. But now it supports a lot of routers
of different models. There is a list in OpenWrt official website which specifies which model of routers are
supported by OpenWrt at this moment. [48]. To use OpenWrt in any device, the flash must be at least 4MB
for limited use of OpenWrt functionalities. But to use more applications and extend the OpenWrt
functionalities 8MB flash has been recommended by OpenWrt community. For the operation to be stable the
RAM is recommended min 32 MB and would be better if the device has 64 MB RAM.
If the hardware requirements have been met and the router model is supported in the list, then the firmware
can be downloaded for use and install in the router from LEDE official download page. It should be mentioned
that the OpenWrt and LEDE communities have merged together and working as a team which holds the
developers under one umbrella and current version OpenWrt/LEDE firmware can be found in here [49].
The most recent version of OpenWrt until now is LEDE 17.01.4 was released on Wed, 18 Oct 2017 and the
older one before LEDE 17.01.4 is Chaos Calmer 15.05.1 was released on Mon, 16 Mar 2016. This two versions
of firmware are advice to use and deploy to have a stable and secure operation. The snapshot versions can
also be used, which are updated regularly, but there is caution to use those builds at one’s own risk, because
those packages usually uploaded as soon as the developers build them without being functionality tested.
In this research as the router model was TP-Link Archer C7-V2 this firmware [50] has been used. After
downloading the firmware the next step is to download the firmware bin file to the router flash memory. Here
is some process have to be followed. First of all the router must be started in Failsafe mode.
Failsafe mode is useful for the router in three condition. First of all, if the route’s OS and all of the packages
need to be erased i.e. factory-reset. If the installed firmware is corrupted. Or if the control to the router is lost
due to any misconfiguration or wrong package installation.
However, if the router have the vendor OS installed in it, then the new OpenWrt/LEDE firmware can be
installed via OEM firmware, bootloader or JTAG. The details have been discussed here [51].
To use failsafe mode the Ethernet interface must be configured as a host to 192.168.1.1/24 network. That is
the gateway is 192.168.1.1 and subnet is 24. The host can be configure with any IP address from 192.168.1.2
- 192.168.1.254. After configuring the PC’s connected Ethernet port to the router as mentioned, the PC will be
ready to access the router for failsafe mode.
To trigger the failsafe mode the router must have a configurable button except on/off switch. For example,
reset button or Wi-Fi on/off button or something like this. To trigger failsafe mode any configurable button
needs to be pushed multiple times. The boot up LED will blink faster than normal and the router is ready in
failsafe mode. When the failsafe mode is on the router can be accessed using ‘telnet 192.168.1.1’ only if the
router is configured with a released image from OpenWrt website. But if the router has configured using a
trunk snapshot, we have to execute the command ‘ssh 192.168.1.1’ to enter the router as root.
hossain@hossain-OptiPlex-9020:~$ telnet @192.168.1.1

OR
hossain@hossain-OptiPlex-9020:~$ ssh root@192.168.1.1
=== IMPORTANT ============================
Use 'passwd' to set your login password
this will disable telnet and enable SSH
------------------------------------------
BusyBox v1.19.4 (2013-03-14 11:28:31 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
ATTITUDE ADJUSTMENT (12.09, r36088)
-----------------------------------------------------
* 1/4 oz Vodka Pour all ingredients into mixing
* 1/4 oz Gin tin with ice, strain into glass.
* 1/4 oz Amaretto
* 1/4 oz Triple sec
* 1/4 oz Peach schnapps
* 1/4 oz Sour mix
* 1 splash Cranberry juice
-----------------------------------------------------
root@(none):/#
After entering the failsafe mode the firmware needs to be downloaded to the router. Using ‘cat’ command
through port number 3333 from the Linux PC the firmware.bin file can be made ready to be downloaded to
the router.
hossain@ubuntu:~$ cat firmware.bin | pv - b | nc -l -p 3333
Then, the firmware.bin file from the Linux Pc offered through port number 3333 can be downloaded to the
router by this command.
root@(none):/# nc 192.168.1.2 3333 > /tmp/firmware.bin
If, the firmware download to the router is successful, the firmware.bin file can be found in the /tmp folder of
the router. To upgrade the router using the new firmware following command needs to be run.
root@(none):/# sysupgrade /tmp/firmware.bin
The new firmware will be installed and the router will be restarted.

8.1.1 Configuration files
After starting the router the first stem would be rename the router. This name will be shown on the terminal
after logged in the router and it will help to identify the OpenWrt installed Node identity easily. Bellow shown
the system configuration file. The second line states the hostname which is renamed as ‘Node_3’ for this
router. Normally it is written as ‘OpenWrt’ or ‘LEDE’ [52]. The time zone can also be set in this configuration
file by editing ‘option timezone’.
8.1.1.a System configuration file
root@Node_3:~# vi /etc/config/system
config system
option hostname 'Node_3'
option timezone 'UTC'
option ttylogin '0'
option log_size '64'
option urandom_seed '0'
config timeserver 'ntp'
option enabled '1'
option enable_server '0'
list server '0.openwrt.pool.ntp.org'
config led 'led_usb1'
option name 'USB1'
option sysfs 'tp-link:green:usb1'
option trigger 'usbdev'
option interval '50'
option dev '1-1'
config led 'led_usb2'
option name 'USB2'
option sysfs 'tp-link:green:usb2'
option trigger 'usbdev'
option interval '50'
option dev '2-1'
config led 'led_wlan2g'
option name 'WLAN2G'
option sysfs 'tp-link:blue:wlan2g'
option trigger 'phy1tpt'
config led 'led_wlan5g'
option name 'WLAN5G'
option sysfs 'tp-link:blue:wlan5g'

option trigger 'phy0tpt'
The network can be configured using network config file. The important part here is ‘config interface 'lan'’. In
this part the ipv4 address and subnet of the router can be configured [53].
After finishing the configuration the system must be restarted to get the configured parameters in action.
root@Node_3:~# /etc/init.d/system restart
8.1.1.b Network configuration file
root@Node_3:~# vi /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd1d:80f9:d36a::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth1.1'
option proto 'static'
option ipaddr '192.168.3.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option proto 'dhcp'
config interface 'wan6'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '2 3 4 5 0t'

config switch_vlan
option device 'switch0'
option vlan '2'
option ports '1 6t'
The wireless interfaces can be configured using wireless configuration file. The wireless operation modes are
also configured in this file [54].
root@Node_3:~# /etc/init.d/network restart
8.1.1.c Wireless configuration file
root@Node_3:~# vi /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'pci0000:01/0000:01:00.0'
option htmode 'HT20'
option disabled '0'
config wifi-iface
option device 'radio0'
option network 'br-int'
option mode 'sta'
option ssid 'hossainmesh'
option encryption 'none'
option wds '1'
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/qca955x_wmac'
option htmode 'HT20'
option disabled '0'
config wifi-iface 'default_radio1'
option mode 'ap'
option ssid 'hossain_Node_3'
#option macaddr 'a4:2b:b0:dd:fd:cb'
option wds '1'

The ‘config wifi-device’ configures the wireless cards for media access control (MAC) and physical
layer (PHY) specifications. The device name ‘radio0’ configures the 2.4 GHz interface while device name
‘radio1’ configures 5 GHz interface. To disable any interface use ‘option disabled 1’ and ‘option disabled 0’ to
enable any interface. The ‘config wifi-iface’ used to configure the wireless interfaces for different
operation modes and apply security. Bellow, shown the configuration of wireless interfaces for different
operation modes.
root@Node_3:~# /etc/init.d/wireless restart
Or, just only:
root@Node_3:~# wifi
8.1.1.d Configure for Ad Hoc
option mode 'adhoc'
To achieve successful Ad Hoc connectivity between two nodes the interfaces of those node must be
configured with same frequency band, same channel and same ssid.
8.1.1.e Configure for WDS
option mode 'ap' // The opposite node must be configured ‘sta’
option wds '1' // ‘1’ means WDS mode is on. ‘0’ means off
To achieve successful WDS connectivity between two nodes the interfaces of those node must be configured
with same frequency band, same channel and same ssid. But, the option mode must be ‘ap’ in one node and
‘sta’ in another node. Otherwise, there will be no connectivity.
8.1.1.f Configure for mesh

option mode 'mesh'
option mesh_id 'hossain_Node_3'
To achieve successful WDS connectivity between two nodes the interfaces of those node must be configured
with same frequency band, same channel and same mesh_id.
Sometimes misconfiguration could lose the connectivity and control to the OpenWrt router. To recover the
misconfiguration the router needs to restart in failsafe mode. In failsafe mode the JFFS2 partition can be
mounted and the settings can be re-edited manually.
root@(none):/#mount_root
After mounting the JFFS2 partition the configuration files can be accessed.
If the mount_root does not work, the OS can be soft factory reset:
root@(none):/# umount /overlay && firstboot && reboot
Even the OS can be hard factory reset if the soft reset does not recover the router access.
umount /overlay && firstboot && reboot
8.2 Supported Wireless radio modes
The ath9k driver is for 2.4 GHz radio interface and ath10k driver is for 5 GHz radio interface. There are several
versions and updates to this drivers [https://github.com/kvalo/ath10k-firmware]. Before continuing for any
wireless mode, one should make sure that the operation mode is supported by the installed and running driver
for the radio. To check whether the driver is supporting the required operation mode or not one can use the
following command.
root@Node_0:~# iw list
…
Part of output omitted
…
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
* mesh point
* p2p-client
* p2p-GO
…
…

valid interface combinations:
* #{ managed, WDS } <= 2048, #{ AP, mesh point } <= 8, #{ P2P
client, P2P-GO } <= 1, #{ IBSS } <= 1,
total <= 2048, #channels <= 1, STA/AP BI must match
* #{ IBSS, AP, mesh point } <= 1,
total <= 1, #channels <= 1, STA/AP BI must match, radar detect
widths: { 20 MHz (no HT), 20 MHz }
…
The required operation mode should be shown in the above list. If not, the driver firmware need to be changed.
For example, if the IBSS is not shown in the list, the interface will not work for the Ad Hoc mode.
To change the driver firmware first the installed driver needs to be removed from the OS using opkg remove
and then install the new firmware using opkg install <filename.ipk>
8.3 Download and backup all packages at once
For development and research works it is advised to download and backup all the packages for a certain date
in the local driver and use them in future. This is most important for snapshot users mainly, because snapshots
are updated upgraded and sometimes deleted from the server. So, if the versions of the packages do not
match it will not work properly as expected and produce unexpected errors. The backup can be done using
this bash script.
8.3.1 Download.sh
#!/bin/bash
echo “Hello, Please enter the link to download location: ”
read link
echo “Downloading files from $link”
for file in $(curl -s "$link" |
grep href |
sed 's/.*href="//' |
sed 's/".*//' |
grep '^[a-zA-Z].*'); do
curl -O "$link"$file
echo ""
file_name="$(ls -Art | tail -n 1)"
echo File Downloaded: "$file_name"
file_size="$(stat --printf="%s" $file_name)"
echo File Size: "$file_size"
echo ""
echo
“:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::”

echo
“:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::”
done
8.3.2 upload.sh
#!/bin/bash
echo
echo
echo Hello, Please enter the Host Ip Address '(IPv4)':
read ip_address
echo Files are uploading to the Host: $ip_address ..........
echo
echo '###############################'
echo '###############################'
echo
#ip_address = $1
#folder_name=$1
#cd $folder_name
#####################################
# node1<--5GHz-->node2<--5GHz-->node3
# | | |
# 2.4GHz 2.4GHz 2.4GHz
# | | |
# clients clients clients
# To install kmod-openvswitch_4.4.14 we need:
# kmod-gre* kmod-lib-crc32c* kmod-mpls* kmod-vxlan* kmod-nf-nat6*
# To install kmod-gre* we need:
# kmod-iptunnel*
echo ::::::::::::::::::::::::::::::::::::::::
echo Files to upload in /etc/config/ folder:
echo ::::::::::::::::::::::::::::::::::::::::
echo
scp install.sh root@$ip_address:/etc/config/
echo
echo ::::::::::::::::::::::::::::::::::::::::
echo Files to upload in /tmp/ folder:

echo ::::::::::::::::::::::::::::::::::::::::
echo
scp -r /openwrt/mips_24kc/ root@$ip_address:/tmp/
# This scp command transfers all the files and subfolder from openwrt folder to the given ip_address location
# Which actually do like following >>>
# scp download/kmod-iptunnel_4.9.87-1_mips_24kc.ipk download/kmod-gre_4.9.87-
1_mips_24kc.ipk download/kmod-crypto-hash_4.9.87-1_mips_24kc.ipk download/kmod-
crypto-crc32c_4.9.87-1_mips_24kc.ipk download/kmod-lib-crc32c_4.9.87-
1_mips_24kc.ipk download/kmod-mpls_4.9.87-1_mips_24kc.ipk download/kmod-
udptunnel4_4.9.87-1_mips_24kc.ipk download/kmod-udptunnel6_4.9.87-
1_mips_24kc.ipk download/kmod-vxlan_4.9.87-1_mips_24kc.ipk download/kmod-nf-
nat6_4.9.87-1_mips_24kc.ipk download/kmod-openvswitch_4.9.87+2.8.2-
1_mips_24kc.ipk mips_24kc/base/libpcap_1.8.1-1_mips_24kc.ipk
mips_24kc/base/zlib_1.2.11-2_mips_24kc.ipk mips_24kc/base/libopenssl_1.0.2n-
1_mips_24kc.ipk download/libpthread_1.1.19-1_mips_24kc.ipk
download/librt_1.1.19-1_mips_24kc.ipk mips_24kc/packages/openvswitch-base_2.8.2-
1_mips_24kc.ipk root@$ip_address:/tmp/
Caution: The file locations could be different for different users. The user must edit the file locations before
execute this script.
8.3.3 install.sh
#!/bin/bash
## install.sh ##
#
********************************************************************************
***********
# To install kmod-openvswitch_4.4.14 we need:
# kmod-gre* kmod-lib-crc32c* kmod-mpls* kmod-vxlan* kmod-nf-nat6*
#
********************************************************************************
***********
## To install kmod-gre* we need: kmod-iptunnel*
opkg install /tmp/kmod-iptunnel_4.9.87-1_mips_24kc.ipk
# Now install kmod-gre*
opkg install /tmp/kmod-gre_4.9.87-1_mips_24kc.ipk
## To install kmod-lib-crc32c_4.4.14 we need: kmod-crypto-crc32c*
# To install kmod-crypto-crc32c* we need:
# kmod-crypto-hash*
opkg install /tmp/kmod-crypto-hash_4.9.87-1_mips_24kc.ipk

# Now install kmod-crypto-crc32c* and kmod-lib-crc32c*
opkg install /tmp/kmod-crypto-crc32c_4.9.87-1_mips_24kc.ipk
opkg install /tmp/kmod-lib-crc32c_4.9.77-1_mips_24kc.ipk
# Install kmod-mpls*
opkg install /tmp/kmod-mpls_4.9.87-1_mips_24kc.ipk
## To install kmod-vxlan* we need: kmod-udptunnel4* and kmod-udptunnel6*
opkg install /tmp/kmod-udptunnel4_4.9.87-1_mips_24kc.ipk
opkg install /tmp/kmod-udptunnel6_4.9.87-1_mips_24kc.ipk
# Now install kmod-vxlan*
opkg install /tmp/kmod-vxlan_4.9.87-1_mips_24kc.ipk
# Install kmod-nf-nat6*
opkg install /tmp/kmod-nf-nat6_4.9.87-1_mips_24kc.ipk
# Install kmod-openvswitch_4.4.14
opkg install /tmp/kmod-openvswitch_4.9.87+2.8.2-1_mips_24kc.ipk
# **********************************************************
# To install openvswitch-base_2.8.1 we need:
# libpcap* libopenssl* librt* kmod-openvswitch*
# **********************************************************
# Install libpcap*
opkg install /tmp/libpcap_1.8.1-1_mips_24kc.ipk
## To install libopenssl* we need zlib_1.2.8
opkg install /tmp/zlib_1.2.11-2_mips_24kc.ipk
# Now Install libopenssl*
opkg install /tmp/libopenssl_1.0.2n-1_mips_24kc.ipk
## To install librt* we need libpthread_1.1.16
opkg install /tmp/libpthread_1.1.19-1_mips_24kc.ipk
# Now install librt*
opkg install /tmp/librt_1.1.19-1_mips_24kc.ipk
# Install openvswitch-base_2.8.1
opkg install /tmp/openvswitch-base_2.8.2-1_mips_24kc.ipk
# To install openvswitch-ovn-controller_2.8.1 we need:
# openvswitch-ovn-base *
opkg install openvswitch-ovn-base_2.8.1-1_ar71xx.ipk
# Now install openvswitch-ovn-controller_2.8.1
opkg install openvswitch-ovn-controller_2.8.1-1_ar71xx.ipk

Caution: The file locations could be different for different users. The user must edit the file locations before
execute this script.
8.4 Install and remove OpenWrt packages
By default the downloaded bin file has some basic and most required packages and modules included in
it. The installed packages in the router can be seen using opkg package manager. Opkg package manager
works same as package managers like apt-get, aptitude, pacman, yum, etc. of the GNU/Linux environment. To
see the installed packages using opkg.
root@NODE_0:~# opkg list
To install a new package at first copy the package from the local disk using scp
scp <file> <username>@<IP address or hostname>:<Destination>
And then install using opkg as following:
root@NODE_0:~# opkg install
The ‘/tmp’ folder is used to put any file which will not require after the router is restarted. Because it is a
temporary memory and will be erased to NULL after the router is restarted. As the internal memory of the
router is low, it is better to remove the unnecessary packages from the router. It can be done using opkg
remove command. But it is important to write the package name correctly, otherwise it will produce an
error. To be confirm the exact spelling of the package name use “opkg list” to see that package in the
OpenWrt and just copy that name.
root@NODE_0:~# opkg remove <package_name>
8.5 Setting up OVS
To install the Open vSwitch module the required *.ipk files needs to be downloaded from ‘lede download
server’ http://downloads.lede-project.org/snapshots/packages/mips_24kc/packages/. The link here provided
is the ‘snapshot version’ Firmware for the TP-Link Archer C7-V2 router. The snapshot folder always provides
the updated modules. But OpenWrt/LEDE warns the users to use those modules at own risk as those are
updated immediately from the master branch without being tested. There are some dependent libraries and
modules needs to be downloaded to make Open vSwitch work successfully. See the appendix 8.3 for details.
After installing the Open vSwitch module it can be checked that if it is working properly or not. Using command
[ovs-vsctl -V] on CLI the version of the OVS installed can be seen.
root@Node_0:~# ovs-vsctl –V
ovs-vsctl (Open vSwitch) 2.8.
DB Schema 7.15.0
The procedure to install Open vSwitch packages are shown in the appendix 8.3.

8.6 Configure and use OVS
Once successfully installed, it is time to create the first virtual bridge (fig. 21). Please note that OVS creates
only bridges in an OVS host not switches. So a number of bridges can be created in a host and they all can be
bind together if needed.
root@NODE_0:~# ovs-vsctl add-br br-int
Figure 21: Creating a bridge in OVS
This command will create a new virtual bridge including an internal port in that bridge which also named as
‘br-int’. Here br-int is the name of the new vSwitch which can be any user defined name (br0, openbr, sw1
etc.). The virtual switch just created can be verified by following command:
root@NODE_0:~# ovs-vsctl show
f6128d5e-952c-435c-ab09-60681c0b95a3
Bridge br-int
Port br-int
Interface br-int
type: internal
To create a second bridge the command is same as above and the second bridge will be just like previous one
as created above with a default internal port named as the bridge name (fig. 22).
root@NODE_0:~# ovs-vsctl add-br br-
int
f6128d5e-952c-435c-ab09-60681c0b95a3
Bridge br-int
Port br-int
Interface br-int
type: internal
cae63bc8-ba98-451a-a652-a3b0e34dc345
Bridge br-02
Port br-02
Interface br-02
type: internal

Figure 22: Creating two bridges in OVS
The router used in this project has two WLan interfaces (2.4 GHz and 5 GHz). By default this two interfaces are
configured to forward packets to the router’s physical bridge br-lan. For this project this interfaces needs to
be connected and forward packets to the virtual bridges we have just created in the Open vSwitch
environment. To connect any physical interface to the virtual bridge it required to make sure that the interface
is not connected to the Linux bridge br-int. So, delete the interface at first from the Linux Bridge.
root@NODE_0:~# brctl delif br-lan wlan0
root@NODE_0:~# brctl delif br-lan wlan1
root@NODE_0:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.a42bb0ddfdcd no eth1
We do not need the second bridge. So let us delete that bridge:
root@NODE_0:~# ovs-vsctl del-br br-02
Attach the physical wireless interfaces to the virtual bridge br-int like this (fig. 23):
root@NODE_0:~# ovs-vsctl add-port br-int wlan0
root@NODE_0:~# ovs-vsctl add-port br-int wlan1
f6128d5e-952c-435c-ab09-60681c0b95a3
Bridge br-int
Port br-int
Interface br-int
type: internal
Port “wlan0”
Interface “wlan0”
Port “wlan1”
Interface “wlan1”

Figure 23: Attaching physical interface to an OVS
8.7 Backup and clone OpenWrt firmware
It is required a lot of time and hard labor to install the same firmware and ipk packages on multiple routers.
If the number of routers operates on same network with same functionalities and packages, it will be wise to
make a router completely ready with firmware and required packages installed in it and by making the desired
configurations at first. Then, the total installed firmware, packages and configured files can be cloned to a
*.bin file and copy that cloned *.bin file all other routers.
To make a clone firmware first a clone file needs to be created.
root@NODE_0:~# cat/dev/mtd5 > /tmp/BackupFirmware.bin
This will create a BackupFirmware.bin file in the /tmp/ folder.
Next, an http server is needed which can be accessed via remote browser. To start an http server the uhttpd
needs to be installed using opkg. After installing the uhttpd package the web server can be started using start
command.
root@NODE_0:~# uhttpd start
The uhttpd configuration file is located in config folder and looks like this:
root@NODE_0:~# vi /etc/config/uhttpd
config ‘uhttpd’ ‘main’
option ‘listen_http’ 80
option ‘home’ ‘/www’

The detailed configuration options can be found here:
[https://openwrt.org/docs/guide-user/services/webserver/uhttpd]
The web server is now accessible via remote browser using the IP address of the router. For now there is no
file exist in the web server. To get the backup firmware in the web server a symbolic link needs to be created.
root@NODE_0:~# ln –s /tmp/BackupFirmware.bin /www/BackupFirmware.bin
Now, the cloned firmware can be downloaded via web browser and can be installed to the router.

Integration of OVS in OpenWrt wireless network and investigation of SDWMN

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Integration of OVS in OpenWrt wireless network and investigation of SDWMN

Similaire à Integration of OVS in OpenWrt wireless network and investigation of SDWMN (20)

Plus de Nazmul Hossain Rakib

Plus de Nazmul Hossain Rakib (9)

Dernier

Dernier (20)

Integration of OVS in OpenWrt wireless network and investigation of SDWMN