Wi-Mesh na prática 1

Olá pessoal,

Sou novo em rede wireless em malha, só tomei ciência da sua existência no final de 2007, em dezembro, e fiquei encantado com a proposta da tecnologia. Tratei de ir correndo no mesmo dia comprar algum material e tentar montar uma MESH. Saquei dos Zinwell G120 com aproute 6.1, e fiz os testes iniciais no escritório. Inicialmente queria ver um conversando com o outro, sem saber por onde começar, virei a noite toda e não consegui nada. Normal :)

Mas, no dia seguinte com a cabeça fria, tive o primeiro sucesso com eles, pingavam entre si e trocavam suas tabelas de roteamento numa boa, só que quando tinham que acessar a LAN em um dois rádios não conseguia, foi então que testei várias combinações dos modos disponíveis nos rádios, chegando a essa configuração: para Gateway (o nó que vaí dá acesso a Internet
) use o modo Roteador Wan e para rádio que vai ter clientes pendurados nele, o velho Cliente ISP, dessa forma funcionou 100%.

Continuando minha missão, tentei fazer meu notebook se conectar a eles. Para isso, instalei o OLSRD para windows que pode ser baixado em olsr.org e fiz a configuração adequada (aproveite e dá uma olhada no arquivo de configuração Default, peguei uns macetes nele). Pense numa coisa legal, saí com dois notes conectados em um dos rádios equipados antenas de 5 dbi cada um, e consegui acesso normal até uns 100mts (o rádio ficou em um primeiro andar de uma casa) daí em diante, tipo cinco metros a mais, caiu a conexão dos dois notebooks. Sendo assim, voltei ao ponto onde conseguia ficar conectado e mandei a pessoa com o outro notebook ir mais adiante, ele automaticamente passou a se conectar ao primero notebook e foi 100 metros a frente conectado, beleza!

Nesse momento, a empolgação bateu, e fui além. Coloquei uma omni que tenho em cima de um prédio em modo ad-hoc e configurei para MESH e colequei um cliente com uma direcional acessando ele, funciona perfeitamente.

Daí resolvi comprar mais duas omnis de 12dbi ( só comprei por que no dia só tinha essas para pronta entrega, o bacana são as 8dbi) e mais dois Zinwell g120, o g220 não rolou não (todos com aproute 6.1).

Coloquei uma omni 12dbi em uma casa de primeiro andar a cerca de 600mts do prédio de 9 andares, e a segunda a mais 600mts da casa de primeiro andar, em uma casa de três andares, e para finalizar mais um Zinwell G120 (Gw Internet) no escritório a 100 metros da primeira casa. Tudo configurado e funcionando, mas é claro que os problemas vinheram, vamos a eles.

Antes de falar sobre os problemas, vou postar as configurações de cada equipamento.

Antes de falar sobre os problema, vou postar as configurções de cada equipamento.

Prédio de 9 andares:

Zinwell G120 - APRouter 6.1 - Omni 8dbi

Modo de Operação : Roteador (WAN Ethernet)
Wireless : Ad-hoc Cliente
SSID: mesh (o mesmo para todos)
Canal:2 ( O mesmo para todos)
Banda: B
LAN IP : 192.16.0.65 --> Esse aqui é o ip dos clientes.
WAN IP: 172.16.0.200 --> Esse o ip que vai para o gateway de Internet

Conteúdo do arquivo olsrd.conf, em /etc/
# cd /etc/
# cat olsrd.conf
#
# olsr.org OLSR daemon config file
#
# Lines starting with a # are discarded
#
# This file was shipped with olsrd 0.X.X
#

# Debug level(0-9)
# If set to 0 the daemon runs in the background

DebugLevel 0

# IP version to use (4 or 6)

IpVersion 4

# Clear the screen each time the internal state changes

ClearScreen yes

# HNA IPv4 routes
# syntax: netaddr netmask
# Example Internet gateway:
# 0.0.0.0 0.0.0.0

Hna4
{
# Internet gateway:
0.0.0.0 0.0.0.0 --> Diz que esse rotedor vai dá acesso para Internet
# more entries can be added:
# 192.168.1.0 255.255.255.0
}

# Should olsrd keep on running even if there are
# no interfaces available? This is a good idea
# for a PCMCIA/USB hotswap environment.
# "yes" OR "no"

AllowNoInt yes

# TOS(type of service) value for
# the IP header of control traffic.
# If not set it will default to 16

#TosValue 16

# The fixed willingness to use(0-7)
# If not set willingness will be calculated
# dynamically based on battery/power status
# if such information is available

#Willingness 4

# Allow processes like the GUI front-end
# to connect to the daemon.

IpcConnect
{
# Determines how many simultaneously
# IPC connections that will be allowed
# Setting this to 0 disables IPC

MaxConnections 0

# By default only 127.0.0.1 is allowed
# to connect. Here allowed hosts can
# be added

Host 127.0.0.1

# You can also specify entire net-ranges
# that are allowed to connect. Multiple
# entries are allowed

#Net 192.168.1.0 255.255.255.0
}

# Whether to use hysteresis or not
# Hysteresis adds more robustness to the
# link sensing but delays neighbor registration.
# Used by default. 'yes' or 'no'

UseHysteresis no

# Hysteresis parameters
# Do not alter these unless you know
# what you are doing!
# Set to auto by default. Allowed
# values are floating point values
# in the interval 0,1
# THR_LOW must always be lower than
# THR_HIGH.

HystScaling 0.50
HystThrHigh 0.80
HystThrLow 0.30


# Link quality level
# 0 = do not use link quality
# 1 = use link quality for MPR selection
# 2 = use link quality for MPR selection and routing
# Defaults to 0

LinkQualityLevel 2

# Link quality window size
# Defaults to 10

LinkQualityWinSize 10

# Polling rate in seconds(float).
# Default value 0.05 sec

Pollrate 0.05


# TC redundancy
# Specifies how much neighbor info should
# be sent in TC messages
# Possible values are:
# 0 - only send MPR selectors
# 1 - send MPR selectors and MPRs
# 2 - send all neighbors
#
# defaults to 0

TcRedundancy 2


#
# MPR coverage
# Specifies how many MPRs a node should
# try select to reach every 2 hop neighbor
#
# Can be set to any integer >0
#
# defaults to 1

#MprCoverage 1


# Interfaces and their rules
# Omitted options will be set to the
# default values. Multiple interfaces
# can be specified in the same block
# and multiple blocks can be set.

# !!CHANGE THE INTERFACE LABEL(s) TO MATCH YOUR INTERFACE(s)!!
# (eg. wlan0 or eth1):

Interface "br0"
{

# IPv4 broadcast address to use. The
# one usefull example would be 255.255.255.255
# If not defined the broadcastaddress
# every card is configured with is used

Ip4Broadcast 255.255.255.255

# Emission intervals.
# If not defined, RFC proposed values will
# be used in most cases.

# Hello interval in seconds(float)
HelloInterval 2.0

# HELLO validity time
HelloValidityTime 6.0

# TC interval in seconds(float)
TcInterval 5.0

# TC validity time
TcValidityTime 15.0

# MID interval in seconds(float)
MidInterval 5.0

# MID validity time
MidValidityTime 15.0

# HNA interval in seconds(float)
HnaInterval 5.0

# HNA validity time
HnaValidityTime 15.0

# When multiple links exist between hosts
# the weight of interface is used to determine
# the link to use. Normally the weight is
# automatically calculated by olsrd based
# on the characteristics of the interface,
# but here you can specify a fixed value.
# Olsrd will choose links with the lowest value.

# Weight 0

}


------------------------------------------------------------------------


Casa de primeiro andar a 600mts do primeiro rádio:

Zinwell G120 - APRouter 6.1 - Omni 12dbi

Modo de Operação : Cliente ISP
Wireless : Ad-hoc Cliente
SSID: mesh (o mesmo para todos)
Canal:2 ( O mesmo para todos)
Banda: B
LAN IP : 10.16.0.65 --> Nat dos clientes
WAN IP: 192.16.20.71 --> Esse aqui é o ip dos clientes.

OLSRD.CONF

# cat olsrd.conf
#
# olsr.org OLSR daemon config file
#
# Lines starting with a # are discarded
#
# This file was shipped with olsrd 0.X.X
#

# Debug level(0-9)
# If set to 0 the daemon runs in the background

DebugLevel 0

# IP version to use (4 or 6)

IpVersion 4

# Clear the screen each time the internal state changes

ClearScreen yes

# HNA IPv4 routes
# syntax: netaddr netmask
# Example Internet gateway:
# 0.0.0.0 0.0.0.0

Hna4
{
# Internet gateway:
# 0.0.0.0 0.0.0.0
# more entries can be added:
# 192.168.1.0 255.255.255.0
}

# Should olsrd keep on running even if there are
# no interfaces available? This is a good idea
# for a PCMCIA/USB hotswap environment.
# "yes" OR "no"

AllowNoInt yes

# TOS(type of service) value for
# the IP header of control traffic.
# If not set it will default to 16

#TosValue 16

# The fixed willingness to use(0-7)
# If not set willingness will be calculated
# dynamically based on battery/power status
# if such information is available

#Willingness 4

# Allow processes like the GUI front-end
# to connect to the daemon.

IpcConnect
{
# Determines how many simultaneously
# IPC connections that will be allowed
# Setting this to 0 disables IPC

MaxConnections 0

# By default only 127.0.0.1 is allowed
# to connect. Here allowed hosts can
# be added

Host 127.0.0.1

# You can also specify entire net-ranges
# that are allowed to connect. Multiple
# entries are allowed

#Net 192.168.1.0 255.255.255.0
}

# Whether to use hysteresis or not
# Hysteresis adds more robustness to the
# link sensing but delays neighbor registration.
# Used by default. 'yes' or 'no'

UseHysteresis no

# Hysteresis parameters
# Do not alter these unless you know
# what you are doing!
# Set to auto by default. Allowed
# values are floating point values
# in the interval 0,1
# THR_LOW must always be lower than
# THR_HIGH.

HystScaling 0.50
HystThrHigh 0.80
HystThrLow 0.30


# Link quality level
# 0 = do not use link quality
# 1 = use link quality for MPR selection
# 2 = use link quality for MPR selection and routing
# Defaults to 0

LinkQualityLevel 2

# Link quality window size
# Defaults to 10

LinkQualityWinSize 10

# Polling rate in seconds(float).
# Default value 0.05 sec

Pollrate 0.05


# TC redundancy
# Specifies how much neighbor info should
# be sent in TC messages
# Possible values are:
# 0 - only send MPR selectors
# 1 - send MPR selectors and MPRs
# 2 - send all neighbors
#
# defaults to 0

TcRedundancy 2


#
# MPR coverage
# Specifies how many MPRs a node should
# try select to reach every 2 hop neighbor
#
# Can be set to any integer >0
#
# defaults to 1

#MprCoverage 1


# Interfaces and their rules
# Omitted options will be set to the
# default values. Multiple interfaces
# can be specified in the same block
# and multiple blocks can be set.

# !!CHANGE THE INTERFACE LABEL(s) TO MATCH YOUR INTERFACE(s)!!
# (eg. wlan0 or eth1):

Interface "wlan0" "eth0" "eth1" "br0"
{

# IPv4 broadcast address to use. The
# one usefull example would be 255.255.255.255
# If not defined the broadcastaddress
# every card is configured with is used

Ip4Broadcast 255.255.255.255

# Emission intervals.
# If not defined, RFC proposed values will
# be used in most cases.

# Hello interval in seconds(float)
HelloInterval 2.0

# HELLO validity time
HelloValidityTime 6.0

# TC interval in seconds(float)
TcInterval 5.0

# TC validity time
TcValidityTime 15.0

# MID interval in seconds(float)
MidInterval 5.0

# MID validity time
MidValidityTime 15.0

# HNA interval in seconds(float)
HnaInterval 5.0

# HNA validity time
HnaValidityTime 15.0

# When multiple links exist between hosts
# the weight of interface is used to determine
# the link to use. Normally the weight is
# automatically calculated by olsrd based
# on the characteristics of the interface,
# but here you can specify a fixed value.
# Olsrd will choose links with the lowest value.

# Weight 0

}

Escritório primeiro andar:

Zinwell G120 - APRouter 6.1 - Direcional 24dbi

Modo de Operação : Roteador (WAN Ethernet)
Wireless : Ad-hoc Cliente
SSID: mesh (o mesmo para todos)
Canal:2 ( O mesmo para todos)
Banda: B
LAN IP : 192.16.0.69 --> Esse aqui é o ip dos clientes.
WAN IP: 172.16.0.20 --> Esse o ip que vai para o gateway de Internet

Conteúdo do arquivo olsrd.conf, em /etc/
# cd /etc/
# cat olsrd.conf
#
# olsr.org OLSR daemon config file
#
# Lines starting with a # are discarded
#
# This file was shipped with olsrd 0.X.X
#

# Debug level(0-9)
# If set to 0 the daemon runs in the background

DebugLevel 0

# IP version to use (4 or 6)

IpVersion 4

# Clear the screen each time the internal state changes

ClearScreen yes

# HNA IPv4 routes
# syntax: netaddr netmask
# Example Internet gateway:
# 0.0.0.0 0.0.0.0

Hna4
{
# Internet gateway:
0.0.0.0 0.0.0.0 --> Diz que esse rotedor vai dá acesso para Internet
# more entries can be added:
# 192.168.1.0 255.255.255.0
}

# Should olsrd keep on running even if there are
# no interfaces available? This is a good idea
# for a PCMCIA/USB hotswap environment.
# "yes" OR "no"

AllowNoInt yes

# TOS(type of service) value for
# the IP header of control traffic.
# If not set it will default to 16

#TosValue 16

# The fixed willingness to use(0-7)
# If not set willingness will be calculated
# dynamically based on battery/power status
# if such information is available

#Willingness 4

# Allow processes like the GUI front-end
# to connect to the daemon.

IpcConnect
{
# Determines how many simultaneously
# IPC connections that will be allowed
# Setting this to 0 disables IPC

MaxConnections 0

# By default only 127.0.0.1 is allowed
# to connect. Here allowed hosts can
# be added

Host 127.0.0.1

# You can also specify entire net-ranges
# that are allowed to connect. Multiple
# entries are allowed

#Net 192.168.1.0 255.255.255.0
}

# Whether to use hysteresis or not
# Hysteresis adds more robustness to the
# link sensing but delays neighbor registration.
# Used by default. 'yes' or 'no'

UseHysteresis no

# Hysteresis parameters
# Do not alter these unless you know
# what you are doing!
# Set to auto by default. Allowed
# values are floating point values
# in the interval 0,1
# THR_LOW must always be lower than
# THR_HIGH.

HystScaling 0.50
HystThrHigh 0.80
HystThrLow 0.30


# Link quality level
# 0 = do not use link quality
# 1 = use link quality for MPR selection
# 2 = use link quality for MPR selection and routing
# Defaults to 0

LinkQualityLevel 2

# Link quality window size
# Defaults to 10

LinkQualityWinSize 10

# Polling rate in seconds(float).
# Default value 0.05 sec

Pollrate 0.05


# TC redundancy
# Specifies how much neighbor info should
# be sent in TC messages
# Possible values are:
# 0 - only send MPR selectors
# 1 - send MPR selectors and MPRs
# 2 - send all neighbors
#
# defaults to 0

TcRedundancy 2


#
# MPR coverage
# Specifies how many MPRs a node should
# try select to reach every 2 hop neighbor
#
# Can be set to any integer >0
#
# defaults to 1

#MprCoverage 1


# Interfaces and their rules
# Omitted options will be set to the
# default values. Multiple interfaces
# can be specified in the same block
# and multiple blocks can be set.

# !!CHANGE THE INTERFACE LABEL(s) TO MATCH YOUR INTERFACE(s)!!
# (eg. wlan0 or eth1):

Interface "br0"
{

# IPv4 broadcast address to use. The
# one usefull example would be 255.255.255.255
# If not defined the broadcastaddress
# every card is configured with is used

Ip4Broadcast 255.255.255.255

# Emission intervals.
# If not defined, RFC proposed values will
# be used in most cases.

# Hello interval in seconds(float)
HelloInterval 2.0

# HELLO validity time
HelloValidityTime 6.0

# TC interval in seconds(float)
TcInterval 5.0

# TC validity time
TcValidityTime 15.0

# MID interval in seconds(float)
MidInterval 5.0

# MID validity time
MidValidityTime 15.0

# HNA interval in seconds(float)
HnaInterval 5.0

# HNA validity time
HnaValidityTime 15.0

# When multiple links exist between hosts
# the weight of interface is used to determine
# the link to use. Normally the weight is
# automatically calculated by olsrd based
# on the characteristics of the interface,
# but here you can specify a fixed value.
# Olsrd will choose links with the lowest value.

# Weight 0

}
----------------------------------------------------------------------

O cliente no terceiro ponto navega normalmente, mas o roteador (Zinwell g120) fica trocando as rotas com muita frequência, e não tá estável, e isso impede que aplicações como MSN, SKYPE e qualquer outra que dependa de uma conexão continuada não funcione. Sites navega numa boa, e também gerou muitos problema no meu hotspot, já que cada hora a conexão vem por um caminho diferente, estou analisando para saber o por que dessa situação, estou achando que é a conexão entre as omnis, ele não consegue se estabilizar com nenhuma e fica ssim louquinho.

O cliente conectado no prédio de 9 andare trabalha normalmente, já que le só tem uma opção de rota para Internet.

Estou pensado em comprar uns linksys para testar na mesma situação para ver o que acontece.

Bom, tenho lindo muito sobre o OLSR que é o protocolo que vem sendo mais usado até agora, e analisando as informações para saber o que fazer para tornar isso estável. Quem quer montar sua MESH tem que ler um pouqinho sobre esses protocolos.

Vou continuar meus teste aqui, e postar os resultados para que alguém tente me ajudar e somar nos conhecimentos.

Até breve.

Seven,

redes mesh com OLSR tem desvantagens:

- O olsr cria um overhead de 256 kbit/s em cada enlace
- O olsr troca entre si apenas as rotas para os hosts que rodan OlSR, ou seja, se o cliente não rodar uma instancia OLsR, ele não será conhecido na rede.

A solução é ativar NAT nos pontos com OLSR que atendem os clientes, assim os pacotes
navegarão pela nuvem mesh até os pontos conhecidos. A desvantagem é que se perde o gerenciamento de clientes. Atendendo com hotspot por ponto ou pppoe por ponto, voce poderá gerenciar usuários sem que o NAT não te prejudique.

Citação:

---

Postado originalmente por PatrickBrandao

Seven,

redes mesh com OLSR tem desvantagens:

- O olsr cria um overhead de 256 kbit/s em cada enlace
- O olsr troca entre si apenas as rotas para os hosts que rodan OlSR, ou seja, se o cliente não rodar uma instancia OLsR, ele não será conhecido na rede.

A solução é ativar NAT nos pontos com OLSR que atendem os clientes, assim os pacotes
navegarão pela nuvem mesh até os pontos conhecidos. A desvantagem é que se perde o gerenciamento de clientes. Atendendo com hotspot por ponto ou pppoe por ponto, voce poderá gerenciar usuários sem que o NAT não te prejudique.

---

Olá Patrick...
Qual a melhor forma de criar uma rede mesh?
Abs

Recomendo OSPF

Voce configura uma interface para atender o cliente com uma rede fixa, recomendo basear essa rede no MAC da placa do ponto de acesso para facilitar o gerenciamento.

Ex.:

MAc eth1: 00:01:0c:ab:a0:bb
Ip eth0: 10.160 (a0). 187.1 /24, clientes de 10 a 254 (dhcp ou nao).

Assim, voce distribui o numero maximo de pontos de acesso com a eth1 para atender os clientes e a eth0 para se conectar em uma rede wireless celular. O OSPF vai fazer com que as rotas sejam inteligentes e redundantes.

Redes mesh em bridge é furada, fuga disso.

Desculpa por ter postado no lugar errado!! Quem quiser ver os resultados vá na categoria MESH!!

Eu não tinha vista que já existia!

Citação:

---

Postado originalmente por PatrickBrandao

Recomendo OSPF

Voce configura uma interface para atender o cliente com uma rede fixa, recomendo basear essa rede no MAC da placa do ponto de acesso para facilitar o gerenciamento.

Ex.:

MAc eth1: 00:01:0c:ab:a0:bb
Ip eth0: 10.160 (a0). 187.1 /24, clientes de 10 a 254 (dhcp ou nao).

Assim, voce distribui o numero maximo de pontos de acesso com a eth1 para atender os clientes e a eth0 para se conectar em uma rede wireless celular. O OSPF vai fazer com que as rotas sejam inteligentes e redundantes.

Redes mesh em bridge é furada, fuga disso.

---

Certo amigo...
Outra coisa.. o seu sistema só trabalha com pppoe? tem modulo para emissao de boleto?
Abs

O MyAuth trabalha originalmente com hotspot, mas tem tambem servidor pppoe.

Ainda não temos software financeiro....

Vc pretende desenvolver a parte financeira tbm? se sim... vai disponibilizar pra quem for seu cliente? qual vai ser o custo adicional?
Outra coisa... eu utilizo um unico pc com mkt em cima da torre e 4 setoriais... controlo tudo por ele... uso apenas ip amarrado ao mac...
Pra usar o seu sistema eu teria q mudar para hotspot?
De que forma eu poderia estar integrando o seu sistema ao meu sistema atual? (apenas mkt)
E por fim.. Quais as vantagens de utilizar o seu sistema?
Achei o sistema muito interessante e se puder me esclarecer essas duvidas quem sabe em breve podemos fazer negocio... rsrs..
Abraços

Sim pretendo, mas isso é uma jornada pois nunca fiz nenhum sistema financeiro antes, terei que fazer e testar em produçao exaustivamente antes de vender.

O MyAuth usa autenticaçao hotspot mas voce pode permitir fixamente por ip e mac sem precisar exigir autenticaçao para os clientes.

O MyAuth controla banda e faz o controle de usuários de forma gerencial,o MK faz isso de forma técnica, voce fazer 2 controles iguais na mesma rede nao tem sentido, logo, voce pode conserver os recursos avançados de AP e outros do MK e usar o MyAuth para administrar os usuários.

Se tiver mais dúvidas é so mandar!

Citação:

---

Postado originalmente por PatrickBrandao

Sim pretendo, mas isso é uma jornada pois nunca fiz nenhum sistema financeiro antes, terei que fazer e testar em produçao exaustivamente antes de vender.

O MyAuth usa autenticaçao hotspot mas voce pode permitir fixamente por ip e mac sem precisar exigir autenticaçao para os clientes.

O MyAuth controla banda e faz o controle de usuários de forma gerencial,o MK faz isso de forma técnica, voce fazer 2 controles iguais na mesma rede nao tem sentido, logo, voce pode conserver os recursos avançados de AP e outros do MK e usar o MyAuth para administrar os usuários.

Se tiver mais dúvidas é so mandar!

---

Entao eu usaria um servidor central com myauth e no meu pop faria bridge mandando tudo pro myauth controlar (usuario, autenticação, banda)??
E no caso de eu adicionar mais um pop?
Como deveria ficar minha estrutura com dois pop's e o myauth?
Abs

Esse tópica é sobre MESH o publicidade do MYAUTH?