Lucas Jeferson (Impressão)

UNIVERSIDADE ESTADUAL DO MARANHO UEMA
CURSO DE ENGENHARIA DA COMPUTAO
LUCAS JEFERSON DA COSTA SILVA
SISTEMA DE GERENCIAMENTO DE REDES WIFI DE PEQUENO E MDIO PORTE
So Lus, MA
2015
Monografia apresentada Universidade Estadual

do Maranho como requisito parcial para ob-
teno do ttulo de Bacharel em Engenharia da
Computao, com habilitao em Telemtica e
Telecomunicaes.
Orientador: MSc. Raimundo de Carvalho Silva Neto
So Lus, MA
2015
Silva, Lucas Jeferson da Costa.
Sistema de gerenciamento de redes wi-fi de pequeno e mdio porte /
Lucas Jeferson da Costa Silva.So Lus, 2016.
80 f
Monografia (Graduao) Curso de Engenharia da Computao,

Universidade Estadual do Maranho, 2016.
Orientador: Prof. Raimundo de Carvalho da Silva Neto.
1.Wi-fi. 2.Gerenciamento. 3.RaspberryPi. 4.OpenWrt. I.Ttulo
CDU: 004.738.5.057.4
Monografia apresentada Universidade Estadual

do Maranho como requisito parcial para ob-
teno do ttulo de Bacharel em Engenharia da
Computao, com habilitao em Telemtica e
Telecomunicaes.
Trabalho aprovado. So Lus, MA, 12 de janeiro de 2015:
MSc. Raimundo de Carvalho Silva Neto

Orientador
Dr. Lcio Flvio de Albuquerque Campos

Primeiro membro
Esp. Marcelo Renato do Carmo Pereira

Filho
Segundo membro
Dedicatria
Este trabalho dedicado toda a minha famlia, que sempre me apoiou, seja com apoio finan-
ceiro, motivacional ou at mesmo atravs cobranas.
Agradecimentos
Aos meus pais, por terem sido a base de todos os meus apredizados.
Aos meus tios Ftima e Jos Raimundo, por me acolherem em sua casa e fazerem dela a minha
casa.
Aos muitos colegas que conheci nessa caminhada e que contriburam com a minha formao.
Aos meus orientadores, por toda contribuio no desenvolvimento desse trabalho.

"Uma mente necessita de livros da mesma forma que
uma espada necessita de uma pedra de amolar se
quisermos que se mantenha afiada"
(George R. R. Martin)
Resumo
Nesse trabalho foi apresentado uma proposta de um Sistema de Gerenciamento de Redes WiFi,
onde foi feita a implementao de um prottipo, utilizando web2py, OpenWrt e Raspberry Pi,
para comprovar a eficcia do sistema. O princpio de funcionamento do sistema o gerencia-
mento de algumas funcionalidades de Access Points utilizando um sistema embarcado chamado
OpenWrt atravs de uma interface web, onde o sistema esteve executando em um computador
do tamanho de um carto de crdito, o Raspberry Pi. No decorrer deste trabalho foi mostrado a
fundamentao terica, que ajuda a entender como funciona cada parte do sistema, foi mostrado
tambm a construo do prottipo do sistema, seu funcionamento, os componentes utilizados e
os testes realizados.
Palavras-chaves: WiFi, Gerenciamento, Raspberry Pi, OpenWrt.

Abstract
This work presented a proposal of a WiFi Network Management System, which carried out
the implementation of a prototype using web2py, OpenWrt and Raspberry Pi, to prove the
effectiveness of the system. The systems working principle is the management of some Access
Points features using an embedded system called OpenWrt through a WEB interface where the
system is running on a credit-card sized computer, the Raspberry Pi. In this paper was shown the
theoretical foundation, it helps to understand how each part of the system, It has also been shown
the construction of prototype system, its operation, the components used and the tests performed.
Key-words: WiFi, Management, Raspberry Pi, OpenWrt.

Lista de ilustraes
Figura 1 Camada MAC e PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figura 2 Canais em 2.4GHz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 3 Representao de um IBSS . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 4 Representao de uma BSS . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 5 Representao de uma ESS . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 6 Estados que uma estao pode assumir . . . . . . . . . . . . . . . . . . . . 32
Figura 7 Resumo do padro IEEE 802.11i . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 8 Montagem do frame WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 9 Processo de autenticao do 802.1x . . . . . . . . . . . . . . . . . . . . . . 36
Figura 10 Exemplo de estrutura de um arquivo de configurao UCI. . . . . . . . . . . 42
Figura 11 Conexo Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 12 Componentes e conexes do Raspberry Pi modelo B+ . . . . . . . . . . . . 48
Figura 13 Caminho de uma requisio HTTP . . . . . . . . . . . . . . . . . . . . . . 52
Figura 14 Estrutura do Web2py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 15 Viso frontal e traseira do TP-Link TL-WR740N. . . . . . . . . . . . . . . 56
Figura 16 Raspberry Pi modelo B+. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 17 Topologia e arquitetura da rede e de seus elementos. . . . . . . . . . . . . 57
Figura 18 Simulador online do dispositivo TL-WA701ND. . . . . . . . . . . . . . . . 58
Figura 19 Tela principal do prottipo do sistema. . . . . . . . . . . . . . . . . . . . . 59
Figura 20 Esquema de conexes entre os dispositivos da LAN. . . . . . . . . . . . . 61
Figura 21 APs cadastrados no sistema. . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 22 Resumo das configurao dos SSIDs no sistema. . . . . . . . . . . . . . . 62
Figura 23 Primeiro escaneamento das redes WiFi no local feita pelo Wifi Analyzer. . . 63
Figura 24 Resumo das configurao dos SSIDs no sistema aps as modificaes. . . . 64
Figura 25 Segundo escaneamento das redes WiFi no local feita pelo Wifi Analyzer. . . 64
Lista de tabelas
Tabela 1 Detalhes dos comandos UCI . . . . . . . . . . . . . . . . . . . . . . . . . 43

Tabela 2 Endereamento usado nos testes. . . . . . . . . . . . . . . . . . . . . . . . 61
Lista de abreviaturas e siglas
Ponto de Acesso - Access Point
Rede Local
Rede Metropolitana
Rede Local Sem Fio
Direct-Sequence Spread Spectrum
Frequency-Hopping Spread Spectrum
Institute of Electrical and Electronic Engineers
Media Access Control
Logical Link Control
Remote Authentication Dial In User Service
Basic Service Set
Distribution System
Distribution System Service
Extended Service Set
Structured Query Language
Service Set Identifier
Wired Equivalent Privacy
Wi-Fi Protected Access
Station Service
Network Access Server
Unified Configuration Interface
Infra Red
Robust Security Network Association
Secure Socket Layers

Temporal Key Integrity Protocol
Pre Shared Key
Extensible Authentication Protocol
Point to Point Protocol
Generic Token Card
Transport Layer Security
Tunneled Transport Layer Security
Protected Extensible Authentication Protocol
Challenge Handshake Authentication Protocol
Extensible Authentication Protocol over LAN
Lightweight Directory Access Protocol
Pluggable Authentication Modules
Network Information Service
Remote Authentication Dial In User Service
Counter Mode with CBC-MAC
Advanced Encryption Standart
General Public License
System on a Chip
Non-Volatile Random Access Memory
Domain Name System
Dynamic Host Configuration Protocol
Secure Shell
Network Address Translation
Transmission Control Protocol
Internet Protocol
HyperText Markup Language

File Transfer Protocol
Terminal Virtual de Rede
Graphics Processing Unit
General Purpose Input/Output
Display Serial Interface
Camera Serial Interface
Uniform Resource Locator
Application Programming Interface
Model-view-controller
Dont Repeat Yourself
Web Server Gateway Interface
eXtensible Markup Language
Rich Site Summary
JavaScript Object Notation
Integrated Development Environment
Cross Site Scripting
Open Web Application Security Project

Sumrio
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2 Hiptese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.2 Objetivos Especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2 PADRO IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 Arquitetura IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 Servios IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.1 Servios de Estao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.2 Servios de Sistema de Distribuio . . . . . . . . . . . . . . . . . . . . . . 31
2.2.3 Estados de uma estao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Autenticao em redes WLAN . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 Autenticao Aberta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.2 Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.3 WiFi Protected Access (WPA) . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.3.1 Extensible Authentication Protocol (EAP) . . . . . . . . . . . . . . . . . . 35
2.3.3.2 IEEE 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.4 Wi-Fi Protected Access (WPA) . . . . . . . . . . . . . . . . . . . . . . . . 37
3 OPENWRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1 Histrico do OpenWrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 O sistema UCI (Unified Configuration Interface) . . . . . . . . . . . . . 40
3.3 Sintaxe nos arquivos de configurao . . . . . . . . . . . . . . . . . . . . 41
3.4 Configurao por linha de comando . . . . . . . . . . . . . . . . . . . . 42
4 PROTOCOLO TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 Fundamentos do Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 RASPBERRY PI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 Componentes do Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . 47
6 FRAMEWORK WEB2PY . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.1 Mtodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Materiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2.1 TP-Link TL-WR740N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2.2 Raspberry Pi B+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3 Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.1 Instalao do OpenWrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.2 Desenvolvimento do Prottipo . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3.3 Instalao do Prottipo no Raspberry Pi . . . . . . . . . . . . . . . . . . . . 60
7.3.4 Testes Prticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8 CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.2 Dificuldades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3 Aprendizado do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.5 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Apndices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
APNDICE A Cdigo do Controller do Prottipo . . . . . . . . . . . 71
APNDICE B Cdigo do Model do Prottipo . . . . . . . . . . . . . 73
APNDICE C Cdigo do Mdulo de Comunicao do Prottipo . . . 75
APNDICE D Script de Configurao do Web2py com Apache no
Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . 77
25
1 INTRODUO
As redes sem fio esto sendo cada vez mais utilizadas na comunicao entre dispositivos
dos mais variados tipos e tamanhos e em diferentes ambientes. Por permitirem a mobilidade,
estas redes facilitam a ubiqidade do poder computacional, tornando transparente a disseminao
da informao e a cooperao dos dispositivos na realizao das mais variadas tarefas (VIEIRA,
2005).
Por esse motivo, os esforos visando aperfeioar ainda mais essa tecnologia so in-
cessantes, para que o usurio possa obter uma experincia agradvel na utilizao do servio
oferecido.
Por exigir padres de qualidade e disponibilidade mais elevados, os clientes corporativos
so os mais cobiados pelas grandes fabricantes de tecnologia de redes WiFi, onde so oferecidas
funcionalidades dentre as quais podemos destacar o gerenciamento centralizado dos APs (Access
Points), gerenciamento de usurios e mobilidade por toda a rea de cobertura da rede. Essas
funcionalidades, aliadas qualidade do hardware utilizado, acabam resultando em um produto
que atende as expectativas do meio corporativo, porm a um custo consideravelmente alto,
tornando a utilizao dessas tecnologias invivel para pequenas empresas e clientes domsticos.
Tendo em vista que a tecnologia WiFi est presente em variados dispositivos e a
necessidade que o usurio tem de estar sempre conectado (inclusive em suas horas de lazer) nos
faz enxergar que, em alguns lugares, um nico AP no mais o suficiente para atender essa
demanda, geralmente devido a arquiterura do ambiente e das limitaes da comunicao via RF
(Rdio Frequncia).
O presente trabalho pretende descrever a criao de um sistema que oferea funci-
onalidades de redes coorporativas, utilizando tecnologias open source e hardware de baixo
custo.
No decorrer do Trabalho, ffoi feito uma fundamentao terica sobre os elementos
cruciais para o desenvolvimento do prottipo, mais adiante sero mostrado as caractersticas e a
implementao do prottipo do projeto e, por fim, foi avaliado a eficcia das tcnicas utilizadas e
mostrado a concluso que foi possvel chegar com o desenvolvimento do projeto.
1.1 Problema
Como gerenciar mltiplos Access Points em uma rede sem a necessidade de se fazer
processos repetitivos?
1.2 Hiptese
O desenvolvimento de um sistema de gerenciamento para uma rede WiFi, capaz de,

com apenas um processo de configurao, configurar todos os access points da rede de forma
26 Captulo 1. INTRODUO
automatizada.
1.3 Objetivos
1.3.1 Objetivo Geral
Desenvolver um sistema de gerenciamento centralizado para redes WiFi de pequeno e

mdio porte, utilizando hardware de baixo custo e software livre, buscando criar uma soluo
que atenda pequenas empresas e ambientes domsticos.
1.3.2 Objetivos Especficos
Oferecer autenticao nica ao usurio na rede;
Desenvolver uma interface de gerncia ao administrador da rede, baseado em web;
Implementar um prottipo que oferea a possibilidade de cadastrar os dispositivos WiFi e

gerenciar as configuraes de rede WiFi, demonstrando a eficcia das tcnicas utilizadas.
1.4 Justificativa
O que motivou a desenvolver esse trabalho foi o alto custo para se desenvolver redes
WiFi com gerenciamento centralizado de todos os dispositivos da rede wireless.
A maioria das solues oferecidas pelo mercado so focadas a atender clientes empresa-
riais de grande porte, tornando o acesso a essas tecnologias, por parte de clientes domsticos e
pequenas empresas, pouco vivel.
27
2 PADRO IEEE 802.11
A comunicao sem fios uma das tecnologias que mais tem crescido nos ltimos anos.
A demanda pela conexo de dispositivos sem a utilizao de cabos aumentou vertiginosamente
em todo o mundo. Atualmente, as LANs sem fios so encontradas em campus universitrios,
escritrios de empresas e em reas pblicas (FOROUZAN, 2006).
Cada vez mais organizaes descobrem que as LANs sem fio so um comple-
mento indispensvel para as LANs com fio tradicionais, para atender necessida-
des de mobilidade, relocao, interligao, rede provisria e cobertura de locais
difceis de ligar (STALLINGS, 2005).
A equipe de trabalho do IEEE divulgou em 1997 as especificaes do protocolo defi-

nidas pelos padres IEEE 802.11, que fazem parte da famlia de padres 802, responsvel por
especificar padronizaes para redes LAN e MAN. No padro 802.11 feito o detalhamento da
camada fsica (PHY) e da subcamada MAC (camada de enlace no padro IEEE 802), como pode
ser vista na Figura 1.
Figura 1 Camada MAC e PHY
Fonte: Adaptado de GARCIA (2003).
O padro IEEE 802.11 prev que a camada fsica poder usar at trs tipos de mtodos
de transmisso: FHSS, DSSS1 e o Infra Vermelho (IR). Os padres FHSS e DSSS operam na
frequncia de 2.4 GHz, sendo que a maioria das aplicaes utilizam a tcnica de DSSS (VINCI;
FERREIRA, 2007).
Segundo CARROLL (2009), a faixa de frequncia de 2.4GHz , provavelmente, a mais
utilizada em WLANs. Sendo utilizada nos padres IEEE 802.11, 802.11b, 802.11g e 802.11n. A
faixa de frequncia de 2.4 GHz vai de 2.400 GHz a 2.4835 GHz ou 2.495 GHz (dependendo
1
Frequency-Hopping Spread Spectrum e Direct-Sequence Spread Spectrum: so tcnicas de codificao para
transmisso digital de sinais
28 Captulo 2. PADRO IEEE 802.11
da regulamentao pas). Nos Estados Unidos e no Brasil utilizado a faixa de 2.400 GHz a
2.4835 GHz, dispostos em 11 canais de largura de banda de 22 MHz, como pode ser visto na
Figura 2. Nesse cenrio, esto disponveis 11 canais, onde alguns deles se sobrepem, podendo
causar interferncia entre si. Por essa razo, os canais 1, 6 e 11 so os mais utilizados, por eles
no estarem sobrepostos.
Figura 2 Canais em 2.4GHz
Fonte: (CARROLL, 2009).
A faixa de 5 GHz utilizada pelos padres IEEE 802.11a, 802.11n e 802.11ac. Essa
faixa de frequncia foi utilizada inicialmente no padro 802.11a, onde as taxas de transmisso
variam de 6 Mbps a 54 Mbps. Algum tempo depois, a faixa de 5 GHz foi utilizada nos padres
802.11n, que poderia usar tanto a faixa de 2.4 GHz quanto a de 5 GHz, e no padro 802.11ac,
que utiliza exclusivamente essa frequncia de transmisso.
2.1 Arquitetura IEEE 802.11
A arquitetura definida para este padro celular, onde cada clula, denominada de Basic
Service Set (BSS), controlada por um Access Point (VINCI; FERREIRA, 2007).
Existem trs tipos de topologia nas quais possvel formar uma rede WLAN, o tipo de
topologia classificado de acordo com a forma que os dispositivos se comunicam. Os trs tipos
de topologias so IBSS (tambm conhecido como AD-HOC), BSS (o mais utilizado nas nossas
residncias) e o ESS (mais utilizadas em ambientes mais extensos ou com muita interferncia).
A seguir temos uma descrio mais detalhada de cada uma dessas topologias:
IBSS (Independent Basic Service Sets): trata-se de um grupo de estaes que se comuni-
cam de forma direta entre si, sem a necessidade de um AP para controlar o acesso, como
pode ser visto na Figura 3. Esse tipo de topologia tambm conhecida como AD-HOC.
2.1. Arquitetura IEEE 802.11 29
Figura 3 Representao de um IBSS
Fonte: do autor, 2015.
BSS (Basic Service Set): um grupo de estaes mveis que se comunicam em uma
clula, tendo o AP como um ponto de conexo comum, como pode ser visto na Figura 4.
Esse AP deve estar conectado rede de distribuio por meio de uma rede cabeada ou at
mesmo por conexes sem fios.
Figura 4 Representao de uma BSS
ESS (Extended Service Sets): nessa topologia, temos duas ou mais estruturas de BSS
conectadas atravs de uma rede de distribuio (uma infraestrutura de rede que pode ser
cabeada, sem fios ou fibra ptica), como pode ser visto na Figura 5. Dependendo de como
os APs esto dispostos no ambiente, possvel que as estaes possam passar da rea de
cobertura de uma BSS para a rea de cobertura de outra de forma transparente, processo
esse denominado de roaming.
Figura 5 Representao de uma ESS
2.2 Servios IEEE 802.11
O padro IEEE 802.11 especifica nove servios diferentes, divididos em duas categorias:
Servios de Estao (SS - Station Services) e os servios de sistema de distribuio (DSS - Dis-
tribution System Service), ambos os servios utilizados pela camada MAC (VINCI; FERREIRA,
2007).
2.2.1 Servios de Estao
Os servios de estao devem ser implementados em todas as estaes que seguem

o padro IEEE 802.11. Como h casos em que os APs tambm podem ser estaes, se faz
necessrio a implementao desse servio nos mesmos (VINCI; FERREIRA, 2007).
Nas redes cabeadas, a segurana relativamente garantida devido ao meio de transmisso
confinado (cabos) e pela segmentao do domnio de coliso oferecido pelos switches. Essa
segurana no pode ser garantida de forma to natural nas redes WLAN, por esse motivo, os
seguintes servios so necessrios:
Autenticao: Usada para estabelecer a identidade das estaes, de uma para outra.
Em uma rede LAN, geralmente se considera que o acesso a uma conexo fsica significa
autorizao para se conectar LAN. Essa no uma suposio vlida para uma WLAN, na
qual a conectividade obtida simplesmente com uma antena corretamente sintonizada. O
servio de autenticao usado pelas estaes para estabelecer sua identidade em estaes
com as quais elas iro se comunicar. O padro IEEE 802.11 no exige qualquer esquema
de autenticao especfico, que pode variar de um handshaking a esquemas de criptografia
de chave pblica (STALLINGS, 2005).
Desautenticao: Uma notificao por parte de uma estao ou AP de que uma associa-
o existente ser finalizada. Assim como necessrio a autenticao para que a estao
tenha acesso efetivo rede, necessrio que a estao emita uma notificao quando
2.2. Servios IEEE 802.11 31
for deixar a rea da BSS ou desligar. Entretanto, o recurso de gerenciamento do MAC

tem a funo de se proteger contra estaes que desaparecem sem enviar a notificao de
desautenticao (STALLINGS, 2005).
Privacidade: Com o objetivo de impedir que as trocas de mensagens entre estao e AP

possam ser lidos por outros dispositivos alm do destinatrio pretendido. Para garantir a
privacidade na troca de mensagens, o padro sugere o uso de criptografia (STALLINGS,
2005).
Delivery: Garantia de entrega das informaes entre os dispositivos, atravs da identifica-

o por endereo MAC (VINCI; FERREIRA, 2007).
2.2.2 Servios de Sistema de Distribuio
Em redes de estrutura do tipo ESS, a responsabilidade de encontrar os destinatrio dos

dados que trafegam pela rede de responsabilidade do sistema de distribuio, mas que o envio
e recebimento de dados pelos dispositivos da rede wireless ocorra necessrio que se os APs
ligados ao sistema de distribuio implementem os servios de que trabalham nas subcamadas
LCC e MAC. Estes servios so:
Associao: Esse servio o responsvel por permitir que uma estao envie e receba
dados pela rede atravs da associao um AP, onde o processo de associao sempre
iniciado pela estao. Ainda que uma estao possa estar autenticada em mais de um AP,
ele pode estar associado somente a um AP, que o mais importante para o sistema de
distribuio quando este necessita descobrir em qual AP a estao est associada.
Desassociao: Este servio serve para informar ao AP quando uma estao no continu-
ar associada ele, podendo ser efetuado tanto pela estao como pelo AP. Esse servio
importante para que no ocorra o envio de frames de forma equivocada para um AP que
no possui mais a estao destinatria associada a ele.
Reassociao: Geralmente por questes de economia de energia, uma estao pode no

ficar continuamente associada a um AP, onde se faz necessrio a existncia do servio de
reassociao, que responsvel por informar ao sistema de distribuio o atual AP ao qual
a estao est associada, sendo invocado sempre pela estao quando esta se reassocia
um AP.
Integrao: O servio de integrao tem a funo de conectar as redes do padro IEEE

802.11 outros tipos de redes LAN, podendo ser uma ou mais LANs ou outra WLAN. Este
servio consiste em traduzir frames IEEE 802.11 para frames da rede destino e vice-versa
(OHARA; PETRICK, 2005).
Distribuio: determina como ser a entrega dos frames. Esse servio determina que o
sistema de distribuio ficar responsvel pela entrega dos frames aos seus respectivos
destinatrios, mesmo que a estao destino esteja associada ao mesmo AP em que a estao
de origem est associada.
2.2.3 Estados de uma estao
O padro IEEE 802.11 define que os dispositivos que sigam esse padro devem imple-
mentar os servios anteriormente citados. Com isso, em algum momento do seu funcionamento,
toda estao poder assumir um dos trs estados que podem ser visualizados na Figura 6, onde
possvel ver melhor a funo de alguns dos servios que j foram mostrados.
Figura 6 Estados que uma estao pode assumir
Fonte: (VINCI; FERREIRA, 2007).
Estado 1: Quando a estao encontra-se nesse estado, ela no est associada e nem
autenticada a nenhum AP. O prximo passo seria realizar autenticao em algum AP
disponvel no local.
Estado 2: Nesse estado, a estao j realizou a autenticao com sucesso, porm ainda
no est associada ao AP. Quando est nesse estado, a estao tem a opo de realizar a
associao para realizar a transmisso dos dados ou realizar a desautenticao para que ele
volte para o Estado 1.
Estado 3: nesse estado que a estao est apta a transmitir dados aos outros dispositivos
da rede, onde a estao encontra-se autenticada e associada um AP. Para sair desse estado,
a estao pode ser desautenticada para voltar ao Estado 1 ou ser desassociado para voltar
ao Estado 2, em ambos os casos o servio pode ser solicitado tanto pela estao quanto
pelo AP.
2.3. Autenticao em redes WLAN 33
2.3 Autenticao em redes WLAN
Inicialmente o padro IEEE 802.11 no especificava nenhum mtodo de que garantisse

segurana no acesso e transmisso dos dados, onde o controle de acesso era feito por endereo
MAC em dispositivos de alguns fabricantes. Como fazer o controle de acesso por endereo MAC
era um muito trabalhoso e de difcil manuteno, foi introduzido no padro IEEE 802.11b o
mtodo de segurana WEP (Wired Equivalent Privacy), que sofria de vrias falhas. Com esses
problemas sofridos pelo WEP, o IEEE resolveu desenvolver o RSNA (Robust Security Network
Association), especificado pelo padro 802.11i, que servia como um aperfeioamento para prover
uma forma mais robusta de segurana no controle de acesso. O RSNA foi idealizado para prover
autenticao, gerao de chaves criptografadas, integridade e confidencialidade.
O padro 802.11i demorou um tempo para ser totalmente especificado e, enquanto isso
no acontecia, a Wi-Fi Alliance criou uma soluo temporria para substituir o WEP, foi a que
nasceu o WPA (WiFi Protected Access). O WPA j implementava parte das especificaes do
padro 802.11i, com os algoritmos de segurana que foram denominados Pre-RSNA. Quando
o padro 802.11i foi finalizado, a Wi-Fi Alliance lanou o mtodo de segurana WPA2, que
conhecido at hoje pela a sua eficcia e amplamente utilizado nos diversos padres IEEE 802.11
desenvolvidos at ento.
Na Figura 7 temos um resumo de como o padro IEEE 802.11i est organizado no seu
objetivo de prover autenticao, gerao de chaves criptografadas, integridade e confidenciali-
dade.
Figura 7 Resumo do padro IEEE 802.11i
Fonte: (HOLT; HUANG, 2010).
2.3.1 Autenticao Aberta
Conhecida como open system, este mtodo de autenticao no possui nenhuma forma
de segurana no controle de acesso das estaes rede. Para fazer a autenticao, considerando
dois dispositivos A e B, o dispositivo A afirma sua identidade para o dispositivo B atravs de uma
requisio de autenticao. O dispositivo B envia para A o resultado da requisio, que pode ser
"success" ou "failure". O dispositivos estaro mutuamente autenticados caso o resultado seja
"sucess" (HOLT; HUANG, 2010).
Como no foi definido originalmente nenhum tipo de segurana para controlar a auten-
ticao das estaes, foi implementado por alguns fabricantes uma lista de autorizao acesso
baseada em endereo MAC, onde somente os dispositivos com o endereo MAC contido na lista
recebiam a resposta "sucess" pela requisies de autenticao feitas ao AP. Essa implementao
no est contida na especificao original do padro IEEE 802.11.
2.3.2 Wired Equivalent Privacy (WEP)
Com o intuito original de prover o mesmo nvel de confidencialidade que era extinta
nas redes cabeadas tradicionais, o mtodo de autenticao WEP foi inicialmente especificado no
padro IEEE 802.11b com o objetivo de fornecer confidencialidade aos dados por meio de um
algoritmo criptogrfico de chave secreta, ser eficiente a ponto de ser capaz de ser processado
rapidamente por software e ser exportvel a ponto de poder ser utilizado em outros pases alm
das fronteiras americanas (MORAES, 2010).
Segundo MORAES (2010), o WEP trabalha com o algoritmo RC42 da RSA que uma
cifra baseada em stream de fluxo, onde um algoritmo simtrico uma nica chave para criptografar
e descriptografar os dados.
Figura 8 Montagem do frame WEP
Fonte: (HOLT; HUANG, 2010).
2
um algoritmo simtrico de criptografia de fluxo mais usado no software e utilizado nos protocolos mais
conhecidos, como Secure Socket Layers (SSL)
Na Figura 8 possvel ver como montado o frame WEP, onde a chave utilizada uma
chave de 40 bits que concatenada com uma vetor de inicializao de 24 bits para formar a
chamada seed ou semente em traduo livre. Toda vez que um texto claro vai ser enviado, ele
submetido uma operao XOR com uma stream de dados pseudorrandmicos gerado pela
semente, onde o resultado dessa operao novamente concatenado com o vetor de inicializao
e transmitido. O processo de decriptao inverso ao que acabou de ser descrito.
Por conter algumas vulnerabilidades que comprometiam a segurana das informaes
que trafegam na rede, o WEP foi definido pela Universidade de Berkeley na Califrnia e pela
Universidade de Maryland como inadequado para prover privacidade em redes sem fio em
camada de enlace.
2.3.3 WiFi Protected Access (WPA)
Criado em 2003 pela Wi-Fi Alliance, o WPA tinha como objetivo encontrar e tentar
corrigir as falhas do WEP, garantindo uma forma temporria de melhorar a segurana das
WLANs enquanto o padro IEEE 802.11i era finalizado. Para isso, foi implementada uma
melhor forma de gerenciamento de chaves utilizando cifra RC4 atravs do TKIP (Temporal Key
Integrity Protocol).
O funcionamento do TKIP baseado na criao de uma chave temporal de 128 bits,
que compartilhada entre todos as estaes e o AP. Essa chave temporal combinada com o
endereo MAC da estao para ajudar compor o vetor de inicializao, que ser utilizado para
a encriptao dos dados. Para melhorar a segurana, ocorre uma distribuio dinmica dessas
chaves temporais, onde as chaves temporais so trocadas a cada 10.000 pacotes.
O WPA j seguia algumas especificaes de uma verso no terminada do padro
802.11i, que definia que o WPA deveria trabalhar de duas formas:
WPA Personal: utiliza o mtodo PSK (Pre Shared Key), que uma chave pr-compartilhada,
previamente instalada no AP e nas estaes para que se faa a autenticao das estaes,
seguido do processo de troca de chaves atravs do TKIP.
WPA Enterprise: esse mtodo de autenticao utiliza o padro IEEE 802.1x, que um
protocolo de autenticao, baseado em porta, que utiliza o EAP (Extensible Authentication
Protocol) (MORAES, 2010).
2.3.3.1 Extensible Authentication Protocol (EAP)
Especificado pela RFC 3748, o EAP foi muito utilizado nos anos de 1990 para prover
uma forma segura de autenticao para o protocolo PPP(Point-to-Point Protocol). Apesar de
ser mais utilizado no PPP, o EAP um simples encapsulamento que pode funcionar sobre
qualquer protocolo da camada de enlace, podendo utilizar uma ampla variedade de mtodos de
autenticao, das quais podemos citar:
MD5 Challenge: funciona como um handshake aplicado ao EAP;
GTC: utiliza cartes com cdigos token para prover autenticao;
TLS: utilizao de certificados, tanto do lado do servidor como do lado do cliente, para
prover autenticao mtua;
TTLS: utilizao de certificados para autenticao apenas do lado do servidor, somado

a utilizao de tunelamento para garantir um canal seguro para o trfego de dados. Esse
mtodo pode ser utilizado em conjunto com outros mtodos de autenticao mais fracos;
PEAP: similar ao TTLS, podendo, tambm, ser utilizado em conjunto com outros mtodos
de autenticao mais fracos;
EAP-SIM: autenticao utilizada em telefonia mvel para garantir a identidade do assi-

nante;
MS-CHAP-V2: autenticao por senha criptografada desenvolvida pela Microsoft e

amplamente utilizada em suas tecnologias.
No mbito de redes sem fio, o EAP utilizado para prover a segurana na autenticao
especificada pelo padro 802.1x, onde o EAP encapsulado em camada 2 e fica conhecido como
EAPOL (EAP over LAN).
2.3.3.2 IEEE 802.1x
Segundo HOLT e HUANG (2010), o 802.1x um protocolo de camada 2 que suporta

controle de acesso rede baseado em porta..
Figura 9 Processo de autenticao do 802.1x
Fonte: (MORAES, 2010).

O processo de autenticao do 802.1x, descrito na Figura 9, mostra a estao do cliente

fazendo a requisio para acessar os recursos da rede e o AP fazendo o papel de intermediador
da autenticao, responsvel por fazer o controle do acesso rede e enviar as credenciais ao
servidor RADIUS. O servidor RADIUS, por sua vez, far a validao dessas credenciais e, de
acordo com a sua base de dados, retornar o resultado ao AP. De acordo com a resposta fornecida
pelo servidor RADIUS, o AP far ou no a liberao do acesso aos recursos da rede para a
estao cliente.
O processo de comunicao entre a estao cliente e o AP feita atravs do protocolo
802.1x baseado no EAP, j a comunicao entre o AP e o servidor de autenticao feita atravs
do protocolo RADIUS.
Uma das vantegens de utilizar o RADIUS que ele oferece suporte a uma variedade
de diferentes bases de usurios. Alm de utilizar base de dados locais, o RADIUS server pode
ser usado como um gateway para diretrios LDAP, faz autenticaes UNIX como NIS e PAM,
domnios Kerberos, Active Directory da Microsoft, ou at mesmo em outros servidores RADIUS
(GAST, 2005).
2.3.4 Wi-Fi Protected Access (WPA)
Baseado na especificao final do padro IEEE 802.11i, o WPA2 foi lanado pela Wi-Fi
Alliance em 2004, fornecendo usurios domsticos e empresas um maior grau de segurana,
mantendo a compatibilidade com o WPA, ou seja, implementa o algoritmo TKIP e a autenticao
por 802.1x.
A novidade que o WPA2 passou a utilizar o algoritmo CCMP (Counter Mode with
CBC-MAC), que considerado pelo governo dos Estados Unidos como um dos mais seguros
existentes por ser baseado na especificao final do AES (Advanced Encryption Standart).
Assim como WPA, o WPA2 oferece dois mtodos de autenticao, um baseado em uma
chave pr-compartilhada e outro baseado em autenticao 802.1x.
39
3 OPENWRT
O OpenWrt uma distribuio do GNU/Linux, altamente customizvel, di-

recionada a sistemas embarcados (frequentemente roteadores wireless). Ao
contrrio de muitas outras distribuies para roteadores, o OpenWrt um sis-
tema operacional facilmente modificvel e repleto de recursos. (OPENWRT,
2015).
Sua funo substituir os firmwares dos roteadores WiFi vindos de fbrica, dando a eles
maior quantidade de funcionalidades e fazendo com o software que executa nesses dispositivo
deixe de ser simplesmente uma ferramenta pronta e esttica, atribuindo mais flexibilidade atravs
da possibilidade de se incluir e excluir novos pacotes de funcionalidades. Isso significa, na
prtica, que possvel ter tudo o que se precisa, sem desperdcios, com base e um kernel Linux
que mais recente do que a maioria das outras distribuies.
Os roteadores de linhas domsticas da grande maioria dos fabricantes oferecem funciona-
lidades limitadas. Essa limitaes so feitas pelo firmware padro de fbrica, que disponibilizam
apenas alguma funes ao usurio, sem oferecer o mximo que os hardwares desses dispositivos
podem oferecer. Como exemplo de funcionalidades que geralmente no so oferecidas de fbrica
e que ficam disponveis com a instalao do OpenWrt temos:
VLAN (Virtual Local Area Networks);
Mltiplos SSIDs (podendo ser cada SSID em uma VLAN diferente);
Configurao por Telnet e SSH (Secure Shell);
Servidor e cliente VPN;
Incluso e excluso de novas funcionalidades e funcionalidades j existentes;
3.1 Histrico do OpenWrt
O projeto OpenWrt foi iniciado em janeiro de 2004. As primeiras verses OpenWRT

foram baseadas em cdigos fontes do Linksys WRT54G para GPL e um BuildRoot1 do projeto
uClibc2 . Esta verso era conhecida como OpenWrt "stable release" (verso estvel) e foi
amplamente colocada em uso (OPENWRT, 2015).
No incio de 2005, alguns novos desenvolvedores se associaram equipe. Depois de
alguns meses de desenvolvimento, a equipe decidiu publicar as primeiras verses "experimen-
tal" (experimentais) de OpenWrt. As verses experimentais usam um sistema de construo
fortemente personalizado com base no BuildRoot2 do projeto uClibc. OpenWrt usa fontes do
1
Ferramenta simples, eficiente e de fcil utilizao para a compilao de sistemas embarcados.
2
Um Sistema Linux de cdigo aberto criado em 1998 e completamente voltado a Sistemas Embarcados, com
kernel de apenas 900Kb e suporte para vrios protocolos de rede.
40 Captulo 3. OPENWRT
kernel oficiais GNU/Linux e s adiciona patches para o SoC e drivers para interfaces de rede
(OPENWRT, 2015).
De 2007 at os dias atuais foram lanadas vrias verses do OpenWrt, onde as verses
estveis lanadas so:
White Russian v0.9 (2007):Lanada em 2007, essa foi a primeira verso do OpenWrt
estvel que pde ser utilizada pelo pblico. O nome que o batizou veio de um famoso
coquetel, onde as verses subsequentes tambm so batizadas com nomes de coquetis;
Kamikaze v7.09 - v8.09.2 (2006-2010): Nessa verso foram feitas melhorias substanciais
para o ambiente de compilao sobre um fork do BuildRoot-NG em agosto de 2006, onde
estes foram implementados no ramo principal de desenvolvimento do Kamikaze e tornou-
se o primeiro lanamento oficial da verso estvel do Kamikaze. As verses 7 e 8 do
OpenWrt so da corrente Kamikaze e lanados durante o perodo de 2007 a 2008;
Backfire v10.03 - v10.03.1 (2010-2011): A primeira verso do OpenWrt Blackfire 10.03

foi lanado em 2010 e sua verso de manuteno (10.03.1) ficou disponvel no fim de
2011;
Attitude Adjustment v12.03 (2013): foi lanada em abril de 2013, onde foram adiciona-
das importantes atualizaes de segurana e, por esse motivo, recomendado que essa
verso seja utilizada em dispositivos com 4MB de memria flash ou mais;
Barrier Breaker v14.07 (2014): verso lanada em julho de 2014;
Chaos Calmer v14.07 (2014): atual verso do OpenWrt, que usa o kernel 3.18 LTS
como base. Essa verso foi lanada em setembro de 2015.
3.2 O sistema UCI (Unified Configuration Interface)
At a verso White Russian as configuraes eram baseadas em NVRAM (Non-Volatile

RAM), onde a NVRAM uma memria no voltil (que persiste mesmo sem alimentao
eltrica) responsvel por guardar as configuraes de inicializao do sistema. O UCI veio como
substituto da NVRAM, oferecendo muito mais do um simples mtodo de armazenar os dados de
forma persistente, ele veio para oferecer uma forma de configurao fcil e simples, tornando a
configurao dos dispositivos menos complicada.
UCI pode ser visto como uma interface de configurao principal do OpenWrt para
as configuraes mais importantes do sistema. Normalmente, essas so as definies que
so cruciais para o funcionamento do dispositivo, tais como so normalmente encontrados na
interface web de roteadores e dispositivos embarcados. Exemplos disso, so o de configurao
de interfaces de rede, as configuraes de rede sem fio, funcionalidade de log e de configurao
de acesso remoto (OPENWRT, 2015).
3.3. Sintaxe nos arquivos de configurao 41
Por ser um sistema baseado em Linux, o OpenWrt segue a mesma estrutura de arquivos
de configurao, alm de aceitar a instalao de programa de terceiros que, por sua vez, tem seus
prprios arquivos de configurao espalhados pelos diretrios do sistema, onde cada arquivo de
configurao de cada programa pode seguir uma sintaxe particular.
Para facilitar a configurao de alguns programas de terceiros, foi feita a compatibilidade
desse programas com o UCI, dessa maneira voc no tem que se preocupar com qualquer um
dos arquivos de configurao deles, basta modificar os arquivos de configurao da UCI, que
seguem uma sintaxe padro. Claro, a maioria dos softwares utilizados no tero sido preparados
para a configurao via UCI, o que pode ser algo bom, porque muitas vezes necessrio utilizar
o poder da prpria interface de configurao de um aplicativo, planejado pelos desenvolvedores.
Portanto, apenas alguns programas selecionados pelos mantenedores dos pacotes OpenWRT
foram beneficiados com da disponibilidade de uma configurao centralizada feita via UCI. A
seguir, temos alguns dos arquivos de configurao com suporte ao UCI:
/etc/config/dhcp: configuraes de DNS e DHCP;
/etc/config/dropbear: configuraes do servidor SSH;
/etc/config/firewall: configuraes firewall, NAT, filtragem de pacotes e redirecionamento

de portas;
/etc/config/network: configuraes de switch, interfaces e rotas;
/etc/config/wireless: configuraes de rede WiFi;
/etc/config/qos: configuraes de QoS (Quality Of Service);
/etc/config/samba: configuraes do Samba (simulador de gerenciador de arquivos e

impresso da Microsoft).
3.3 Sintaxe nos arquivos de configurao
Os arquivos de configurao da UCI seguem uma estrutura simples e de fcil enten-

dimento, onde essa estrutura composta, basicamente, por um ou mais blocos de instrues
de configuraes, que por usa vez so formados por uma ou mais declaraes de opes e a
definio de seus valores.
Figura 10 Exemplo de estrutura de um arquivo de configurao UCI.
Fonte:(OPENWRT, 2015).
Na Figura 10, possivel ver um exemplo de como estruturado um arquivo de configu-

rao da UCI, exemplificando a inicializao do bloco de configurao indicada por:
config example teste : indica o incio de um bloco de configuraes (ou seo);
option string some value : definio de um opo do tipo string;
option boolean 1 : definio de um opo do tipo boolean, que pode receber os

valores 0, no, off, false ou disabled para representar um valor falso e 1 , yes,
on, true ou enabled para representar verdadeiro;
list : define uma lista de valores, que so considerados como sendo da mesma lista de
acordo com o tipo (que nesse exemplo definido pelo valor collection).
Na definio dos tipos e dos valores pode ser usado aspas simples ou aspas duplas, mas
o uso dessas aspas no so obrigatrias, elas so utilizadas apenas para especificar valores que
contm espaos em sua composio.
3.4 Configurao por linha de comando
At agora, foi mostrado que para alterar as configuraes era necessrio, simplesmente,
mudar os valores nos arquivos de configurao do servio que desejamos modificar. No entanto,
quando for necessrio fazer configuraes via scripts, possvel modificar qualquer configurao
UCI atravs do utilitrio de linha de comando UCI, que pode ser utilizado pelos desenvolvedores
tanto para definir novas configuraes, modificar configuraes existentes e analisar as configu-
raes feitas. Essa ltima funo pode ser muito til quando o desenvolvedor precisa analisar
um arquivo de configurao UCI para tomar outra deciso, tornando o uso dos comandos awk ou
grep totalmente desnecessrios.
A estrutura base dos comandos UCI : "uci [<options>] <command> [<arguments>]"
3.4. Configurao por linha de comando 43
Na estrutura base dos comandos UCI temos as opes (options), que servem como
comandos opcionais para controlar como os resultados sero mostrados ou para especificar como
o comando ser executado. A Tabela 1 mostra os comandos UCI padres, sua utilizao e a
descrio de cada um.
Tabela 1 Detalhes dos comandos UCI

Comando Forma de usar Descrio
batch - Executar scripts de comandos
UCI.
export [<config>] Exportar arquivos de configurao
na sintaxe UCI.
import [<config>] Importar arquivos de configurao
na sintaxe UCI.
changes [<config>] Listar as alteraes feitas, antes
de dar o commit.
commit [<config>] Escreve os comandos nos
arquivos de configurao.
add <config> <section-type> Adicionar uma seo ao arquivo
de configurao.
add_list <config>.<section>.<option>=<string> Adicionar uma string uma lista
de j existente.
del_list <config>.<section>.<option>=<string> Remover uma string de uma lista
j existente.
show [<config>[.<section>[.<option>]]] Mostrar uma opo, seo ou
configurao em notao
comprimida.
get <config>.<section>[.<option>] Buscar um valor de opo, seo
ou configurao.
set <config>.<section>[.<option>]=<value> Atribuir um valor uma opo,
seo ou configurao.
delete <config>[.<section[.<option>]] Deletar uma determinada seo
ou opo.
rename <config>.<section>[.<option>]=<name> Renomear uma determinada seo
ou opo.
revert <config>[.<section>[.<option>]] Reverter uma determinada opo,
seo ou arquivo de configurao.
Fonte: (OPENWRT, 2015).

Por ser uma interface de linha de comando, os comandos UCI so utilizados quando
feito o acesso remoto ao dispositivo que executa o OpenWrt. Para permitir o acesso remoto aos
dispositivos, o OpenWrt oferece nativamente servidores Telnet e SSH.
45
4 PROTOCOLO TELNET
Nesse trabalho, necessrio realizar a comunicao com os dispositivos da rede, que

esto executando o OpenWRT, de forma automatizada. Para realizar esse feito, o protocolo
Telnet ser de grande importncia para a implementao do prottipo. Dessa forma, importante
conhecer o funcionamento bsico desse protocolo.
Quando as primeiras redes e a internet foram sendo desenvolvidas, um dos problemas
mais importantes que os cientistas de computao tinham para resolver era como permitir que
algum operando um computador pudesse acessar e usar outro computador como se o usurio
estivesse conectado localmente ele. O protocolo criado para atender a essa necessidade foi
chamado Telnet, onde aconteceu um esforo para que este protocolo fosse compatvel com o
modelo TCP/IP e a internet como um todo (KOZIEROK, 2005).
Mesmo que a maioria dos usurios de internet no usem diretamente o protocolo Telnet,
alguns dos seus princpios ainda esto muito presentes em muitas das tarefas dirias da maioria
dos usurios da internet, como o simples fato de carregar uma pgina HTML (HyperText Markup
Language), enviar um e-mail ou enviar um arquivo via FTP (File Transfer Protocol).
O protocolo Telnet foi desenvolvido no final dos anos de 1960, quando s existiam os
grandes computadores nas empresas, que eram acessados por terminais fsicos. Esse cenrio
era afetado por duas limitaes, a primeira era que cada usurio tinha que ter um terminal para
acessar o computador e a segunda era que seria necessrio um terminal para cada computador
que o usurio fosse acessar. Dessa forma, com a utilizao de redes locais, que utilizavam os
protocolos TCP/IP, junto com o protocolo Telnet, permitiram s empresas fazer uma economia
significativa com hardware, pois essa dupla permitia a qualquer usurio utilizar o um terminal
para estabelecer uma sesso em qualquer computador da rede.
Figura 11 Conexo Telnet

46 Captulo 4. PROTOCOLO TELNET
Uma conexo Telnet usa o protocolo TCP como base para transmisso. A figura 11
mostra os elementos de uma conexo Telnet entre dois computadores. Para efetuar um conexo
necessrio que no computador do cliente tenha instalado um servio de Telnet Client e para
que o computador destino possa responder requisio de conexo do cliente necessrio que o
o mesmo tenha um servio Telnet Server instalado.
4.1 Fundamentos do Telnet
primeira vista, pode ser surpreendente que Telnet tenha levado tanto tempo para se
desenvolvido, porque, em teoria, deveria ser um protocolo muito simples de definir: tudo o que
precisa fazer enviar as teclas digitadas e a sada do programa atravs da rede como qualquer
outro protocolo. Isso seria verdadeiro se cada terminal de computador usasse o mesmo mtodo
de comunicao, mas essas mquinas no faziam isso. O protocolo Telnet torna-se complicado
porque esse protocolo precisa permitir que um terminal de um fabricante seja capaz de falar
com um computador que pode usar uma representao de dados muito diferentes (KOZIEROK,
2005).
Para resolver esse problema, o Telnet implementa uma tecnologia que permite a garantia
de compatibilidade entre diferentes tipos de terminais, permitindo que a utilizao de recursos
especiais opcionais ao computadores que permitirem tais recursos. Para isso, o protocolo Telnet
se baseia em trs fundamentos:
Terminal Virtual de Rede (NVT): um dispositivo virtual de comunicao bidirecional.

O NVT tem uma impressora e um teclado, onde a impressora responde para os dados
de entrada e o teclado produz os dados de sada que so enviados e recebidos atravs da
conexo Telnet. As opes padro so caracteres de sete bits ASCII em um campo de oito
bits, trs caracteres de controle, cinco caracteres de controle opcionais e um jogo de sinais
de controle bsico (POSTEL; REYNOLDS, 1983);
Regras de Negociao: permite que alguns terminais anfitries ofeream opes extras,
que no so especificadas nas opes padro. A regra bsica para a inicializao do uso de
uma opo que uma das partes (ou ambas) faa uma solicitao de incio da opo, que
pode, ou no, ser aceito pelo outro lado (CCM, 2015);
Opes e Opes de Negociadas: servem para evitar situaes de bloqueio, onde pode
ser que uma das partes envie pedidos de negociao de opes a cada confirmao de outra
parte. Para isso, os pedidos devem ser emitidos apenas quando houver uma mudana de
modo, quando uma das partes receber um pedido de mudana de modo a adoo desse
modo s deve acontecer se o modo adequado no estiver ativo e um pedido s pode ser
inserido no fluxo de dados no lugar onde tem efeito.
47
5 RASPBERRY PI
O Raspberry Pi um computador desenvolvido pela Raspberry Pi Foundation, que

baseado em SoC (System on a Chip) da fabricante Broadcom. Este SoC consiste em um
processador, GPU, memria RAM e uma entrada pra carto de memria (onde ser armazenado
o sistema operacional). Tudo isso integrado em um chip de pequenas dimenses.
A ideia de um computador minsculo, de preo acessvel, para crianas veio em 2006,

quando Eben Upton, Rob Mulllins, Jack Lang and Alan Mycroft, que nessa poca no Laboratrio
de Computao da Universidade de Cambridge, preocuparam-se com a reduo, ano a ano, da
procura de estudantes por aprender Cincia da Computao e a reduo do nvel das habilidades
dos que j estudavam (FOUNDATION, 2015).
Aps vrios projetos e prottipos, o projeto do primeiro Raspberry Pi s foi se tornar

mais vivel em 2008, com o surgimento dos processadores desenvolvidos para smartphones,
que ofereciam potncia e excelentes recursos multimdia aliados a preos acessveis. Trs anos
depois , o Raspberry Pi Modelo B entrou em processo de produo em massa atravs de acordos
de fabricao licenciada com a element 14/Premier Farnell e RS Eletronics, onde foram vendidos
mais de dois milhes de unidades em dois anos (FOUNDATION, 2015).
O sistema operacional oficial do Raspberry Pi o Raspbian, uma distribuio Linux

baseada no Debian. Apesar de o Raspbian ser o sistema operacional oficial, existem diversos
outros sistemas compatveis, como uma verso do Ubuntu e at mesmo uma verso do OpenWrt.
Apesar de ter sido idealizado para incentivar o aprendizado da programao para

crianas, o Raspberry Pi acabou sendo muito bem visto pelos olhos dos adultos, devido a sua
grande versatilidade, tamanho reduzido e preo baixo. Dessa forma, ele est sendo muito
utilizado em projetos de embarcados em diversas reas do conhecimento.
5.1 Componentes do Raspberry Pi
Para construir o prottipo do projeto, foi utilizado o Raspberry Pi modelo B+. Podemos
ver, destacados na Figura 12, os componentes mais relevantes para a formao da estrutura deste
pequeno computador:
48 Captulo 5. RASPBERRY PI
Figura 12 Componentes e conexes do Raspberry Pi modelo B+
Fonte:(ELEMENT14, 2015).
Broadcom BMC2835 700MHz SoC ARM 11: esse o SoC, onde temos o CPU de
700 MHz, GPU e memria RAM de 512 MB. Alm disso, ele responsvel por gerenciar
perifricos como o GPIO (General Purpose Input/Output).
Portas USB 2.0: Esse modelo conta com 4 portas USB disponveis para conectar perifri-
cos compatveis com o padro USB.
Porta Ethernet 100/10 mbps: nico meio de conexo de rede disponvel por padro
em todos os modelos lanados at o momento.
GPIO 40 pinos: Consiste em duas filas de pinos, onde a maior parte desses pinos so
de propsitos gerais de entrada/sada. Ele pode ser usado para conectar o Raspberry Pi
outros dispositivos eletrnicos (SCHMIDT, 2014).
5.1. Componentes do Raspberry Pi 49
Conector DSI: interface DSI (Display Serial Interface), que pode ser utilizado para
conectar uma tela compatvel com esse tipo de conexo.
Porta HDMI: conexo para vdeo e udio digital de alta qualidade que pode ser conectado
a TVs ou monitores.
Conector CSI: interface CSI (Camera Serial Interface), que pode ser utilizado para
conectar uma cmera compatvel com esse tipo de conexo.
Audio I/O: conexo para prover entrada e sada de udio.
Power Connector: umas das entradas para fonte de energia, que trata-se de uma porta
mini USB. Alm dessa entrada, o Raspberry Pi pode ser energizado por um par de pinos
GPIO, que so especificamente para essa funcionalidade.
Micro SD Connector: essa conexo utilizada para o encaixe do carto micro SD, que
onde o sistema operacional ser armazenado.
51
6 FRAMEWORK WEB2PY
Desenvolvido inicialmente como uma ferramenta de ensino por Massimo Di Pierro, o

Web2py um web framework livre e open source, escrito em Python e programvel em Python,
para desenvolvimento gil de aplicaes web seguras baseadas em banco de dados. O Web2py
um framework full stack, o que significa que ele contm todos os componentes que voc
precisa para desenvolver completamente aplicaes web funcionais, altamente interativas e
escalveis.
Em seu nvel mais fundamental, uma aplicao web composta de um conjunto de
funes (ou mtodos) que so executadas quando a URL correspondente visitada. A sada do
programa retornada para o visitante e transmitido pelo navegador. O objetivo dos frameworks
web permitir que desenvolvedores criem novos aplicativos de forma gil, fcil e sem erros.
Isso feito por fornecimento de APIs1 (Application Programming Interface) e ferramentas que
reduzem e simplificam a quantidade de codificao que necessria (PIERRO, 2013).
Alm de permitir a construo de sistemas web baseado no padro MVC (Model View
Controller), o Web2py permite a implementao de mdulos pelo desenvolvedor, que podem ser
importados para qualquer parte do sistema de forma muito simples.
O DAL (Database Abstraction Layer) uma uma API escrita em Python que mapeia
objetos Python em objetos de banco de dados, tais como consultas, tabelas e registros, com o
objetivo de simplificar a utilizao de diversos bancos de dados em aplicaes Web2py.
Esse framework foi projetado para orientar um desenvolvedor web a seguir as boas
prticas da engenharia de software, tal como a utilizao do padro MVC. Web2py separa
a representao dos dados (model) da apresentao dos dados (view) e tambm da lgica de
aplicao e do fluxo de trabalho (controller). Alm disso, o Web2py fornece bibliotecas para
ajudar na criao, implementao, e teste do projeto, cada uma dessas trs partes desenvolvidas
separadamente, mas trabalhando em conjunto(PIERRO, 2013).
A linguagem Python tipicamente segue os seguintes princpios:
No se repita (DRY - Dont Repeat Youself );
Deve existir apenas uma maneira bvia de para fazer algo;
Explcito melhor do que implcito.
O Web2py procura seguir rigorosamente os dois primeiros princpios por forar o desen-
volvedor a utilizar boas prticas de engenharia de software, utilizando o amplamente difundido
padro de projeto MVC e incentivando o reaproveitamento de cdigo. O framework guia o
1
um conjunto de rotinas e padres estabelecidos por um software, que se resume a utilizar seus servios, sem
implementar nada na prpria API.
52 Captulo 6. FRAMEWORK WEB2PY
desenvolvedor facilitando as tarefas mais comuns em desenvolvimento para web(PYTHON,

2013).
Figura 13 Caminho de uma requisio HTTP
Fonte:(PIERRO, 2013).
A Figura 13 mostra um exemplo de uma requisio HTTP feita um sistema web

desenvolvido com Web2py, onde o elemento Main a aplicao WSGI2 (Web Server Gateway
Interface) e a partir dela o sistema interage entre os models, logo aps com os controllers e,
por fim, com as views, que so responsveis por dar a resposta em diversos formatos possveis
(HTML, XML, RSS, JSON, streaming, etc).
A estrutura do Web2py pode ser vista na Figura 14, que nos mostra que ele composto
pelos seguintes componentes:
Aplicao welcome: uma das aplicaes padro do Web2py, que serve como base para
o desenvolvimento de novas aplicaes;
Aplicao examples: contm exemplos interativos, documentaes sobre o Web2py e

um clone exato do site oficial do Web2py;
Aplicao admin: oferece uma completa IDE (Integrated Development Environment

Ambiente de Desenvolvimento Integrado) que utilizada para criar, projetar e gerenciar as
aplicaes Web2py;
Aplicao prprias: so aplicaes desenvolvidas pelo usurio;
Bibliotecas: o ncleo do Web2py, de onde vem todas as funcionalidades do framework;

2
uma especificao de uma interface simples e universal usada para manter a comunicao entre servidores
web e aplicaes ou frameworks que utilizam linguagem Python
53
Servidor Web: o servidor usado para receber e responder s requisies. O servidor

padro Rocket, mas pode ser substitudo pelo Apache atravs de algumas modificaes;
Interpretador Python: responsvel por executar os cdigo em Python(atualmente

distribudo com a verso 2.5 do Python).
Figura 14 Estrutura do Web2py
Fonte:(PIERRO, 2013).
No decorrer do desenvolvimento do Web2py tambm houve uma grande preocupao

em prover segurana das aplicaes Web2py. Para isso, o os desenvolvedores resolveram
consultar a OWASP (Open Web Application Security Project), que uma comunidade mundial
livre e de cdigo aberto focado em melhorar a segurana de aplicaes de software.
A OWASP listou os dez principais problemas de segurana responsveis por expor
aplicaes web ao risco de ataque de crackers. Nessa lista h vrios tipos de vulnerabilidades
como o SQL injection, o Cross Site Scripting (XSS), conexes no criptografadas e outras
mais. Atravs dessa lista, os desenvolvedores do Web2py focaram em evitar que as aplicaes
desenvolvidas com Web2py sofressem dessas mais famosas e perigosas vulnerabilidades.
Com todas as facilidades ofertadas pelo Web2py, aliadas segurana que o framework
insere nas aplicaes desenvolvidas, faz com que o Web2py seja considerado uma tima ferra-
menta para desevolvimento gil e seguro de aplicaes web em linguagem Python.
55
7 DESENVOLVIMENTO
Nessa etapa, ser feito um detalhamento dos materiais utilizados no prottipo do projeto,
assim como as etapas realizadas para o desenvolvimento do mesmo.
7.1 Mtodo
De acordo com a classificao de PRODANOV e FREITAS (2013), este projeto se

tratou de uma pesquisa experimental, onde a implementao do prottipo buscou comprovar
a eficincia das tcnicas, e aplicada, pois buscou resolver o problema de gerenciamento de
mltiplos APs, utilizando hardware de baixo custo e software livre, com o objetivo de reduzir
custos.
Para o desenvolvimento do projeto, foram seguidas as seguintes etapas:
1. Estudo da literatura envolvida;
2. Substituio dos firmwares originais dos APs pelo OpenWrt;
3. Desenvolvimentos dos algoritmos que permitiram o envio de comandos para os APs com
o OpenWrt j instalados, que chamaremos de mdulo de comunicao;
4. Desenvolvimento do prottipo do sistema web aplicando o mdulo de comunicao com

os APs;
5. Instalao do prottipo do sistema web no Raspberry Pi;
6. Testes Prticos.
7.2 Materiais
7.2.1 TP-Link TL-WR740N
O TL-WR740N um dispositivo de conexo de rede cabeada/wireless integrado com

um roteador de compartilhamento de internet e um switch de 4 portas. O Roteador wireless N
compatvel com os padres IEEE 802.11b e IEEE 802.11g, baseado na tecnologia do padro
IEEE 802.11n e oferece um desempenho de at 150Mbps (TPLINK, 2015).
Esse equipamento, apesar de tambm ser um roteador, ser utilizado apenas como
Access Point. Para isso, ser utilizado apenas as portas LAN do equipamento.
Nos testes prticos, sero utilizados dois dispositivos desse modelo, sendo que um
modelo utiliza a verso de hardware v4.23 e o outro utiliza a verso v4.25. Essa verso do
hardware muito importante, pois atravs disso saberemos qual o arquivo imagem do sistema
56 Captulo 7. DESENVOLVIMENTO
OpenWrt correta a ser utilizada para cada verso de hardware, onde a utilizao da verso errada
pode acarretar na inutilizao do equipamento.
Figura 15 Viso frontal e traseira do TP-Link TL-WR740N.
Fonte: (TPLINK, 2015).
importante saber que a substituio do firmware original por firmware de terceiros

(que o caso do OpenWrt) faz com que o equipamento perca o direito garantia de suporte
oferecida pelo fabricante.
7.2.2 Raspberry Pi B+
Esse pequeno computador ser utilizado para hospedar o prottipo do sistema de

gerenciamento centralizado de dispositivos WiFi. O Raspberry Pi B+ far uso da sua porta
ethernet para se comunicar com os APs.
Figura 16 Raspberry Pi modelo B+.
Fonte: (ELEMENT14, 2015).

7.3. Implementao 57
Apesar de pequeno e de ter um hardware de desempenho modesto, o Raspberry Pi

poderoso o suficiente para hospedar um sistema web que no necessita de tanto processamento.
Alm disso, as suas dimenses reduzidas e baixo consumo de energia, facilitam a acomodao
desse equipamento em lugar seguro sem requerer muito espao.
7.3 Implementao
O projeto de Gerenciador de Redes WiFi tem como objetivo criar um sistema para
gerenciar dispositivos WiFi em uma rede local. Para realizar essa tarefa, o sistema contar
com uma interface de configurao que poder ser acessada por qualquer navegador, onde as
configuraes feitas pela interface web so enviadas aos APs.
Os APs funcionam como servidores Telnet, esperando para serem acessados pelo
sistema de gerenciamento WiFi, que por sua vez converte as configuraes feitas pela interface
web em comandos UCI e acessa os APs cadastrados no sistema por linha de comando atravs do
protocolo Telnet. Podemos ver na Figura 17 a arquitetura dos elementos da rede e a topologia
utilizada:
Figura 17 Topologia e arquitetura da rede e de seus elementos.
Para conseguir chegar ao prottipo funcional, foi necessrio seguir um pequeno roteiro,
onde cada etapa de fundamental importncia para o sucesso dos testes.
7.3.1 Instalao do OpenWrt
O primeiro passo para substituir o firmware original do dispositivo pelo OpenWrt

verificar as especificaes do hardware do prprio dispositivo, verificando se esse dispositivo
compatvel com o OpenWrt e qual a verso mais recente est disponvel para ele.
Mais informaes podem ser encontradas no site do OpenWrt, na seo denominada
Table of Hardware, que contm as informaes pertinentes todos os equipamentos que j tem
suporte ao sistema e aos equipamento que esto em fase adaptao.
O processo de instalao do OpenWrt ser feito acessando a interface web do firmware
original do dispositivo na seo System Tools > Firmware Upgrade, semelhante ao que podemos
ver na Figura 18. Nessa parte, basta selecionar o arquivo do sistema compatvel com o hardware
do dispositivo, clicar em Upgrade e esperar cerca 90 segundos para que o firmware de fbrica
seja substitudo pelo OpenWrt(o que pode acarretar na perda de garantia do fabricante).
importante que seja utilizado a verso do OpenWrt especfico para o hardware em questo
e que o fornecimento de energia no seja interrompido, pois isso pode acabar inutilizando o
equipamento.
Figura 18 Simulador online do dispositivo TL-WA701ND.
Fonte: http://www.tp-link.com.br/resources/simulator/TL-WA701ND/Index.htm
Aps o trmino do processo, a interface de configurao do equipamento fica acessvel

ao usurio atravs do endereo 192.168.1.1, acessado pelo navegador.
7.3. Implementao 59
7.3.2 Desenvolvimento do Prottipo
O prottipo do Sistema de Gerenciamento de Redes WiFi uma demonstrao do

funcionamento efetivo da proposta que est sendo oferecida. Nele foi implementado as seguintes
funcionalidades:
Gerenciamento dos dispositivos: nessa seo possvel cadastrar , editar e remover os

dispositivos WiFi que sero gerenciados atravs do endereo IP e modificar o canal da
faixa de 2.4 GHz que cada AP utilizar;
Gerenciamento de SSIDs: nessa seo possvel editar dois SSIDs que sero exibidos
por todos os APs cadastrados. Ser possvel modificar cada SSID, editando o prprio
nome do SSID, o tipo de criptografia utilizada para fazer autenticao, a senha de acesso e
at mesmo os dados de um servidor RADIUS para prover a autenticao externa.
Todo o sistema de gerenciamento foi feito utilizando o web2py, onde o sistema dividido
em duas partes, a primeira parte a dos views, models e controllers, que visam fornecer toda a
parte interao com o usurio, manipulao e armazenamento dos dados; e a segunda parte a do
mdulo de comunicao, que foi implementado com o objetivo de receber os dados fornecidos
pelo usurio, convert-los para comandos de texto UCI e enviar esses comandos todos os APs
cadastrados por meio do protocolo Telnet
Figura 19 Tela principal do prottipo do sistema.
Na Figura 19, possvel ver a tela principal do prottipo do sistema de Gerenciamento

de Rede Redes WiFi, onde est disponvel, no menu lateral, as duas opes para acessar as
sees que foram implementadas no prottipo, descritas anteriormente.
Todos os cdigos referentes ao prottipo do sistema estaro disponveis nos Apndice

A, B e C, para melhor entendimento do funcionamento do que foi feito.
7.3.3 Instalao do Prottipo no Raspberry Pi
O processo de deploy de uma aplicao no web2py bem simples. Depois que a

aplicao finalizada basta ir na rea administrativa do web2py e exportar a aplicao, que
ir resultar em um arquivo com extenso "w2p". Esse arquivo dever ser utilizado para subir
a aplicao no local de hospedagem de escolha do usurio (desde que seja compatvel com
web2py).
No Raspberry Pi foi criado um ambiente de hospedagem para o prottipo do nosso
sistema, esse ambiente vai ser instalado no sistema operacional do Rapberry Pi, o Raspbian, onde
o web2py est executando em conjunto com um servidor Apache com o protocolo HTTPS ativo.
Para criar esse ambiente, foi utilizado um script de configurao do desenvolvido ser
usado em distribuies Linux Debian. Esse script serve pra instalar todos os componentes
necessrios para hospedar aplicaes feitas em web2py. As principais modificaes feitas pelo
script so as seguintes:
Instalar os mdulos necessrios para executar o web2py;
Instalar o web2py no diretrio "/home/www-data/";
Criar um certificado auto-assinado SLL;
Configurar web2py com mod_wsgi;
Sobrescrever o diretrio "/etc/apache2/sites-available/default";
Reiniciar o Apache.
O script est disponvel na sua forma completa no Apndice D para quem quiser obter
mais aprofundamento sobre o funcionamento do mesmo.
Nesse ponto, caso no ocorra nenhum problema durante a execuo do script de
instalao, o ambiente estar pronto para importar o Sistema de Gerenciamento de Rede WiFi
por meio da aplicao admin do web2py, que server para gerenciar as aplicaes instaladas.
Para o funcionamento do sistema, tambm exigido a instalao do banco de dados
MySQL, onde ser criada uma tabela com o nome "wifi".
7.3.4 Testes Prticos
Para realizar os testes prticos foram utilizados dois dispositivos TP-Link TL-WR740N
(um com o hardware v4.23 e o outro com o hardware v4.25) e um Raspberry Pi modelo B+.
Foi feito o processo de substituio do firmware do fabricante pelo OpenWrt nos TP-Link TL-
WR740N, a execuo do script para criao do ambiente de execuo de aplicaes web2py com
7.3. Implementao 61
servidor web Apache no Raspberry Pi e a importao da aplicao do Sistema de Gerenciamento

de Rede WiFi.
O objetivo do teste criar uma rede LAN composta por dois dispositivos TP-Link
TL-WR740N executando o OpenWrt, um Raspberry Pi modelo B+ hospedando o prottipo do
Sistema de Gerenciamento de Rede WiFi, um computador ou notebook para acessar a interface
web do prottipo do sistema, para realizar as devidas configuraes, e um smartphone Android
com o aplicativo Wifi Analyzer para verificar as modificaes feitas na rede WiFi em tempo real.
A Figura 20 mostra como foi feita as conexes entre os dispositivos usados durante os
testes.
Figura 20 Esquema de conexes entre os dispositivos da LAN.
importante que alguns desses equipamento tenham endereamento IPV4 atribudos

de forma esttica. Na Tabela 2, exibida a relao de endereamento de rede IPV4 atribudo
para cada dispositivo da rede.
Tabela 2 Endereamento usado nos testes.
Dispositivo Endereo IPV4

Raspberrt Pi 192.168.1.200/24
AP1 192.168.1.201/24
AP2 192.168.1.202/24
Notebook Pode ser atribudo por DHCP
Note que na Tabela 2 no foi inserido o endereo IPV4 do smartphone. Isso acontece
porque ele vai ter o papel de simplesmente monitorar as modificaes feitas nos SSIDs e
criptografias de autenticao utilizadas. Para realizar essa funo, o smartphone s precisava ter
o aplicativo Wifi Analyzer instalado e no precisava estar conectado rede WiFi.
Com toda a rede montada e os dispositivos se comunicando normalmente, usamos o
notebook para acessar o sistema de gerenciamento para cadastrar os dispositivos. Para realizar
essa tarefa, basta abrir o navegador e colocar o endereo 192.168.1.200. Feito isso, o navegador
mostrou a tela mostrada na Figura 19, onde foi clicado na seo "Dispositivos".
Figura 21 APs cadastrados no sistema.
Na seo "Dispositivos", est disponvel a opo de adicionar novos dispositivos e editar

ou remover os dispositivos j cadastrados. possvel ver, na Figura 21, que foi feito o cadastro
do "AP 1"de "AP 2"utilizando os endereamentos previamente definidos na Tabela 2, alm disso
foi definido que os APs funcionariam nos canais 1 e 6 da faixa de 2.4 GHz, respectivamente.
Figura 22 Resumo das configurao dos SSIDs no sistema.
Para mostrar o efetivo funcionamento do prottipo do Sistema de Gerenciamento de

Rede WiFi, faremos um teste que consiste em mostrar o estado atual dos SSIDs no sistema,
7.3. Implementao 63
como mostra a Figura 22, e comparar com o que mostra o aplicativo Wifi Analyzer, como na
Figura 23. Aps isso, editar as configuraes atravs do sistema e aplicar as configuraes nos
APs, finalizando com uma nova comparao com o que mostra o Sistema de Gerenciamento de
Rede WiFi e o Wifi Analyzer, para comprovar que as modificaes feitas pelo sistema refletem
nos APs em poucos segundos.
Figura 23 Primeiro escaneamento das redes WiFi no local feita pelo Wifi Analyzer.
A Figura 23 mostra que as configuraes esto compatveis com as informaes do

sistema, onde cada SSID aparece duas vezes. Isso acontece porque cada AP exibe dois SSIDs
diferentes, sendo comprovado pelo fato de os SSIDs repetidos estarem em canais de 2.4GHz
diferentes, pois apesar de cada AP ter dois SSIDs, cada um possui apenas um rdio.
O prximo passo foi fazer as modificaes nos SSIDs para que fosse possvel verificar
a mudana acontecer, de fato, atravs do Wifi Analyzer. Para isso, foi modificado o nome do
primeiro SSID para "SSID_01_MODIFICADO"e o tipo autenticao para "Aberto", no segundo
SSID foi modificado o nome para "SSID_02_MODIFICADO"e o tipo de autenticao para
"WPA-PSK", como pode ser visto na Figura 24.
Figura 24 Resumo das configurao dos SSIDs no sistema aps as modificaes.
Aps cerca de cinco segundos, as configuraes feitas so efetivadas nos APs e eles j
comeam a se comportar de acordo com o que foi definido no sistema, a prova disso a Figura
25, que mostra o escaneamento das redes WiFi durante os testes, onde o resultado mostra total
compatibilidade com as configuraes feitas no Sistema de Gerenciamento de Rede WiFi.
Figura 25 Segundo escaneamento das redes WiFi no local feita pelo Wifi Analyzer.

65
8 CONCLUSO
Garantir uma forma fcil e barata de gerenciar dispositivos de rede WiFi na rede facilita
muito a adoo dessa tecnologia por parte de pequenas e mdias empresas e em ambientes
domsticos, uma vez que ela facilita a configurao dos dispositivos cadastrados e garante a
escalabilidade da rede de forma mais simples.
Durante o desenvolvido prottipo do projeto, algumas dificuldades acabaram aparecendo
devido a falta de experincia com algumas tecnologias utilizadas, mas, no final, conseguimos
chegar a um prottipo funcional, conseguindo atender as funcionalidades propostas, inicialmente,
nos objetivos especficos.
8.1 Resultados
Ao final do desenvolvimento do prottipo do projeto, foi realizado o que foi proposto,

fazer um prottipo capaz de enviar comandos de configurao a dispositivos WiFi com o
firmware OpenWRT instalado atravs de uma interface web (atravs do navegador de internet)
simples, e possibilitar ao usurio a autenticao nica na rede, uma vez que cada AP contm os
mesmos SSIDs, formas de autenticao e senhas, dessa forma o usurio s precisa configurar as
credenciais de acesso rede uma vez e poder acessar por qualquer AP cadastrado no sistema.
8.2 Dificuldades Encontradas
Como a proposta do prottipo do Sistema Gerenciamento da Rede Wifi era oferecer

uma interface para centralizar o gerenciamento dos ativos de rede Wifi, seria necessrio oferecer
a possibilidade de fazer isso de qualquer lugar da LAN (e possivelmente fora dela tambm),
da nasceu a nossa maior dificuldade: oferecer ao usurio o acesso ao sistema da forma fcil e
independente da plataforma utilizada para fazer o acesso, ou seja, atravs de uma interface web,
acessvel atravs de qualquer navegador web comum.
A maior dificuldade foi em encontrar uma forma de integrar a interface de configurao
ao mdulo de configurao dos mltiplos dispositivos na rede. Essa dificuldade foi resolvida
com o uso do framework Web2Py, usado para desenvolvimento web. A escolha do Web2Py
foi essencial, pois o cdigo do mdulo de comunicao com os dispositivos WiFi foi feito em
Python, o que acabou facilitando a integrao das duas partes.
8.3 Aprendizado do Projeto
No decorrer dos estudos na graduao, muitos aprendizados e conceitos foram apresen-

tados, porm, muitas vezes de forma isolada (para aplicaes especficas). Dessa forma, nem
66 Captulo 8. CONCLUSO
sempre foi possvel ver as mltiplas aplicaes para o que aprendemos e fica difcil, para alguns,
pensar fora do contexto da disciplina e ampliar as possibilidades de uso do que aprendemos.
Dessa maneira, o maior aprendizado obtido foi na utilizao de mltiplos conceitos
e tecnologias, resultando em um amadurecimento multidisciplinar e na descoberta da grande
vantagem da utilizao de vrios conceitos para a soluo dos problemas enfrentados pela
humanidade.
8.4 Contribuies
Com o crescimento da utilizao do padro IEEE 802.11 (WiFi) em vrios ambientes

e por vrias classes sociais, torna-se cada vez mais evidente a necessidade de uma rede WiFi
escalvel, homognea e de fcil gerncia e configurao.
Com isso, a maior contribuio desse trabalho est em descrever conceitos que podem
ser aplicados na construo dessa soluo, utilizando software livre e hardware de baixo custo.
8.5 Trabalhos Futuros
Esse trabalho criou a base para a construo de um projeto de rede WiFi com gerncia
e configurao centralizada, de forma que o foco sempre esteve em conseguir implementar os
conceitos bsicos, com o objetivo de ser chegar a um prottipo funcional do sistema, sem se
preocupar muito com funcionalidades como a segurana das informaes.
Sendo assim, foi definido como trabalhos futuros, a possibilidade de implementao
de prottipos funcionais que implementem, principalmente, funes de segurana, que um
fator essencial na atualidade. Para isso, poderamos citar citar como melhoria que poderiam ser
implementadas em trabalhos futuros:
A utilizao de VLANs para garantir a segunrana dos dados trafegados;
A substituio do Telnet pelo SSH como forma de comunicao entre o sistema e os APs;
Criao de mtodos de autenticao para garantir acesso autorizado ao painel de configu-

rao do sistema apenas para usurios autorizados;
Migrao do sistema de gerenciamento para o ambiente de Computao em Nuvem.

67
Referncias
CARROLL, B. J. CCNA Wireless Official Exam Certification Guide. Indianapolis: Cisco

Press, 2009.
CCM. O protocolo Telnet. 2015. Disponvel em: <http://br.ccm.net/contents/

286-o-protocolo-telnet>. Acesso em: 15.11.2015.
ELEMENT14. 2015. Disponvel em: <http://http://www.element14.com/>. Acesso em:

25.10.2015.
FOROUZAN, B. Comunicao de Dados e Redes de Computadores. Porto Alegre: ed. 3,

Bookman, 2006.
FOUNDATION, R. P. ABOUT US. 2015. Disponvel em: <https://www.raspberrypi.org/about/>.

Acesso em: 25.10.2015.
GARCIA, L. G. U. REDES 802.11 (Camada de Enlace). 2003. Disponvel em:

<http://www.gta.ufrj.br/grad/01_2/802-mac/>. Acesso em: 10.05.2015.
GAST, M. 802.11 Wireless Networks: The Definitive Guide. [S.l.]: ed. 2, OReilly, 2005.
ISBN 0596100523.
HOLT, A.; HUANG, C. 802.11 wireless networks security and analysis. London: Springer,
2010. ISBN 978-1-84996-274-2.
KOZIEROK, C. M. Telnet Protocol. 2005. Disponvel em: <http://www.tcpipguide.com/free/t_

TelnetProtocol.htm>. Acesso em: 15.11.2015.
MORAES, A. Segurana em Redes: Fundamentos. So Paulo: ERICA, 2010. ISBN

9788536503257.
OHARA, B.; PETRICK, A. IEEE 802.11 Handbook: A Designers Companion. [S.l.]: Wiley,
2005. (IEEE standards wireless networks series).
OPENWRT. 2015. Disponvel em: <https://openwrt.org/>. Acesso em: 04.11.2015.
PIERRO, M. D. Web2py: Complete Reference Manual. Chicago, IL: Experts4Solutions, 2013.
POSTEL, J.; REYNOLDS, J. Request for Comments 854: TELNET PROTOCOL

SPECIFICATION. 1983. Disponvel em: <https://tools.ietf.org/html/rfc854>. Acesso em:
15.11.2015.
PRODANOV, C. C.; FREITAS, E. C. Metodologia do trabalho cientfico: mtodos e tcnicas

da pequisa e do trabalho acadmico. [S.l.]: 2. ed. - Novo Hamburgo: Feevale, 2013.
PYTHON. Web2pyt. 2013. Disponvel em: <http://http://wiki.python.org.br/>. Acesso em:

17.11.2015.
SCHMIDT, M. Raspberry Pi: a quick-start guide. Firsco, TX: The Pragmatic Programmers,
2014. ISBN 978-1-93778-580-2.
68 Referncias
STALLINGS, W. Redes de Sistemas de Comunicao de Dados: Teoria e Aplicaes

Corporativas. Rio de Janeiro: ed. 5, Elsevier, 2005.
TPLINK. Roteador Wireless N 150Mbps. 2015. Disponvel em: <http://www.tp-link.com.br/

products/details/cat-9_TL-WR740N.html>. Acesso em: 28.11.2015.
VIEIRA, D. IEEE 802.11. 2005. Universidade Federal do Rio de Janeiro.
VINCI, O.; FERREIRA, P. WiIP Sistema de Comunicao VoIP Wi-Fi. So Paulo, 2007.
Apndices
71
APNDICE A Cdigo do Controller do Prottipo
# -*- coding: utf-8 -*-
#########################################################################
## UEMA - Universidade Estadual do Maranho
## Curso de Engenharia da Computao
## Desenvolvido por Lucas Jeferson da Costa Silva com base no modelo for-
## necido pelo framework web2py
##
## Esse o controller default, responsvel por realizar todas funes do
## prottipo.
#########################################################################
from enviar import *
def wifi():
return dict()
def ssid():
rows = db().select(db.t_wireless.ALL)
return dict(rows = rows)
def edit_ssid():
arg = request.args(0, cast=int)
form = SQLFORM(Wireless, arg, showid=False, submit_button=Salvar)
if form.accepts(request,session):
session.flash = form accepted
redirect(URL(ssid))
elif form.errors:
response.flash = form has errors
else:
response.flash = please fill the form
return dict(form=form)
def dispositivos():
rows = db().select(db.t_dispositivo.ALL)
return dict(rows = rows)
def add_dispositivo():
form = SQLFORM(Dispositivos, submit_button=Salvar)
if form.process().accepted:
form_canal = form.vars.f_canal
form_end = form.vars.f_endereco
enviarTelnetSimples(wireless.radio0.channel=+form_canal+\n,form_end)
redirect(URL(aplicar))
elif form.errors:
response.flash = Erros no formulrio!
else:
response.flash = Preencha o formulrio!
def del_dispositivo():
72 APNDICE A. Cdigo do Controller do Prottipo
db(Dispositivos.id==request.args(0, cast=int)).delete()
redirect(URL(dispositivos))
def edit_dispositivo():
arg = request.args(0, cast=int)
form = SQLFORM(Dispositivos, arg, showid=False, submit_button=Salvar)
if form.accepts(request,session):
form_canal = form.vars.f_canal
form_end = form.vars.f_endereco
enviarTelnetSimples(wireless.radio0.channel=+form_canal+\n,form_end)
redirect(URL(aplicar))
elif form.errors:
response.flash = form has errors
else:
response.flash = please fill the form
def aplicar():
listaDeComandos = []
for rows in db().select(db.t_wireless.ALL):
dictDados = {}
if (rows.f_disable):
dictDados[disable] = 1
else:
dictDados[disable] = 0
dictDados[ssid] = rows.f_ssid
dictDados[encryption] = converter_cript(rows.f_encryption)
dictDados[key] = rows.f_key
dictDados[server] = rows.f_server
dictDados[port] = rows.f_port
numeroDaInterface = int(rows.id) - 1
listaDeComandos += gerarComandos(dictDados, str(numeroDaInterface))
listDispositivos = []
for row in db().select(db.t_dispositivo.ALL):
print(row.f_endereco)
listDispositivos.append(row.f_endereco)
enviarTelnet(listDispositivos, listaDeComandos)
message = "Enviado!"
return dict(message = message)
73
APNDICE B Cdigo do Model do Prottipo
# -*- coding: utf-8 -*-
#########################################################################
## UEMA - Universidade Estadual do Maranho
## Curso de Engenharia da Computao
## Desenvolvido por Lucas Jeferson da Costa Silva com base no modelo for-
## necido pelo framework web2py
##
## Esse o model, responsvel por realizar toda a modelagem de banco de
## dados do sistema.
#########################################################################
## app configuration made easy. Look inside private/appconfig.ini

from gluon.contrib.appconfig import AppConfig
## once in production, remove reload=True to gain full speed
myconf = AppConfig(reload=True)
if not request.env.web2py_runtime_gae:
#Conexo com o banco de dados MySQL local.
db = DAL(mysql://root:123456@localhost/wifi)
else:
## connect to Google BigTable (optional google:datastore://namespace)
db = DAL(google:datastore+ndb)
## store sessions and tickets there
session.connect(request, response, db=db)
## or store session in Memcache, Redis, etc.
## from gluon.contrib.memdb import MEMDB
## from google.appengine.api.memcache import Client
## session.connect(request, response, db = MEMDB(Client()))
## by default give a view/generic.extension to all actions from localhost

## none otherwise. a pattern can be controller/function.extension
response.generic_patterns = [*] if request.is_local else []
## choose a style for forms
response.formstyle = myconf.take(forms.formstyle)
# or bootstrap3_stacked or bootstrap2 or other
response.form_label_separator = myconf.take(forms.separator)
from gluon.tools import Auth, Service, PluginManager
auth = Auth(db)
service = Service()
plugins = PluginManager()
## create all tables needed by auth if not custom tables

auth.define_tables(username=False, signature=False)
## configure email
mail = auth.settings.mailer
74 APNDICE B. Cdigo do Model do Prottipo
mail.settings.server=logging if request.is_local else myconf.take(smtp.server)

mail.settings.sender = myconf.take(smtp.sender)
mail.settings.login = myconf.take(smtp.login)
## configure auth policy

auth.settings.registration_requires_verification = False
auth.settings.registration_requires_approval = False
auth.settings.reset_password_requires_verification = True
Dispositivos = db.define_table(t_dispositivo,
Field(f_endereco, string, label=IP do dispositivo),
Field(f_canal, string, requires=IS_IN_SET(range(1,12)), label=Canal do AP),
Field(f_nome, string, label=Nome do AP)
)
encList = [Aberto, WPA-PSK, WPA2-PSK, WPA2-Enterprise]

Wireless = db.define_table(t_wireless,
Field(f_disable, boolean, label=Desativar),
Field(f_ssid, string, label=SSID),
Field(f_encryption,string,requires=IS_IN_SET(encList),label=Criptografia),
Field(f_key, string, label=Senha),
Field(f_server, string, label=IP do servidor RADIUS),
Field(f_port, string, label=Porta do Servidor RADIUS)
)
75
APNDICE C Cdigo do Mdulo de Comunicao do Prottipo
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from gluon import *
import socket
import telnetlib
def gerarComandos(dictComandos, num):

#Comando base para outros comandos
comando = "uci set wireless.@wifi-iface[<num>].<opt>=<com>"
#Cria uma lista com os comandos, contidos no dicionrio, que sero utilizados
listComandos = dictComandos.keys()
#Criando uma lista com os comandos que sero dados no final

listComFinal = []
com1 =
for x in listComandos:
auxComando = comando
auxComando = auxComando.replace("<num>",num)
auxComando = auxComando.replace("<opt>",str(x))
auxComando = auxComando.replace("<com>",str(dictComandos[x]))
com1 += auxComando + \n
listComFinal.append(com1)
return listComFinal
def enviarTelnet(dictDadosDisp, listComandos):

#Envio de multiplos comandos por Telnet
listComandos.append(uci commit wireless \n)
listComandos.append(wifi \n)
listComandos.append(exit \n)
for key in dictDadosDisp:
#teste(\n\nConectado a %s \n\n % key)
tn = telnetlib.Telnet(key)
for x in listComandos:
tn.write(x)
#teste(x)
print tn.listener()
tn.close()
def enviarTelnetSimples(comando, disp):

#Envio simples por Telnet
tn = telnetlib.Telnet(disp)
tn.write(comando + \n)
tn.close()
def converter_cript(ssid):
if ssid == Aberto:
return none
elif ssid == WPA-PSK:
76 APNDICE C. Cdigo do Mdulo de Comunicao do Prottipo
return psk
elif ssid == WPA2-PSK:
return psk2
elif ssid == WPA2-Enterprise:
return wpa2
else:
return none
77
APNDICE D Script de Configurao do Web2py com Apache no Raspberry Pi
Disponvel para download em: http://web2py.googlecode.com/hg/scripts/setup-web2py-debian-sid.sh
echo "This script will:

1) install all modules need to run web2py on Ubuntu/Debian
2) install web2py in /home/www-data/
3) create a self signed sll certificate
4) setup web2py with mod_wsgi
5) overwrite /etc/apache2/sites-available/default
6) restart apache.
You may want to read this script before running it.
Press a key to continue...[ctrl+C to abort]"
read CONFIRM
#!/bin/bash
# optional
# dpkg-reconfigure console-setup
# dpkg-reconfigure timezoneconf
# nano /etc/hostname
# nano /etc/network/interfaces
# nano /etc/resolv.conf
# reboot now
# ifconfig eth0
echo "installing useful packages"

echo "=========================="
apt-get update
apt-get -y install ssh
apt-get -y install zip unzip
apt-get -y install tar
apt-get -y install openssh-server
apt-get -y install build-essential
apt-get -y install python2.5
apt-get -y install ipython
apt-get -y install python-dev
apt-get -y install postgresql
apt-get -y install apache2
apt-get -y install libapache2-mod-wsgi
apt-get -y install python2.5-psycopg2
apt-get -y install postfix
apt-get -y install wget
apt-get -y install python-matplotlib
apt-get -y install python-reportlab
apt-get -y install mercurial
/etc/init.d/postgresql restart
# optional, uncomment for emacs

# apt-get -y install emacs
# optional, uncomment for backups using samba

# apt-get -y install samba
78 APNDICE D. Script de Configurao do Web2py com Apache no Raspberry Pi
# apt-get -y install smbfs
echo "downloading, installing and starting web2py"

echo "==========================================="
cd /home
mkdir www-data
cd www-data
rm web2py_src.zip*
wget http://web2py.com/examples/static/web2py_src.zip
unzip web2py_src.zip
mv web2py/handlers/wsgihandler.py web2py/wsgihandler.py
chown -R www-data:www-data web2py
echo "setting up apache modules"

echo "========================="
a2enmod ssl
a2enmod proxy
a2enmod proxy_http
a2enmod headers
a2enmod expires
a2enmod wsgi
mkdir /etc/apache2/ssl
echo "creating a self signed certificate"

echo "=================================="
openssl genrsa 1024 > /etc/apache2/ssl/self_signed.key
chmod 400 /etc/apache2/ssl/self_signed.key
openssl req -new -x509 -nodes -sha1 -days 365 -key
/etc/apache2/ssl/self_signed.key >/etc/apache2/ssl/self_signed.cert
openssl x509 -noout -fingerprint -text < /etc/apache2/ssl/self_signed.cert >

/etc/apache2/ssl/self_signed.info
echo "rewriting your apache config file to use mod_wsgi"

echo "================================================="
echo
NameVirtualHost *:80
NameVirtualHost *:443
# If the WSGIDaemonProcess directive is specified outside of all virtual
# host containers, any WSGI application can be delegated to be run within
# that daemon process group.
# If the WSGIDaemonProcess directive is specified
# within a virtual host container, only WSGI applications associated with
# virtual hosts with the same server name as that virtual host can be
# delegated to that set of daemon processes.
WSGIDaemonProcess web2py user=www-data group=www-data processes=1 threads=1
<VirtualHost *:80>
WSGIProcessGroup web2py
WSGIScriptAlias / /home/www-data/web2py/wsgihandler.py
WSGIPassAuthorization On
<Directory /home/www-data/web2py>
AllowOverride None
Order Allow,Deny
Deny from all
<Files wsgihandler.py>
79
Allow from all

</Files>
</Directory>
AliasMatch ^/([^/]+)/static/(?:_[\d]+.[\d]+.[\d]+/)?(.*) \
/home/www-data/web2py/applications/$1/static/$2
<Directory /home/www-data/web2py/applications/*/static/>
Options -Indexes
Order Allow,Deny
Allow from all
</Directory>
<Location /admin>
Deny from all
</Location>
<LocationMatch ^/([^/]+)/appadmin>
Deny from all
</LocationMatch>
CustomLog /var/log/apache2/access.log common

ErrorLog /var/log/apache2/error.log
</VirtualHost>
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/self_signed.cert
SSLCertificateKeyFile /etc/apache2/ssl/self_signed.key
WSGIProcessGroup web2py
WSGIScriptAlias / /home/www-data/web2py/wsgihandler.py
WSGIPassAuthorization On
<Directory /home/www-data/web2py>
AllowOverride None
Order Allow,Deny
Deny from all
<Files wsgihandler.py>
Allow from all
</Files>
</Directory>
AliasMatch ^/([^/]+)/static/(?:_[\d]+.[\d]+.[\d]+/)?(.*) \
/home/www-data/web2py/applications/$1/static/$2
<Directory /home/www-data/web2py/applications/*/static/>
Options -Indexes
ExpiresActive On
ExpiresDefault "access plus 1 hour"
Order Allow,Deny
Allow from all
</Directory>
CustomLog /var/log/apache2/access.log common

ErrorLog /var/log/apache2/error.log
</VirtualHost>
> /etc/apache2/sites-available/default
80 APNDICE D. Script de Configurao do Web2py com Apache no Raspberry Pi
echo "restarting apache"

echo "================"
/etc/init.d/apache2 restart
cd /home/www-data/web2py
sudo -u www-data python -c "from gluon.widget import console; console();"
sudo -u www-data python -c "from gluon.main import save_password;
save_password(raw_input(admin password: ),443)"
echo "done!"
}

Lucas Jeferson (Impressão)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lucas Jeferson (Impressão)

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE ESTADUAL DO MARANHO UEMA

CURSO DE ENGENHARIA DA COMPUTAO

LUCAS JEFERSON DA COSTA SILVA

SISTEMA DE GERENCIAMENTO DE REDES WIFI DE PEQUENO E MDIO PORTE

SISTEMA DE GERENCIAMENTO DE REDES WIFI DE PEQUENO E MDIO PORTE

Monografia apresentada Universidade Estadual

Orientador: MSc. Raimundo de Carvalho Silva Neto

Monografia (Graduao) Curso de Engenharia da Computao,

Orientador: Prof. Raimundo de Carvalho da Silva Neto.

1.Wi-fi. 2.Gerenciamento. 3.RaspberryPi. 4.OpenWrt. I.Ttulo

SISTEMA DE GERENCIAMENTO DE REDES WIFI DE PEQUENO E MDIO PORTE

Monografia apresentada Universidade Estadual

Trabalho aprovado. So Lus, MA, 12 de janeiro de 2015:

MSc. Raimundo de Carvalho Silva Neto

Dr. Lcio Flvio de Albuquerque Campos

Esp. Marcelo Renato do Carmo Pereira

Aos meus orientadores, por toda contribuio no desenvolvimento desse trabalho.

Palavras-chaves: WiFi, Gerenciamento, Raspberry Pi, OpenWrt.

Key-words: WiFi, Management, Raspberry Pi, OpenWrt.

Figura 1 Camada MAC e PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Tabela 1 Detalhes dos comandos UCI . . . . . . . . . . . . . . . . . . . . . . . . . 43

Ponto de Acesso - Access Point

Rede Local Sem Fio

Direct-Sequence Spread Spectrum

Frequency-Hopping Spread Spectrum

Institute of Electrical and Electronic Engineers

Media Access Control

Logical Link Control

Remote Authentication Dial In User Service

Basic Service Set

Distribution System Service

Extended Service Set

Structured Query Language

Service Set Identifier

Wired Equivalent Privacy

Wi-Fi Protected Access

Network Access Server

Unified Configuration Interface

Robust Security Network Association

Secure Socket Layers

Pre Shared Key

Extensible Authentication Protocol

Point to Point Protocol

Generic Token Card

Transport Layer Security

Tunneled Transport Layer Security

Protected Extensible Authentication Protocol

Challenge Handshake Authentication Protocol

Extensible Authentication Protocol over LAN

Lightweight Directory Access Protocol

Pluggable Authentication Modules

Network Information Service

Remote Authentication Dial In User Service

Counter Mode with CBC-MAC

Advanced Encryption Standart

General Public License

Non-Volatile Random Access Memory

Domain Name System

Dynamic Host Configuration Protocol

Network Address Translation

Transmission Control Protocol

HyperText Markup Language

Terminal Virtual de Rede

Graphics Processing Unit