Rogue AP Detection

CHAPTER 1
INTRODUCTION
One of the most critical security concerns of IT managers today is the possibility that
rogue wireless access points may be present on the corporate network. A rogue access
point is one that the company does not authorize for operation. The trouble is that a rogue
access points often don't conform to wireless LAN (WLAN) security policies, which
enables an open, insecure interface to the corporate network from outside the physically
controlled facility.

1.1 Overview

A rogue access point is a wireless access point that has been installed on a secure
network without explicit authorization from a local network administrator [1], whether
added by a well-meaning employee or by a malicious attacker. Although it is technically
easy for a well-meaning employee to install a "soft access point" or an
inexpensive wireless router - perhaps to make access from mobile devices easier - it is
likely that they will configure this as "open", or with poor security, and potentially allow
access to unauthorized parties. Figure 1.1 shows an unknown AP is connected to
company’s network. If an attacker installs an access point they are able to run various
types of vulnerability scanners, and rather than having to be physically inside the
organization, can attack remotely - perhaps from a reception area, adjacent building, car
park, or with a high gain antenna, even from several miles away.

Figure 1.1 An unknown AP is connected to company’s network

Department of ECE, JSS S&TU, Mysuru Page 1

 Rogue AP Detection

To prevent the installation of rogue access points, organizations can install wireless
intrusion prevention systems to monitor the radio spectrum for unauthorized access
points. Presence of a large number of wireless access points can be sensed in airspace
of a typical enterprise facility. These include managed access points in the secure
network plus access points in the neighborhood. A wireless intrusion prevention system
facilitates the job of auditing these access points on a continuous basis to learn whether
there are any rogue access points among them. In order to detect rogue access points,
two conditions need to be tested:

1. whether or not the access point is in the managed access point list
2. whether or not it is connected to the secure network

The first of the above two conditions is easy to test - compare wireless MAC address
(also called as BSSID) of the access point against the managed access point BSSID list.
However, automated testing of the second condition can become challenging in the light
of following factors:

 Need to cover different types of access point devices such as bridging, NAT
(router), unencrypted wireless links, encrypted wireless links, different types of
relations between wired and wireless MAC addresses of access points, and soft
access points.
 Necessity to determine access point connectivity with acceptable response time in
large networks.
 Requirement to avoid both false positives and negatives which are described
below.

If an unauthorized access point is found connected to the secure network, it is the

rogue access point of the first kind (also called as “wired rogue”). On the other hand, if
the unauthorized access point is found not connected to the secure network, it is an
external access points. Among the external access points, if any is found to be
mischievous or potential risk (e.g., whose settings can attract or have already attracted
secure network wireless clients), it is tagged as rogue access point of the second kind,
which is often called an "evil twin".

Department of ECE, JSS S&TU, Mysuru Page 2

 Rogue AP Detection

A "soft access point" (soft AP) can be set up on a Wi-Fi adapter using for example
Windows' virtual Wi-Fi or Intel's My Wi-Fi. This makes it possible, without the need of a
physical Wi-Fi router, to share the wired network access of one computer with wireless
clients connected to that soft AP. If an employee sets up such a soft AP on their machine
without coordinating with the IT department and shares the corporate network through it,
then this soft AP becomes a rogue AP [2].

1.2 Problem Description

Rogue AP poses serious security threat to a wired enterprise network as it provides

a wireless backdoor into the enterprise network for outsiders, bypassing all wired security
measures such as firewalls and network access control (NAC). A rogue AP may also
deliberately flood Wi-Fi network with management messages that brings down capacity
and performance of Wi-Fi network. Rogue AP threats operates at layer below antivirus
and wired IDS Protection.

1.3 Aim

The Nokia’s solution for the Rogue AP detection allows operator to configure the
Access Points in one of the three supported modes using Graphical User Interface (GUI)
or by bulk importing the AP configuration data. cWLC also supports provisioning of White
list of BSSIDs which operator can configure to ensure that the known non-Registered
neighbors are not detected as Rogue. The “BSSID White List” can be provisioned by
manually adding up to 4K entries using GUI.

1.4 Literature Survey

Jim Geier [1] discuss the most critical security concerns of IT managers today is the
possibility that rogue wireless access points may be present on the corporate network. A
rogue access point is one that the company does not authorize for operation. The trouble
is that a rogue access points often don't conform to wireless LAN (WLAN) security
policies, which enables an open, insecure interface to the corporate network from outside
the physically controlled facility.

Department of ECE, JSS S&TU, Mysuru Page 3

 Rogue AP Detection

Within a properly secured WLAN, rogue access points are more damaging than rogue
users. Unauthorized users trying to access a WLAN likely will not be successful at
reaching valuable corporate resources if effective authentication mechanisms are in
place. Major issues arise, however, when an employee or hacker plugs in a rogue access
point. The rogue allows just about anyone with an 802.11-equipped device on the
corporate network, which puts them very close to mission-critical resources.

Ajay Kumar Gupta [2] describes the newly launched Microsoft Windows7 operating
system now makes it easy for users to turn their laptops and netbooks into a soft access
point. This soft access point can be configured on the built-in Wi-Fi adapter or on an
external Wi-Fi adapter plugged into a Windows 7 machine. Free software applications
from the web, such as the one provided by connectively, offer an easy-to-use interface to
configure such access points, with various options.

A soft access point configured on a Windows 7 machine functions almost similar to a

physical Wi-Fi access point to which other Wi-Fi devices can connect to as Wi-Fi clients.
Also, it allows users to share a particular network accessible on the laptop with connected
Wi-Fi clients. A soft access point running on a user’s Windows 7 machine enables the
creation of a Wi-Fi personal area network (PAN), which is easy to setup, easy to carry,
and managed by the user. Thus, a Windows 7 user is no longer required to carry a
physical access point device and the optional power charger cord for this device to setup
a Wi-Fi PAN.

In addition, users are relieved from accessing and going through the complex
configuration screens of a typical physical access point device. Although a traditional Wi-
Fi ad-hoc mode is also available for users to set up their Wi-Fi PAN without the need for
a physical access point, the virtual Wi-Fi capabilities of Windows 7 has advantages over
this mode due to two basic facts.

Torvalds, Linus [3] explains the experience with Linux in maintaining a large
distributed development project, along with his intimate knowledge of file system
performance gained from the same project and the urgent need to produce a working

Department of ECE, JSS S&TU, Mysuru Page 4

 Rogue AP Detection

system in short order. GIT supports rapid branching and merging, and includes specific
tools for visualizing and navigating a non-linear development history.

In GIT, a core assumption is that a change will be merged more often than it is written,
as it is passed around to various reviewers. In GIT, branches are very lightweight: a
branch is only a reference to one commit. With its parental commits, the full branch
structure can be constructed. Torvalds has described GIT as being very fast and scalable
and performance tests done by Mozilla showed it was an order of magnitude faster than
some version control systems, and fetching version history from a locally stored repository
can be one hundred times faster than fetching it from the remote server.

Robotframework.org [4] describes the Robot Framework is operating system and

application independent. The core framework is implemented using Python and runs also
on Jython (JVM) and IronPython (.NET). Robot Framework itself is open source software
released under Apache License 2.0, and most of the libraries and tools in the ecosystem
are also open source. The framework was initially developed at Nokia Networks and it is
nowadays sponsored by Robot Framework Foundation.

Kawaguchi, Kohsuke; et al [5] explains how Jenkins helps to automate the non-human
part of the software development process, with continuous integration and facilitating
technical aspects of continuous delivery. It is a server-based system that runs in servlet
containers such as Apache Tomcat. It supports version control tools, including AccuRev,
CVS, Subversion, Git, Mercurial, Perforce, ClearCase and RTC, and can execute Apache
Ant, Apache Maven and sbt based projects as well as arbitrary shell scripts and Windows
batch commands.

1.5 Organization of Report

The Chapter 1 contains the brief introduction about project, problem statement, and
the literature survey. Chapter 2 is about the brief introduction about Nokia’s Airscale Wi-
Fi architecture. Chapter 3 describes the software tools used for automation and language
which is used. Chapter 4 explains about cwlc, AP functionalities and configuration
parameters for various pages.

Department of ECE, JSS S&TU, Mysuru Page 5

 Rogue AP Detection

Chapter 5 is about test scenarios for the feature. Chapter 6 shows the result analysis
and discussion, where the snapshots and discussion are shown about the project.
Chapter 7 explains conclusion, advantages and limitations of the project.

Department of ECE, JSS S&TU, Mysuru Page 6

 Rogue AP Detection

CHAPTER 2

NOKIA AIRSCALE WI-FI ARCHITECTURE

Nokia Wi-Fi Controller is a cloud based Wi-Fi controller which provides centralized
management for a large set of Nokia Wi-Fi APs. Apart from managing Wi-Fi AP, controller
also enables network optimization features to provide greater RF efficiency and better
end user experience. Wi-Fi controller terminates management and control plane from AP
while bearer is directly sent from AP to internet or a Wi-Fi gateway.

2.1 cWLC
The Nokia Wi-Fi system consists of Nokia Wi-Fi AP’s (Indoor and Outdoor Models)
and Nokia Cloud based Wi-Fi Controller (cWLC). Nokia Wi-Fi portfolio contains 2X2 and
3X3 indoor and outdoor Wi-Fi APs supporting 802.11a/b/g/n/ac Wi-Fi technologies. Nokia
Wi-Fi system is integrated with the operator’s core network (carrier Wi-Fi) via the Wi-Fi
Gateway.

2.1.1 cWLC Overview

cWLC is a standalone cloud based controller which is hosted on a generic IT

platform. Currently cWLC supports an open stack based cloud infrastructure. One cWLC
can support multiple APs and STA devices. Number of APs and STA devices supported
by a cWLC depends on number of cores available to run cWLC application. Up to 1024
WLAN can be configured on a cWLC. Operator has flexibility to configure authentication
type and authentication/accounting server per WLAN.

2.1.2 Interfaces/Protocol

Wi-Fi controller terminates management and control plane from AP while bearer is
directly sent from AP to internet or a Wi-Fi gateway. The cWLC and AP are interfaced
using NWAM [Nokia Wi-Fi AP Management] and radius protocols. The NWAM protocol
is used for Management and Control interface for Wi-Fi AP whereas the radius protocol
is used for Interface for exchanging authentication and accounting messages. Both
MWAM and radius protocols uses https as the ports. Figure 2.1 provides an overview of

Department of ECE, JSS S&TU, Mysuru Page 7

 Rogue AP Detection

interfaces supported by cWLC platform. Table 2.1 provides a more detailed description
of each interface.

Figure 2.1 cWLC External Interfaces

NE Interface Name Description Protocol/Port

cWLC <->AP NWAM (Nokia Management and Control https
Wi-Fi AP interface for Wi-Fi AP.
Management)
cWLC <->AP Radius Interface for exchanging https
Authentication and
accounting messages
cWLC <->EMS SNMP Interface for uploading SNMPv2/v3
alarms and stats
cWLC <->Traffic Restful Interface for Wi-Fi Restful
Orchestrator management and traffic
steering
cWLC <->NTP Radius Interface for clock NTP
Server synchronization
cWLC <->AAA Radius Interface for exchanging UDP
Server Authentication and
accounting messages
cWLC <->Captive WISPr Interface for https
Portal authenticating STA with
external portal

Table 2.1 cWLC External Interfaces

Department of ECE, JSS S&TU, Mysuru Page 8

 Rogue AP Detection

2.1.3 Deployment Model

cWLC is a standalone cloud based controller which is hosted on a generic IT

platform. cWLC application runs on Open Stack based cloud infrastructure.

Two delivery models are supported for cWLC application:

 cWLC application code, cloud framework and IT Hardware is delivered and

managed by Nokia.
 cWLC application code is delivered by Nokia, IaaS (Infrastructure as a service )
is owned by operator.

Nokia provided cloud framework includes OpenStack, KVM hypervisor and RHEL7
components along with the controller platform.

2.1.4 cWLC Platform

The HP’s rack mount server, DL 380p G8 server is currently being targeted as the
hardware for cloud based Wireless Controller (cWLC). DL380p G8 details are provided
in the Table 2.2

Table 2.2 cWLC Platform Details

Department of ECE, JSS S&TU, Mysuru Page 9

 Rogue AP Detection

2.1.5 Nokia Wi-Fi cWLC Architecture

Nokia cWLC is a cloud based application which supports Open Stack based cloud.
Open Stack cloud framework can be provided either by Nokia or by operator. Nokia
provided cloud framework includes Open Stack, KVM hypervisor and RHEL7components
along with controller platform. cWLC application should support any Open Stack based
cloud. Some of the features on cWLC application may depend heavily on underlying cloud
framework and these features may not be available fully if underlying cloud framework
does not support required features.

2.2 Nokia Airscale Wi-Fi Access Point

The Nokia Wi-Fi system consists of Nokia Wi-Fi AP’s (Indoor and Outdoor Models)
and Nokia Cloud based Wi-Fi Controller (cWLC). Nokia Wi-Fi portfolio contains 2X2 and
3X3 indoor and outdoor Wi-Fi APs supporting 802.11a/b/g/n/ac Wi-Fi technologies. Nokia
Wi-Fi system is integrated with the operator’s core network (carrier Wi-Fi) via the Wi-Fi
Gateway.

2.2.1 Wi-Fi AP Overview

Nokia Wi-Fi AP terminates 802.11 a/b/g/n/ac air interfaces from STA devices. Nokia
Wi-Fi AP is based on Qualcomm Atheros chipset and Qualcomm Soc. Details of
Qualcomm chipset and Soc are following:

 2X2 Wi-Fi AP
o Scorpion SoC (QCA 9557)

o Perigrine QCA 9892 – 2x2/2s-80 (802.11ac)

In Nokia Wi-Fi AP open source OpenWRT software is used as base software and
value added features are added by Nokia. Control and Management traffic from AP is
forwarded to cWLC in a secure tunnel. For bearer traffic AP supports L2oGRE tunnel to
Wi-Fi gateway or local breakout at AP can be done. L2oGRE tunnel or local breakout
decision is done per SSID based on configuration at cWLC. Nokia Wi-Fi AP architecture
consists of Nokia modules and OpenWRT modules.

Department of ECE, JSS S&TU, Mysuru Page 10

 Rogue AP Detection

2.2.2 Access Point Architecture

Nokia Wi-Fi AP architecture is explained in the Figure 2.2

Figure 2.2 Wi-Fi AP architecture

2.2.3 Wi-Fi AP State Transition

Wi-Fi AP States and state transition diagram is described in Figure 2.3:

• Idle – AP boots up and start with idle state. AP gets its IP address either by DHCP
or IP address statically allocated. If AP cannot discover its own IP address, AP will
start a back off timer and restart IP discovery again.

• Controller Discovery – AP learns controllers IP address. Multiple controllers’ IP

address can be learned during this process. Controller IP will be provisioned
manually during first release. After learning controller IP address, AP starts
registration process with controller and creates a connection with controller. If
connection establishment is successful, AP will transition to registered state else
it will move back to idle state.

• Registered state – AP starts a timer and waits for either configuration or image
download from controller. If timer expires and configuration/image download is not
triggered, AP will transition controller discovery state.

• Configure – Controller starts FTP to download configuration data to AP. Once

configuration download is successful, AP either moves to Reset or Run state.

Department of ECE, JSS S&TU, Mysuru Page 11

 Rogue AP Detection

Figure 2.3 Wi-Fi AP State Transition Diagram

• Image Data – Controller starts FTP to download AP firmware to AP. Once

download is successful, AP either moves to reset state.

• Run – AP moves to run state when configuration download is successful and

configuration data passes sanity checks. Controller can update configuration data
during Run State.

 Reset – AP moves to reset state after image download, configuration download,

operator action or some fault. After Reset AP moves back to idle state and starts
process to discover AP and controller IP address.

2.3 User Interface

Nokia Wi-Fi system also supports Wi-Fi operations without Wi-Fi Gateway where
bearer from Wi-Fi AP is directly sent to the internet.

2.3.1 Controller GUI

The Controller (cWLC) provides GUI for the management of Access Points and
the controller itself – including the monitoring of Wireless Clients.

Following sub-sections layout the governing principles for designing effective GUI
and specify the architectural foundation for building modern yet simple GUI.

Department of ECE, JSS S&TU, Mysuru Page 12

 Rogue AP Detection

2.3.2 Characteristics

The characteristics of GUI are

 Simple: GUI should have default values and basic or advanced kind of
prioritization.
 Clarity: GUI should have clear typography, color, texture, labels & messages and
tooltips.
 Familiarity: GUI should use standard icons and real-life metaphors so that it can
be familiar to the user.
 Aesthetics: GUI should have proper layout, alignment, grouping and contrast.
 Responsive: GUI should loads quickly and provides feedback on the progress.
 Consistent: GUI shoud develops usage patterns like uniform layout, elements,
icons, and placement.
 Efficient: GUI should have minimize eye and hand movement so that it takes a
shorter navigation paths.
 Forgiving: GUI should support undo actions to prevent errors and easy recovery
from erroneous inputs

2.3.3 Interface Element Types

Design of the element types (accordion, table, text field/area and everything that
appears on the user interface) is required to be done carefully as they are the building
blocks of an effective GUI. The common element types that a user interface should have:

 Input Controls
 Text Fields: Textbox is used for allowing a user to enter some text on the
GUI.
 Checkboxes: Checkbox is used to provide a list of options in which the user
can choose multiple choices.
 Radio Buttons: Radio button is used to showcase a list of items out of which
the user can choose one.

Department of ECE, JSS S&TU, Mysuru Page 13

 Rogue AP Detection

 Dropdowns: Dropdown is used to provide a list of options in which the user

can choose one among all the options.
 List Boxes: List boxes are used when multiple selections are permitted or a
specific visible size has been specified.
 Navigational Components
 Menu: Menu is used for navigate to user defined page.
 Breadcrumb: Breadcrumb navigation provide links back to each previous page
the user navigated through, and shows the user's current location in a website.
 Search: Search boxes on web pages are used to allow users to enter a query
to be searched to a Web page.
 Pagination: Pagination is used to divide a document into discrete pages.
 Informational Components
 Labels: Label is used for knowing an information for the particular field. It
cannot edited by the user.
 Tooltips: Tooltip is a message which appears when a cursor is positioned over
an icon, image, hyperlink, or other element in a graphical user interface.
 Icons: Icon is used to point and click with a mouse on GUI.
 Progress Bar: Progress bar is used to show a user how far the task is in
process.
 Containers
 Accordion: An accordion is used to show HTML content.
 Table: Table is a structure which has rows and columns on a Web page.

2.3.4 Architectural Goals

The architectural goals for building standards-based GUI and for providing
directions to the backend implementation are:

 GUI should be a web application.

 GUI should be based on the latest web application architecture.
 GUI should be based on open standards & technologies.
 GUI should leverage existing open source software libraries.

Department of ECE, JSS S&TU, Mysuru Page 14

 Rogue AP Detection

 GUI should provide user experience similar to RIA and as close as possible to
Desktop application.
 GUI should support cross-browser compatibility.
 GUI should support multiple screen resolutions.
 GUI should be extensible to support newer client types like Mobile App.

2.3.5 Web Application Architecture

First-generation web applications followed the architecture where all of GUI Logic
and Application Logic resided together on the server while the client (browser) simply
displays the content returned by server. The client model is shown in Figure 2.4 which
does not have any intelligence.

Figure 2.4 Web Application Architecture - 1st Generation

2.3.6 Technologies & Frameworks

The Technologies and Frameworks used for the implementation are:

 HTML5 + CSS3 + JavaScript + JavaScript Framework: HTML5 is a markup

language used for structuring and presenting content on the World Wide Web. It
is the fifth and current major version of the HTML standard. Cascading Style
Sheets (CSS) is a style sheet language used for describing the look and formatting
of a document written in a markup language (HTML). JavaScript is used as a
programming language for the behavior of the webpage.
 AJAX: It is an Asynchronous JavaScript and XML. AJAX is not a programming
language.

Department of ECE, JSS S&TU, Mysuru Page 15

 Rogue AP Detection

AJAX just uses a combination of: A browser built-in XMLHttpRequest object (to
request data from a web server) JavaScript and HTML DOM (to display or use the
data)

 Bootstrap: Bootstrap is an open source toolkit for developing with HTML, CSS,
and JS.
 jQuery: The purpose of jquery is to make the task easier by using javascript on the
webpage.
 JavaFX: JavaFX is a Java library used to build Rich Internet Applications. The
applications written using this library can run consistently across multiple
platforms.
 Silverlight: Silverlight is a powerful development tool for creating engaging,
interactive user experiences for Web applications.
 Google Web Toolkit (GWT): GWT Web Toolkit is an open source set of tools that
allows web developers to create and maintain complex JavaScript front-
end applications in Java.

Department of ECE, JSS S&TU, Mysuru Page 16

 Rogue AP Detection

CHAPTER 3
SOFTWARE TOOLS
Feature testing is an essential and time-consuming activity. Therefore, automation of any
aspect of software test engineering can reduce testing time and, in the long-run, reduce
costs for the testing activity.

3.1 Automation Testing

Automation Testing means using an automation tool to execute the test case suite.
The automation software can also enter test data into the system under Test, compare
expected and actual results and generate detailed test reports. Successive development
cycles will require execution of same test suite repeatedly. Using a test automation tool,
it's possible to record the test suite and re-play it as required. Once the test suite is
automated, no human intervention is required. This improved ROI of Test Automation.
The goal of Automation is to reduce the number of test cases to be run manually and not
to eliminate Manual testing altogether.

Automation testing is important due to the reasons:

 Manual Testing of all workflows, all fields and all negative scenarios is time
consuming.
 It is difficult to test for multilingual sites manually.
 Automation does not require Human intervention. It can be executed overnight.
 Automation increases the speed of test execution.
 Automation helps increase Test Coverage.
 Manual Testing can become boring and hence error-prone.

3.2 GIT

GIT is a version control system for tracking changes in computer files and
coordinating work on those files among multiple people. It is primarily used for source
code management in software development, but it can be used to keep track of changes

Department of ECE, JSS S&TU, Mysuru Page 17

 Rogue AP Detection

in any set of files. As a distributed revision control system, it is aimed at speed [4], data
integrity and support for distributed, non-linear workflows.

It has 3 states as shown in Figure 3.1

 Committed (stored in local database)

 Modified (file changed but not committed to database)
 Staged (modified file is marked to go into the next commit snapshot)

Figure 3.1 Flow Diagram for GIT states

SETUP: GIT configures user information used across all local repositories.

git config --global user.name “[firstname lastname]”

--This command is used to set a name that is identifiable for credit when review version
history.

git config --global user.email “[valid-email]”

--This command is used to set an email address that will be associated with each history
marker.
Department of ECE, JSS S&TU, Mysuru Page 18
 Rogue AP Detection

git config --global color.ui

--This command is used to auto set automatic command line coloring for GIT for easy
reviewing.

SETUP & INIT: GIT configures user information, initializing and cloning repositories.

git init

--This command is used to initialize an existing directory as a GIT repository.

git clone [url]

--This command is used to retrieve an entire repository from a hosted location via URL.

STAGE & COMMIT: After the changes are done in local repository, changes are move to
main branch.

git status

--This command is used to show modified files in working directory.

git add [file]

--This command is used to add a file as it looks now to your next commit (stage).

git reset [file]

--This command is used to unstage a file while retaining the changes in working directory.

git diff

--This command is used to show what is changed but not staged.

git diff --staged

--This command is used to show what is staged but not yet commited.

git commit -m “[descriptive message]”

--This command is used to commit your staged content as a new commit snapshot.

Department of ECE, JSS S&TU, Mysuru Page 19

 Rogue AP Detection

BRANCH & MERGE: Isolating work in branches, changing context, and integrating
changes.

git branch

--This command is used to list the branches.

git branch [branch-name]

--This command is used to create a new branch at the current commit.

git checkout

--This command is used to switch to another branch and check it out into working
directory.

git merge [branch]

--This command is used to merge the specified branch’s history into the current one.

git log

--This command is used to show all commits in the current branch’s history.

3.2.1 Advantages of GIT

Free and open source

Git is released under GPL’s open source license. It is available freely over the
internet. We can use Git to manage propriety projects without paying a single penny. As
it is an open source, you can download its source code and also perform changes
according to your requirements.

Fast and small

As most of the operations are performed locally, it gives a huge benefit in terms of
speed. Git does not rely on the central server; that is why, there is no need to interact with
the remote server for every operation performed. The core part of Git is written in C, which
avoids runtime overheads associated with other high level languages.

Department of ECE, JSS S&TU, Mysuru Page 20

 Rogue AP Detection

Though Git mirrors entire repository, the size of the data on the client side is small.
This illustrates the efficiency of Git at compressing and storing data on the client side.

Implicit backup

The chances of losing data are very rare when there are multiple copies of it. Data
present on any client side mirrors the repository, hence it can be used in the event of a
crash or disk corruption.

Security

Git uses a common cryptographic hash function called secure hash function
(SHA1), to name and identify objects within its database. Every file and commit is check-
summed and retrieved by its checksum at the time of checkout. It implies that it is
impossible to change file, date, and commit message and any other data from the Git
database without knowing Git.

No need of powerful hardware

In case of CVCS, the central server needs to be powerful enough to serve requests
of the entire team. For smaller teams, it is not an issue, but as the team size grows, the
hardware limitations of the server can be a performance bottleneck. In case of DVCS,
developers don’t interact with the server unless they need to push or pull changes. All the
heavy lifting happens on the client side, so the server hardware can be very simple
indeed.

Easier branching

CVCS uses cheap copy mechanism. If we create a new branch, it will copy all the
codes to the new branch, so it is time-consuming and not efficient. Also, deletion and
merging of branches in CVCS is complicated and time-consuming. But branch
management with Git is very simple. It takes only a few seconds to create, delete, and
merge branches.

Department of ECE, JSS S&TU, Mysuru Page 21

 Rogue AP Detection

3.3 RIDE: Robot Framework and Data Editor

Robot Framework is a generic test automation framework for acceptance testing

and acceptance test-driven development (ATDD). It has easy-to-use tabular test data
syntax and it utilizes the keyword-driven testing approach. Its testing capabilities can be
extended by test libraries implemented either with Python or Java, and users can create
new higher-level keywords from existing ones using the same syntax that is used for
creating test cases.

Robot Framework project is hosted on Git Hub where you can find further
documentation, source code, and issue tracker. Downloads are hosted at Py PI. The
framework has a rich ecosystem around it consisting of various generic test libraries and
tools that are developed as separate projects.

Framework is operating system and application independent. The core framework

is implemented using Python and runs also on Python (JVM) and Iron Python (.NET).
Robot Framework itself is open source software released under Apache License 2.0, and
most of the libraries and tools in the ecosystem are also open source. The framework
was initially developed at Nokia Networks and it is nowadays sponsored by Robot
Framework Foundation. The Robot Framework IDE (RIDE) is the integrated development
environment to implement automated tests for the Robot Framework. The Robot
Framework is a generic test-automation framework.

The latest available version of RIDE is currently 0.40.1, which has been used as a
basis for this blog post. First releases of this tool have been a little bit bumpy, but it can
be seen that a lot of progress has been made in the meantime. A minor stumbling block
was the download, as the hosting of the project is currently in a transition phase from
Google Code to Git Hub. The download for releases up to 0.39.1 is still available from the
old RIDE pages at Google Code. The newer downloads are only available from Git Hub.
The download and the installation as such have been running smoothly on my Windows
XP machine. On first start up one big change was immediately visible for a veteran RIDE
user.

Department of ECE, JSS S&TU, Mysuru Page 22

 Rogue AP Detection

There is a new panel that allows editing of open files as plain text. But first things
first. Once a test suite has been loaded (or alternatively a whole directory containing
several test suites) it will be displayed in a tree-like structure on the left hand side of the
editor. For each test suite individual test cases can be selected for editing from this
navigation tree. It is positive that every referenced resource file is automatically loaded
and shown in the navigation tree under External Resources. As long as the test suite is
selected it is possible to configure its global settings, for example Suite-Setup and Suite-
Teardown. A big advantage of the Robot-IDE is the support in configuring different
aspects of test suites. Writing everything manually one might not even be aware that
some features exist.

Together with the very complete Robot Framework documentation this really helps
in writing test cases with the Robot Framework. When clicking on the Edit-Button a new
window pops up for editing as shown in Figure 3.2. Sometimes part of the syntax has to
be known and entered here as well. For example the separation of arguments for a
keyword using the pipe symbol.

Figure 3.2 RIDE Window

Figure 3.3 RIDE Suite Setup

Department of ECE, JSS S&TU, Mysuru Page 23

 Rogue AP Detection

To edit an individual test case one has to select that test case from the navigation
tree first. Generic fields for this test case – for example documentation and tagging – can
then be defined in the upper part of the editor. In the lower part the test case is written in
tabular format as a sequence of corresponding keyword calls as shown in Figure 3.3.
Thereby the keyword is written in the first column and all possible parameters in the other
columns. A simple testcase for search in the google is as shown in Figure 3.4 and Figure
3.5.

Figure 3.4 RIDE Test case

Figure 3.5 RIDE Edit Window

A quick test shows that changes in the text editor show up in the visual editor and
vice versa. Switching between both views is thus working very smoothly and as expected.

Department of ECE, JSS S&TU, Mysuru Page 24

 Rogue AP Detection

Of course one is expecting further support for the daily implementation work from
an IDE. RIDE implements this support already for some time by offering an auto
completion for keywords. This can be activated by pressing “CTRL-Space” when entering
a keyword as shown in Figure 3.6.

In an empty field this will then show all available – read from all included test
libraries – keywords. Otherwise it is possible to start typing and then get the auto
completion for all keywords starting with the already typed text.

Figure 3.6 RIDE Edit Window if CTRL-Space is used

For those keywords that are defined in included resource files it is in possible to
jump to the corresponding definition directly performing a double click on that keyword
in the test definition (or another keyword definition).

A very nice feature is the possibility to also perform this operation in the other
direction, thus finding all places where a specific keyword has been used. This can be
done by pressing the button Find Usages in the corresponding editor page. This feature
exists as well for all keywords included via test libraries.

Therefore, it is first of all possible to get an overview of all those keywords under
the menu option “Tools -> Search Keywords” as shown in Figure 3.7

Department of ECE, JSS S&TU, Mysuru Page 25

 Rogue AP Detection

Figure 3.7 RIDE Information Window

As already mentioned it is also possible here to search for all places in all open
files where such a keyword is used. This is especially useful when refactoring test cases.
By pressing on one of the search results RIDE jumps directly to the corresponding place
in the editor.

3.4 Jenkins

Jenkins is a free software [5] that allows continuous integration. Jenkins will be
installed on a server where the central build will take place. Figure 3.8 shows a simple
workflow of how Jenkins works.

Figure 3.8 Jenkins Flowchart

Department of ECE, JSS S&TU, Mysuru Page 26

 Rogue AP Detection

3.4.1 Continuous Integration

Continuous Integration is a development practice that requires developers to

integrate code into a shared repository at regular intervals. This concept was meant to
remove the problem of finding later occurrence of issues in the build lifecycle. Continuous
integration requires the developers to have frequent builds. The common practice is that
whenever a code commit occurs, a build should be triggered. The system requirements
for Jenkins is shown in Table 3.1.

JDK JDK 1.5 or above

Memory 2 GB RAM (recommended)

Disk Space No minimum requirement. Note that since all builds will be
stored on the Jenkins machines, it has to be ensured that
sufficient disk space is available for build storage.

Operating System Version Jenkins can be installed on Windows, Ubuntu/Debian, Red

Hat/Fedora/CentOS, Mac OS X, openSUSE, FReeBSD,
OpenBSD, Gentoo.

Java Container The WAR file can be run in any container that supports Servlet
2.4/JSP 2.0 or later.(An example is Tomcat 5).

Table 3.1 System requirements for Jenkins

3.4.2 Download Jenkins

By default, the latest release and the Long-Term support release will be available
for download. The past releases are also available for download. Click the Long-Term
Support Release tab in the download section. Click the link “Older but stable version” to
download the Jenkins war file.

Department of ECE, JSS S&TU, Mysuru Page 27

 Rogue AP Detection

3.4.3 Starting Jenkins

Open the command prompt. From the command prompt, browse to the directory
where the Jenkins. War file is present. Run the following command After the command is
run, various tasks will run, one of which is the extraction of the war file which is done by
an embedded webserver called win stone. Once the processing is complete without major
errors, the following line will come in the output of the command prompt. Once Jenkins is
up and running, one can access Jenkins from the link − http://localhost:8080. This link will
bring up the Jenkins dashboard as shown in Figure 3.9.

Figure 3.9 Dashboard for Jenkins

3.5 Programming Language: Python

Python is well known for its dynamic and simple nature. All languages compete
hard with Python in its reduced code version in few lines and quality for a common
scenario. Selenium is reliable to be used with most of the popular languages but synced
with Python it produces great results.

Department of ECE, JSS S&TU, Mysuru Page 28

 Rogue AP Detection

Features of Python

 Easiness in coding and readability.

 Runs faster when compared with popular languages such as Java.
 Dynamic typing nature when compared with the static typing nature of Java.
 Advantageous over traditional complex braces system through simple
indentations.
 The Python APIs can be empowered to connect with the browser through
Selenium.

Department of ECE, JSS S&TU, Mysuru Page 29

 Rogue AP Detection

CHAPTER 4

DESIGN AND IMPLEMENTATION

Rogue AP poses serious security threat to a wired enterprise network as it provides a

wireless backdoor into the enterprise network for outsiders, bypassing all wired security
measures such as firewalls and network access control (NAC). A rogue AP may also
deliberately flood Wi-Fi network with management messages that brings down capacity
and performance of Wi-Fi network as shown in Figure 4.1.

Figure 4.1 Rogue AP Devices

4.1 Different Modes

The Nokia’s Cloud Wireless Controller (cWLC) provides the capability for operator to
provision different types of APs for performing Rogue AP detection. When this feature

Department of ECE, JSS S&TU, Mysuru Page 30

 Rogue AP Detection

enabled, Nokia Wi-Fi APs can be configured in one of the following modes as shown in
Figure 4.2.

Figure 4.2 Different types of Modes

Dedicated detection mode: The APs configured in this mode will not support traffic. The
APs in this mode will perform both active (Probe request/Probe response) scanning and
passive (Beacon listening) scanning. During an active scan, the client radio transmits a
probe request and listens for a probe response from an AP as shown in Figure 4.3

Figure 4.3 Active Scanning

Department of ECE, JSS S&TU, Mysuru Page 31

 Rogue AP Detection

With a passive scan, the client radio listens on each channel for beacons sent
periodically by an AP. A passive scan generally takes more time, since the client must
listen and wait for a beacon versus actively probing to find an AP. Another limitation with
a passive scan is that if the client does not wait long enough on a channel, then the client
may miss an AP beacon.

On-demand detection mode: The APs configured in this mode will support both traffic
and Rogue AP detection. The APs will be selected by the cWLC, with proprietary Rogue
AP detection (RAPD) algorithm, for performing the Rogue AP detection. The Figure 4.4
shows the TCP dumps at cWLC for on demand mode scan initiation. The detection will
be done at per Band level as shown in Figure 4.5. When selected, an AP will first perform
detection on 5 GHz band. To start the detection clients will be dis-associated from the 5
GHz band and the active scanning will be performed. After completing the scan the scan
results are sent to cWLC and the traffic is enabled back on the 5 GHz band. After
completing the 5 GHz scan, the 2.4 GHz scan is started by dis-associating all the clients
on that band. After the scan is completed the scan result is sent to cWLC and the traffic
is enabled again on 2.4 GHz band.

Figure 4.4 TCP dump at cWLC

Department of ECE, JSS S&TU, Mysuru Page 32

 Rogue AP Detection

Figure 4.5 Detection band levels

Sniffer tool is used to capture the active and passive scan. Sniffer capture for on-
demand scan is shown in Figure 4.6

Figure 4.6 Sniffer capture for on-demand scan

No-detection mode: The APs configured in this mode will only support traffic.

Department of ECE, JSS S&TU, Mysuru Page 33

 Rogue AP Detection

4.2 AP Functionality

The APs will receive their mode as part of configuration download from cWLC. The
mode can be changed from cWLC, which will be conveyed to AP in the change request
message. The AP will take a maximum of 10 minutes to honor the mode change request
from cWLC. The APs which are provisioned in dedicated detection mode will perform the
scanning in both Active and passive mode. A configurable timer defines the mode in which
such APs will perform the periodic scanning of different types. The view of Nokia’s Wi-Fi
AP is shown in Figure 4.7

Figure 4.7 Nokia’s Wi-Fi AP

Upon expiry of the configurable timer, such APs will perform the active scanning by
sending Probe request for all the configured SSIDs and also for the “Wildcard SSID” in
all the channels, as per configured country code, of both the bands. Upon getting the
Probe response message, AP will switch to passive scanning by listening to the Beacons.
The APs will generate the combined neighbor report from the Active and Passive scans
and send the neighbor report to cWLC upon expiry of configurable report timer. The
interface between cWLC and AP is shown in Figure 4.8.

Figure 4.8 Interface between cWLC and AP

Department of ECE, JSS S&TU, Mysuru Page 34

 Rogue AP Detection

The APs which are provisioned in On-Demand detection mode will perform only active
scanning. Active scanning is performed by sending the Probe request for all the
configured SSIDs and also for the “Wildcard SSID” in all the channels, as per configured
country code, of both the bands. The Active scanning will be done in one band at a time.
The APs will first perform the active scanning in 5 GHz band and then will perform the
active scanning in 2.4 GHz band.

The APs provisioned in this mode, when selected to do scanning, will start the
scanning in 5 GHz band by disassociating all the clients which are connected to this AP
in 5 GHz band. Upon receipt of the Probe responses, AP will create the neighbor report
and send to cWLC. Upon completion of the 5 GHz scan, AP will enable the clients on 5
GHz band and disassociate all the clients on the 2.4 GHz band. Upon receipt of the Probe
responses for 2.4 GHz band, AP will create the neighbor report and send to cWLC.

4.2 cWLC Functionality

The Nokia’s solution for the Rogue AP detection allows operator to configure the
Access Points in one of the three supported modes using Graphical User Interface (GUI)
or by bulk importing the AP configuration data. cWLC also supports provisioning of White
list of BSSIDs which operator can configure to ensure that the known non-Registered
neighbors are not detected as Rogue. The “BSSID White List” can be provisioned by
manually adding up to 4K entries using GUI. cWLC also provides a capability to import a
file in the prescribed format to auto-populate the “BSSID White List”. cWLC will run a
proprietary RAPD algorithm to select APs provisioned in the “On-Demand detection”
mode to perform the scanning to detect neighbors. At any point of time, cWLC will select
a maximum of operator configured percentage of APs for doing scanning under a
particular Zone.

cWLC will receive separate neighbor reports for each of the band. Upon receipt of
neighbor reports from the APs, cWLC will decipher if the reported neighbor is a rogue AP
or legitimate AP by running the RAPD (Rogue AP Detection) algorithm. cWLC will check
if the reported neighbor is Configured or Registered. The methodology of cWLC is as
shown in Figure 4.9

Department of ECE, JSS S&TU, Mysuru Page 35

 Rogue AP Detection

Figure 4.9 cWLC functionality

cWLC will check if the reported neighbor is Configured or Registered. If the

reported neighbor is Configured or Registered, cWLC will mark the neighbor as legitimate
neighbor and take no further action on that neighbor. If the reported neighbor is neither in
the Configured list nor in the registered list, then cWLC will check if the reported neighbor
exists in the pre-configured BSSID white list. If the reported neighbor is in pre-configured
BSSID white list, cWLC will mark the neighbor as legitimate neighbor and take no further
action on that neighbor. If the reported neighbor is neither present in Configured or
Registered list nor in BSSID white list, then cWLC detects that neighbor as Rogue AP
and updates the Rogue AP list.

4.3 Configuration Parameters

Configuration parameters are used for a wide range of services, from basic to specific
server operations, and for performance tuning. These parameters are added as part of
Rogue AP feature for the following pages:

 Wi-Fi AP Page
 AP Group Page
 Zone Page
 Rogue AP List Page

Department of ECE, JSS S&TU, Mysuru Page 36

 Rogue AP Detection

4.3.1 Wi-Fi AP Page

The parameters which are included for the Wi-Fi AP page are

 LastScanTime: This is the textbox field in which presents the previously scanned
time of the AP.
 RogueAPDetection: This is the dropdown field which shows all different modes of
Rogue AP Detection i.e, Dedicated, on demand and no detection mode as shown
in Figure 5.9
 MaxRogueAPDetectorPerZone: This is the textbox field which presents number of
rogue AP detectors are configured for one zone.
 RogueAPDetectorMode: This is the checkbox field which is a parent filed for all
other fields. When this is enabled rogue AP detection will be processed.
 ScanResultReportInterval: This is the textbox field which shows the time taken by
AP to generate report after scanning.
 ActiveScanInterval: This is the textbox field which shows the time taken by AP to
undergo active scanning.
 ScanGuardInterval: This is the textbox field which shows the time taken by AP to
undergo passive scanning.

Figure 4.10 View of Wi-Fi AP Page

Department of ECE, JSS S&TU, Mysuru Page 37

 Rogue AP Detection

4.3.2 Zone Page

The parameters which are included for the Zone page are

 RogueAPDetection: This is the dropdown field which shows all different modes of
Rogue AP Detection i.e, Dedicated, on demand and no detection mode.
 MaxRogueAPDetectorPerZone: This is the textbox field which presents number of
rogue AP detectors are configured for one zone.
 RogueAPDetectorMode: This is the checkbox field which is a parent filed for all
other fields. When this is enabled rogue AP detection will be processed.
 ScanResultReportInterval: This is the textbox field which shows the time taken by
AP to generate report after scanning.
 ActiveScanInterval: This is the textbox field which shows the time taken by AP to
undergo active scanning.
 ScanGuardInterval: This is the textbox field which shows the time taken by AP to
undergo passive scanning.

The configuration parameters for Zone page is shown in Figure 4.11.

Figure 4.11 View of Zone Page

Department of ECE, JSS S&TU, Mysuru Page 38

 Rogue AP Detection

4.3.3 AP Group Page

The parameters which are included for the AP Group page are

 RogueAPDetection: This is the dropdown field which shows all different modes of
Rogue AP Detection i.e, Dedicated, on demand and no detection mode.
 RogueAPDetectorMode: This is the checkbox field which is a parent filed for all
other fields. When this is enabled rogue AP detection will be processed.
 ScanResultReportInterval: This is the textbox field which shows the time taken by
AP to generate report after scanning.
 ActiveScanInterval: This is the textbox field which shows the time taken by AP to
undergo active scanning.
 ScanGuardInterval: This is the textbox field which shows the time taken by AP to
undergo passive scanning.

The configuration parameters for AP Group page is shown in Figure 4.12.

Figure 4.12 View of AP Group Page

Department of ECE, JSS S&TU, Mysuru Page 39

 Rogue AP Detection

4.3.4 Rogue AP List Page

The parameters which are included for the Rogue AP List Page are

 RogueAPBSSID: It is the MAC address of an Rogue AP

 FirstSeenTime: It is time in which Rogue AP is seen first.
 LastSeenTime: It is time in which Rogue AP is seen last.
 DetectorAPId: It is the MAC address of detector AP
 SSIDName: It is the Name of the network
 FrequencyBand: It can be 2.4 or 5Ghz
 ChannelNo: It is the channel number of the rogue AP

View of Rogue AP list Page is as shown in Figure 4.13 and Figure 4.14

Figure 4.13 View of Rogue AP List Page

Figure 4.14 View of Rogue AP List Page

Department of ECE, JSS S&TU, Mysuru Page 40

 Rogue AP Detection

CHAPTER 5

SCENARIOS INCLUDED FOR ROGUE AP DETECTION

Robot Framework test cases are created using test case tables in test case files. Such a
file automatically creates a test suite from all the test cases it contains. There is no upper
limit for how many test cases there can be, but it is recommended to have less than ten,
unless the data-driven approach is used, where one test case consists of only one high-
level keyword.

The project consists of 20 automation feature testing testcases. The testcases can
be executed individually or altogether. If all testcases are selected to be run, if one
testcase fails in between then it continuous with the other testcase. Later the failed
testcase can be debugged using the log. It mainly consist of 2 suites.

 Scanning Suite
 Rogue AP Detection Suite

5.1 Scanning Suite

The various variables are used in suite level for initializing the values as shown in
Figure 5.1. The suite includes the active and passive scanning of an AP. It does not detect
the Rogue AP. Only AP in ACTIVE state is considered for scanning.

Figure 5.1 RIDE view of variables used

Department of ECE, JSS S&TU, Mysuru Page 41

 Rogue AP Detection

Test Case 01: Only AP in Active state is considered for scan

The testcase is used to verify whether cWLC picks up AP whose Telephony state
is Active and does not pick up AP whose Telephony state is Registered Unlocked or OOS
Unlocked. The RIDE view of the testcase is as shown in Figure 5.2

Figure 5.2 RIDE view of Test Case 01

Test Case 02: AP with procedural state set to config change or None is
considered for scan

The testcase is used to verify whether cWLC picks up AP whose Telephony state
is Active and Procedural State is CONFIGURATION CHANGE or None. The RIDE view
of the testcase is as shown in Figure 5.3

Figure 5.3 RIDE view of Test Case 02

Department of ECE, JSS S&TU, Mysuru Page 42

 Rogue AP Detection

Test Case 03: AP in SW download is not considered for scan

The testcase is used to verify whether cWLC not picks up AP whose Telephony
state is Active and Procedural State is SW download. The RIDE view of the testcase is
as shown in Figure 5.4

Figure 5.4 RIDE view of Test Case 03

Test Case 04: AP in SW activation is not considered for scan

The testcase is used to verify whether cWLC not picks up AP whose Telephony
state is Active and Procedural State is SW activation. The RIDE view of the testcase is
as shown in Figure 5.5

Figure 5.5 RIDE view of Test Case 04

Department of ECE, JSS S&TU, Mysuru Page 43

 Rogue AP Detection

Test Case 05: AP in cWLC transition is not considered for scan

The testcase is used to verify whether cWLC not picks up AP whose Telephony
state is Active and Procedural State is cWLC movement. The RIDE view of the testcase
is as shown in Figure 5.6

Figure 5.6 RIDE view of Test Case 05

Test Case 06: AP in locking is not considered for scan

The testcase is used to verify whether cWLC not picks up AP whose Telephony
state is Active and Procedural State is locking. The RIDE view of the testcase is as shown
in Figure 5.7

Figure 5.7 RIDE view of Test Case 06

Department of ECE, JSS S&TU, Mysuru Page 44

 Rogue AP Detection

Test Case 07: Only APs under zone with feature enabled is considered for scan

This testcase is used to verify whether the AP is configured with Rogue AP feature.
The RIDE view of the testcase is as shown in Figure 5.8

Figure 5.8 RIDE view of Test Case 07

5.2 Rogue AP Detection Suite

It includes the active and passive scanning and validate the neighbor report by
the cWLC. The variables used in the suite as shown in Figure 5.9

Figure 5.9 RIDE view of variables used

Department of ECE, JSS S&TU, Mysuru Page 45

 Rogue AP Detection

Test Case 08: On Sending Perform Active Scan AP should send Neighbor Report
for 2.4 and 5 GHz with valid fields

The testcase is used to verify whether AP send the neighbor report to cwlc for both
band levels 2.4G and 5 GHz. The RIDE view of the testcase is as shown in Figure 5.10

Figure 5.10 RIDE view of Test Case 08

Test Case 09: Configure AP in Nodetection mode and Verify AP responding to

Perform Active Scan with NACK and Not sending Neighbor report

This testcase is used to verify whether AP does not send neighbor report to cwlc.
The RIDE view of the testcase is as shown in Figure 5.11

Figure 5.11 RIDE view of Test Case 09

Department of ECE, JSS S&TU, Mysuru Page 46

 Rogue AP Detection

Test Case 10: Configure AP in Dedicated mode and verify the SSIDs are not
Transmitting and AP sends Neighbor report for two intervals

The testcase is used to verify whether AP sends neighbor report for 2.4G and 5
GHz to cwlc. The RIDE view of the testcase is as shown in Figure 5.12

Figure 5.12 RIDE view of Test Case 10

Test Case 11: Disable the Rogue AP Feature at AP and send Perform Neighbour
Scan then AP should send response with NACK

The testcase is used to verify whether AP sends response to cwlc by disabling

rogue AP feature or not. The RIDE view of the testcase is as shown in Figure 5.13

Figure 5.13 RIDE view of Test Case 11

Department of ECE, JSS S&TU, Mysuru Page 47

 Rogue AP Detection

Test Case 12: After Perform Scan and Neighbor Report Perform MAC call and see
if it connects while AP is not scanning and perform download

The testcase is used to verify whether AP sends the neighbor report to cwlc or not.
The RIDE view of the testcase is as shown in Figure 5.14

Figure 5.14 RIDE view of Test Case 12

Test Case 13: Verify if AP retries Neighbor Report Once on not sending response
and AP returns to the original channel in on demand mode if ACS is disabled

The testcase is used to verify whether AP does not send the neighbor report to
cwlc after scanning, it retries once again in the same channel if ACS mode is disabled.
The RIDE view of the testcase is as shown in Figure 5.15.

Figure 5.15 RIDE view of Test Case 13

Department of ECE, JSS S&TU, Mysuru Page 48

 Rogue AP Detection

Test Case 14: AP should do rogue AP detection in all channels in dedicated mode
even if channels are blacklisted

The testcase is used to verify whether AP will undergo rogue AP detection in

dedicated mode. The RIDE view of the testcase is as shown in Figure 5.16

Figure 5.16 RIDE view of Test Case 14

Test Case 15: Call should be disconnected while triggering Active Scan in on
demand mode in 2.4 GHz

The testcase is used to verify whether Clients will be disconnected while AP is

triggered with Active scan.The RIDE view of the testcase is as shown in Figure 5.17.

Figure 5.17 RIDE view of Test Case 15

Department of ECE, JSS S&TU, Mysuru Page 49

 Rogue AP Detection

Test Case 16: Call should be disconnected while triggering Active Scan in on
demand mode in 5 GHz

The testcase is used to verify whether Clients will be disconnected while AP is

triggered with Active scan. The RIDE view of the testcase is as shown in Figure 5.18

Figure 5.18 RIDE view of Test Case 16

Test Case 17: AP should do perform Active scan only in 5 GHz if power state of 2.4
GHz is 0

The testcase is used to verify whether AP will undergo active scanning only in 5
Ghz or not. The RIDE view of the testcase is as shown in Figure 5.19

Figure 5.19 RIDE view of Test Case 17

Department of ECE, JSS S&TU, Mysuru Page 50

 Rogue AP Detection

Test Case 18: AP should do perform Active scan only in 2.4 GHz if power state of 5
GHz is 0

The testcase is used to verify whether AP will undergo active scanning only in 2.4
Ghz or not. The RIDE view of the testcase is as shown in Figure 5.20

Figure 5.20 RIDE view of Test Case 18

Test Case 19: AP should do rogue AP detection in only 5 ghz if power state of
2.4ghz is 0

The testcase is used to verify whether AP will undergo rogue AP detection only in
5 Ghz or not. The RIDE view of the testcase is as shown in Figure 5.21

Figure 5.21 RIDE view of Test Case 19

Department of ECE, JSS S&TU, Mysuru Page 51

 Rogue AP Detection

Test Case 20: AP should do rogue AP detection in only 2.4 ghz if power state of
5ghz is 0

The testcase is used to verify whether AP will undergo rogue AP detection only in
2.4 Ghz or not. The RIDE view of the testcase is as shown in Figure 5.22.

Figure 5.22 RIDE view of Test Case 20

5.3 Logs

After writing the testcase in the “TextEdit” window of the RIDE, save the file. Initially
the log is set as “TRACE” by passing “-L TRACE” in the arguments. The scenario is
executed by clicking “Run” button. After execution of testcase, log is generated. Log is
opened by clicking “Log” icon in RIDE. The testcase logs are shown in Figure 5.23

Department of ECE, JSS S&TU, Mysuru Page 52

 Rogue AP Detection

Department of ECE, JSS S&TU, Mysuru Page 53

 Rogue AP Detection

Figure 5.23 Testcase logs

Department of ECE, JSS S&TU, Mysuru Page 54

 Rogue AP Detection

CHAPTER 6

RESULT

cWLC will check if the reported neighbor is Configured or Registered. If the reported
neighbor is Configured or Registered, cWLC will mark the neighbor as legitimate neighbor
and take no further action on that neighbor. If the reported neighbor is neither in the
Configured list nor in the registered list, then cWLC will check if the reported neighbor
exists in the pre-configured BSSID white list. If the reported neighbor is in pre-configured
BSSID white list, cWLC will mark the neighbor as legitimate neighbor and take no further
action on that neighbor. If the reported neighbor is neither present in Configured or
Registered list nor in BSSID white list, then cWLC detects that neighbor as Rogue AP
and updates the Rogue AP list.

cWLC posts an alarm when the first rogue AP detected. This alarm is cleared only
when not even single rogue AP is available in the network. cWLC post an icon to
represent the availability of Rogue APs in the network.

Figure 6.1 Presence of Rogue AP in the network

cWLC provides an option to move the APs from “Rogue AP List” to “BSSID White
List” which blocks the BSSID of the Rogue AP.

Department of ECE, JSS S&TU, Mysuru Page 55

 Rogue AP Detection

CHAPTER 7

CONCLUSION

Rogue AP poses serious security threat to a wireless enterprise network as it provides a

wireless backdoor into the enterprise network for outsiders, bypassing all wired security
measures such as firewalls and network access control (NAC). A rogue AP may also
deliberately flood Wi-Fi network with management messages that brings down capacity
and performance of Wi-Fi network. The Nokia’s solution for the Rogue AP detection
allows operator to configure the Access Points using Rogue AP feature. This feature
consists of dedicated detection, on demand detection and no detection mode. Wi-Fi AP
is configured using any one of the mode. The purpose of the project is to test the Rogue
AP feature using different automation scenarios. By executing these scenarios Rogue AP
is detected. Then that Rogue AP is moved to BSSID White list.

7.1 Advantages

Time constraints often make it impossible to manually test any feature thoroughly for
different scenarios. Manual Testing of all workflows, all fields and all negative scenarios
is time consuming. It is difficult to test for multilingual sites manually. Automation does not
require Human intervention. It can be executed overnight. Manual Testing can become
boring and hence error-prone. The keywords which are written for automation testcases
are reusable. No need of new keywords all the time, even if some update in the feature.

Automation helps us to find bugs in the early stages of executing which reduces the
working hours to fix these problems. Automated testing is more reliable and way quicker
when running boring repetitive standardized tests which cannot be skipped, ever, but may
cause errors when manually tested.

Sufficient test coverage typically demands significant effort. Hundreds of test cases
may be needed to exercise all use scenarios, validate boundary and edge cases, and
ensure that an application is compatible across browsers and devices. Data-driven

Department of ECE, JSS S&TU, Mysuru Page 56

 Rogue AP Detection

automated testing separates test procedures from test data, allowing to cover more
scenarios with a minimum amount of effort.

7.2 Limitations

Automation tool works on JavaScript to enable browsers to manipulate the UI of an

application. So to work upon any element present in a webpage, scripts needs to identify
the element from the properties defined by developers. In case there are html tags created
that doesn’t have unique properties to identify any specific element, automation scripts
will fail to perform action on it.

There are few test cases for which one time manual test effort is enough to say
whether the result will pass or fail. For example: – Selecting a radio button, once it’s
selected there is no way it can get un-selected unless page is refreshed. Such test cases
have minimum risk of failure and that doesn’t justify automating. The biggest
disadvantage is the time required to decide which of the reasons actually applies to the
failed testcase whether it is an actual bug or it’s a product issue.

Department of ECE, JSS S&TU, Mysuru Page 57

 Rogue AP Detection

REFERENCES

[1] Jim Geier “Identifying Rogue Access Points” January 06, 2003.

[2] Ajay Kumar Gupta, Vaibhav Vishal “Security Risk Exposure Increases due to Windows
7 Virtual Wi-Fi Capability”.
[3] Torvalds, Linus “Re: Kernel SCM saga” April 07, 2005

[4] "Robot Framework Homepage". Robotframework.org. Retrieved March 23, 2012.

[5] Kawaguchi, Kohsuke; et al. "Use Hudson: License". Archived from the original on
February 7, 2009. Retrieved January 30, 2011.

Department of ECE, JSS S&TU, Mysuru Page 58