[PROBLEMA] Omnitik não envia mais de 10MB apos raio.

[ubntReparos]

Séra então que o chip esta afetado? Fiquei tão irritado hoje depois de estar em 5200 e todos ccqs 90/90 de não conseguir passar mais de 10mb que fiz um ponto a ponto pra minha casa e deixei os meus tios na Omni, aqui em casa agora ta puxando tudo mas a praga da Omnitik continua com troughput preso de 10mb, este chip e trocavel?

Como te disse, em equipamentos Ubiquiti que utilizam esse mesmo chip esse problema é muito comum.

Faço reparos em Equipamentos Ubiquiti aqui em Goiás, (não tenho costume de reparar Mikrotik), mas por acaso em um lote de equipamentos UBNT que comprei vieram 2 OMINITIK com esse mesmo problema, troquei o chipset AR7241 e agora esta funcionando normalmente.

Então, "sim" ele é "trocavel".

Em reparos de equipamentos UBNT cobro R$ 70,00, mas como não sei de onde vc é, náo sei te dizer quanto vc vai gastar, mas com certeza esse reparo não pode custar mais que R$ 100,00.

[rubem]

Se tem certeza que não tem loop na rede (Uma bridge conectada via cabo e via wifi, digamos), também voto em pau no chipset ou no firmware.

Se enviar novo firmware não ajudou (1 em cada 100 vezes ajuda), pau no chipset.

[1929]

@rubem , só para ampliar a discussão, o que você me diz da leitura do Noise Floor bem baixo em todos os canais? Dá para confiar nestas leituras?

[rubem]

Aqui na roça escaneio muito ruído a -116dBm também, provavelmente porque não tem ruído mesmo.

Nas fazendas é bem como a imagem, ruído perto da sensibilidade do aparelho, porque simplesmente não tem ruído em nenhum canal. Na cidade até tem (Especialmente 5180, que é o default de MK antigo e muito usuário tonto deixa no default, só nesse canal em casa escaneio meia duzia de SSID, enquanto digamos em 5835 não tem ninguém).

Se não tem ruído, o software vai tratar como ruído aquilo que ele não consegue decifrar, que não consegue definir se é um pacote IEE 802.11x. Se tiver apenas pacotes de outros provedores, em padrão wifi 802.11, ele não deve mesmo exibir como ruído porque isso é "Uso do canal" e não "Ruído".

Se não tem ruído, o que o rádio não "entende" é o que está muito perto do limiar inferior da sensibilidade.

Eu notava muito isso em 2,4GHz mesmo, um roteador barato mostrava ruído em -88dBm, um Bullet da vida mostrava em -96dBm, e um cartão mini-pcie numa RB mostrava em -110dBm. Pra mim só ficou claro o motivo quando olhei nos datasheets qual a sensibilidade mínima do aparelho.

No caso de MK, a sensibilidade mínima no datasheet não é tão baixa, mas... eles dão os valores com canal de 20MHz. Pra usar o MESMO data rate em 20 e 40MHz de largura precisamos aumentar o nível de sinal (Senão o CCQ diminui), ou seja, canal mais largo tem sensibilidade pior. E MK permite canais de 10MHz ou mesmo 5MHz. Se em 20MHz a sensibilidade em MCS0 é de -96dBm, não duvido que em 10MHz ela seja de -106dBm, e em 5MHz de -116dBm, no caso de SXT acho que é por aí, porque com 5MHz de largura dá pra ter CCQ de 100% em MCS0 com sinal de -94dBm!

Alias, também é bom notar que isso na verdade não é a expressão de CADA ruído, é o noise floor, é a média dos ruídos. Pode ter uma ou outra micro-rajada de dados ilegíveis, mas ser tão rápida que não aparece no canal.

Outra coisa, eu sei que a etapa de RF tem filtros focados em 5,8GHz mesmo (Mais um motivo pra eu chamar de burrice o uso de 5,1-5,3GHz), faz todo sentido essa imagem, com o menor ruído sendo medido em 5,8GHz, essa é a faixa onde é permitido maior potência (Não só no brasil, pelo que vi na maior parte do mundo é assim) então é ideal pra uso outdoor, é a frequencia onde a antena terá quase sempre o menos VSWR (A MK não diz o VSWR por frequencia na Omnitik, mas quase toda antena recente que tem isso na ficha técnica tem o menos VSWR na casa dos 5,6-5,9GHz, VSWR menor implica menos retorno pela antena, logo, vai ter mesmo um noise floor num nível menor).

Tudo que analiso me faz crer que a imagem está correta, que o chipset de RF está muito bem.


(Se aumentar potência, ou posicionar a Omnitik do lado de algo, talvez ela escaneie um noise floor maior, mas aí seria ruído criado por ela mesma, e presente só naquele palmo quadrado que ela ocupa)

E a parte de ethernet fica em OUTRO lugar, são componentes diferentes, estão em chipsets diferentes, tem todo potencial pra queimar ethernet mas a parte de RF continuar operando perfeita.

Alias, tenho RB433 assim, com o switch IP175 queimado, mas como estava como AP, com IP configurado, acessando via wifi posso configurar outro cartão e usar como repetição ou coisa assim, só testei o throughput com um cartão como AP e outro como cliente e foi normal, tá guardado pra uso futuro (Porque duvido que o dolar volte a um preço bom, e que a Receita volte ao normal, pra eu poder importar componentes de novo antes de 2020, tenho uma duzia de coisas guardadas pra quando puder comprar componentes pra reparo, já me conformei com o futuro próximo, usar o que tem, porque importar peça não dá, e algumas coisas não acho no brasil).

[1929]

Sim, explicação perfeita.... mas eu fico com uma dúvida.

Se o sinal é alto com uma leitura de noise destas, o SNR vai ser alto o que é muito desejável para uma boa conexão.

Tem um vídeo da Computech onde eles comentam sobre ambientes de exposição por exemplo, com dezenas e dezenas de redes instaladas por cada expositor. E todos convivem dentro deste ambiente que aparentemente é altamente poluído.
Segundo eles, o que importa não é o número de SSIDs no local, mas sim o SNR que os usuários do AP chegam ao AP. Que o firmware está preparado para escutar todos os SSID e separar o que está configurado nele.

Neste caso postado por exemplo o canal citado está com uma porcentagem alta de ocupação, mas o Noise Floor é praticamente o mesmo.
Isto me deixou confuso com relação a informação que a leitura nos dá. Que vantagem tem de estar lá listado o Noise, se na prática só damos importância a porcentagem de ocupação?
Não estou me opondo, pois também escolho pela porcentagem de ocupação.
Mas tenho uma desconfiança de que um canal deveria ser descartado o uso no caso de uma alta taxa de ocupação aliado a um Noise Floor baixo.

[renanssj5]

Se tem certeza que não tem loop na rede (Uma bridge conectada via cabo e via wifi, digamos), também voto em pau no chipset ou no firmware.

Se enviar novo firmware não ajudou (1 em cada 100 vezes ajuda), pau no chipset.

Ruben existe uma bridge direta, tem um sxt enviando ponto a ponto para outro, o sxt que esta no ponto principal está na classe 88.6, a omni e 88.1, o sxt que recebe setei la no quick set dele bridge e tinha conectado e funcionado na hora pegando a classe 5.1 que e a minha rede interna, ao verificar o ip dele aparece que esta na mesma da omni 88.1 mas aparece desabilitado ja que em bridge o sxt que recebe assimilou o ip da rede interna, será que esta influenciando?

[rubem]

Sim, explicação perfeita.... mas eu fico com uma dúvida.

Se o sinal é alto com uma leitura de noise destas, o SNR vai ser alto o que é muito desejável para uma boa conexão.

Tem um vídeo da Computech onde eles comentam sobre ambientes de exposição por exemplo, com dezenas e dezenas de redes instaladas por cada expositor. E todos convivem dentro deste ambiente que aparentemente é altamente poluído.
Segundo eles, o que importa não é o número de SSIDs no local, mas sim o SNR que os usuários do AP chegam ao AP. Que o firmware está preparado para escutar todos os SSID e separar o que está configurado nele.

Neste caso postado por exemplo o canal citado está com uma porcentagem alta de ocupação, mas o Noise Floor é praticamente o mesmo.
Isto me deixou confuso com relação a informação que a leitura nos dá. Que vantagem tem de estar lá listado o Noise, se na prática só damos importância a porcentagem de ocupação?
Não estou me opondo, pois também escolho pela porcentagem de ocupação.
Mas tenho uma desconfiança de que um canal deveria ser descartado o uso no caso de uma alta taxa de ocupação aliado a um Noise Floor baixo.

Pelo que sempre testo, aí entra a sensibilidade.
Se seto pra MCS15, com sensibilidade em -75dBm, e o sinal que quero está em -55dBm, terei CCQ de 100%, e podem ter meia duzia de SSID's lá pelos -80 a -76dBm que não vai atrapalhar.

Uma coisa é o pacote pequeno e em datarate baixo que leva o SSID, esse pacote é emitido na potência máxima setada, e é lido até quando está na sensibilidade mínima usável (Uns -95 a -100dBm, dependendo do aparelho).

Já o pacote de dados do cliente, esse vai no esquema de modulação que você setou, é um pacote maior e num datarate maior. Digamos que está usando MCS15, o SSID é emitido em BPSK (Legível até em -95dBm), mas o MCS15 está em 64QAM, legível só bem acima de -75dBm.

O Airview nos UBNT mais recentes mostra no gráfico a ocupação por "hits", apenas enviar SSID dá poucos hits, é um canal usado mas pouquíssimo usado, gera um gráfico bem esparso comparado a um canal onde está tendo mesmo troca de dados do usuário.

Também é bom cuidar que cliente de AP, mesmo sem tráfego, gera uns pontos altos e esparsos no Airview, são os dados de sincronia trocados a cada X segundos pra ver se o cliente e AP ainda estão presentes (Um pergunta pro outro "Ainda tá aí?"), você pode estar de costas pro AP, escanear o canal como relativamente vazio, mas em meia hora esse cliente começa a navegar, mandar dados de usuário, aí o canal fica bem ocupado, seja lá qual data rate ele usar vai ocupar todo o canal massivamente, depende mais do numero de pacotes usado.


Assim como tem um SNR mínimo a se respeitar, pra garantir a legibilidade do pacote de dados, se aplicar essa margem nos sinais alheios acho que tem como ter CCQ ótimo.

Nunca tirei tempo de tentar coisa tipo conseguir -40dBm num canal onde tem sinal alheio chegando em -60dBm, provavelmente não vai prestar porque -60dBm ainda é muito legível, mas onde tem sinal alheio a -76dBm, se o SEU sinal está em -55dbm o CCQ vai ficar no máximo.

Eu não confiava tanto no Channel usage do Mikrotik porque ele parece que tinha me enganado umas vezes, mas quando tive um Airview de UBNT em mãos pude notar, o que as vezes está com uso baixo é na verdade um cliente que está sem tráfego, e o pouco uso do canal é apenas a troca de pacotes de sincronia (E sabe que tem cliente que fica com CPE ligada 24h mas que trafega dados realmente só 3h por dia, nessas 3h ele te atrapalhará, se usar esse canal.

Aqui um exemplo, 2 extremos, o scan de SSID vai mostrar os 2 canais com SSID na casa dos -60dBm, mas... em 5400MHz aparentemente é um cliente, tem dados esparsos, no waterfall view tem rajadas amarelas, mas isso é nível de sinal, se for uma rajada a -60dBm por MINUTO atrapalha pouco, pra isso ele mostra em baixo o numero de hits, que é bem baixo, aparentemente são MENOS de 20 hits em 5 minutos! Isso não é nem o ping do Windows verificando se tem internet, isso é realmente só a CPE trocando dados com o AP pra verificar status:


Isso quer dizer que posso usar 5400MHz no meu PTP?
Agora pode.
Mas e daqui 2 horas, quando o cliente chegar em casa e começar a navega? Aí vai ficar como o outro extremo em 5800MHz, canal cheio de uso, mas sem aumentar o nível do SSDI.

Agora provavelmente terá CCQ de 100%, mas quando esse cliente navegar, e competir pela ocupação do canal, o CCQ cai pra 80 ou 90% e o provedor fica louco.

Não que o channel usage do MK não funcione, é que ele é igual o Airview, ele mostra o uso AGORA. E o scan de SSID não mostra as respostas de clientes, se você estiver de costas pro AP, com um cliente de frente pra você, hora que esse cliente começar a trafegar ele vai atrapalhar muito, se essa CPE estiver ligada pelo menos o Airview te permite descobrir isso, mas em MK não tem nada.
(E também nem toda CPE fica ligada 24x7, tem gente que desliga tudo umas 16h por dia, ainda pode ter CCQ ruim nalguns horários)

Se aplicar a regra do SNR aos sinais alheios, de quase 35dBm de distância se usar datarate alto, talvez dê pra viver com sinal alheio de -70dBm, duvido um pouco, o que já testei é com sinal abaixo da sensibilidade do data rate e foi ok, atrapalho zero.

[rubem]

Ruben existe uma bridge direta, tem um sxt enviando ponto a ponto para outro, o sxt que esta no ponto principal está na classe 88.6, a omni e 88.1, o sxt que recebe setei la no quick set dele bridge e tinha conectado e funcionado na hora pegando a classe 5.1 que e a minha rede interna, ao verificar o ip dele aparece que esta na mesma da omni 88.1 mas aparece desabilitado ja que em bridge o sxt que recebe assimilou o ip da rede interna, será que esta influenciando?

Se está em bridge, tanto faz o IP, ela passa tudo quanto é dado porque se baseia no mac adress, pode ser ip local ou real que uma bridge passa.

E a questão de pegar só 10M numa porta também não afeta isso, antes de acionar o DHCP a porta faz algumas trocas de dados pra estabelecer comunicação, se em 100M ela não consegue, parte pra 10M, e só depois de uma duzia de pacotes trocados sem erro é que o DHCP client faz a requisição pro DHCP server.

E dá um ping rumo ao IP local da Omnitik, porque além da porta estar em 10M, pode ter perda de pacote. Mas ping com pacote grande.
O normal seria
ping -t 192.168.88.1
Pra usar um ping com pacote grande, igual o tamanho dos pacotes de dados (Limitados pelo MTU), acrescente a variável -l de large, e o tamanho do pacote em bytes
O ping normal é com 32 bytes, ele equivale a
ping -t 192.168.88.1 -l 32
Mas pra ver se não tem perda de pacotes REAIS, perto do limite do MTU, testa
ping -t 192.168.88.1 -l 1400
ping -t 192.168.88.1 -l 1450
ping -t 192.168.88.1 -l 1470

O máximo que poderia acontecer via cabo é o ping normal ficar em 1 ou 2ms, e o ping com pacote grande subir pra 2 a 4ms.
Se, via cabo, o ping com pacote de 1400 bytesm der algo tipo 10ms, e perder 1 a cada 10 pings (É o que geralmente vejo com rádio que fica em 10M depois de tempestade), isso é uma perda de 10% dos pacotes, a navegação fica sofrida.

E mesmo que já tenha trocado a porta, pra uma que aceita 100M, dá o ping igual, porque se o chipset foi afetado ele vai perder pings ou dar tempos enormes também nas outras portas. Em CI de switch isso é comum, queima só 1 porta mas as outras são um pouco afetadas, perdem alguns pacotes grandes.

(E navegação usa pacotes grandes, não pequenos, mesmo o status do WhatsApp usa pacotes de uns 500B pra cima, até isso (Que gera tráfego tipo 1 ou 2kbps) é afetado)

[renanssj5]

Se está em bridge, tanto faz o IP, ela passa tudo quanto é dado porque se baseia no mac adress, pode ser ip local ou real que uma bridge passa.

E a questão de pegar só 10M numa porta também não afeta isso, antes de acionar o DHCP a porta faz algumas trocas de dados pra estabelecer comunicação, se em 100M ela não consegue, parte pra 10M, e só depois de uma duzia de pacotes trocados sem erro é que o DHCP client faz a requisição pro DHCP server.

E dá um ping rumo ao IP local da Omnitik, porque além da porta estar em 10M, pode ter perda de pacote. Mas ping com pacote grande.
O normal seria
ping -t 192.168.88.1
Pra usar um ping com pacote grande, igual o tamanho dos pacotes de dados (Limitados pelo MTU), acrescente a variável -l de large, e o tamanho do pacote em bytes
O ping normal é com 32 bytes, ele equivale a
ping -t 192.168.88.1 -l 32
Mas pra ver se não tem perda de pacotes REAIS, perto do limite do MTU, testa
ping -t 192.168.88.1 -l 1400
ping -t 192.168.88.1 -l 1450
ping -t 192.168.88.1 -l 1470

O máximo que poderia acontecer via cabo é o ping normal ficar em 1 ou 2ms, e o ping com pacote grande subir pra 2 a 4ms.
Se, via cabo, o ping com pacote de 1400 bytesm der algo tipo 10ms, e perder 1 a cada 10 pings (É o que geralmente vejo com rádio que fica em 10M depois de tempestade), isso é uma perda de 10% dos pacotes, a navegação fica sofrida.

E mesmo que já tenha trocado a porta, pra uma que aceita 100M, dá o ping igual, porque se o chipset foi afetado ele vai perder pings ou dar tempos enormes também nas outras portas. Em CI de switch isso é comum, queima só 1 porta mas as outras são um pouco afetadas, perdem alguns pacotes grandes.

(E navegação usa pacotes grandes, não pequenos, mesmo o status do WhatsApp usa pacotes de uns 500B pra cima, até isso (Que gera tráfego tipo 1 ou 2kbps) é afetado)

Obrigado pela grande aula vc e um mestre, segunda testarei o seu tutorial mas a porta esta a 100mbs, isso tenho certeza, pode e claro estar afetada por causa da ether 1 que esta em loop mas está desabilitada, mas como vc falou uma pode influenciar a outra.






Dei uma corrida ali e fiz o teste, não perdeu pacotes via Ethernet nem com 1470, estou usando aqui na minha casa um ponto a ponto e nele está tudo ok, o balanceador de carga tp link tb estragou uma das saídas a porta 5, pensei que ele poderia estar ruim tb mas no local ele opera mandando os 30mb da adsl e aqui em casa no ponto a ponto tb esta passando toda a banda, fiz um bandwitch test para um ilimitado e vejam so, ela ta travada em 10mb mesmo via wireless, ta mostrando 13.5 em interfaces mas e meio fake, o real ta dentro do quadro de teste, esse chip so pode ter sido condenado.

[rubem]

Hum, mas você fez o teste rumo a um IP que está conectado via wifi também nesse datarate de 26M?

Se for, é normal o throughput ficar nesses 12,5Mbps, até 14Mbps também. Mas o teste de banda vai ficar abaixo depois do trabalho de trocar pacotes e tal, 8,4 Mbps acho pouco mas toda vez que vi limite na porta o limite era realmente uns 10Mbps (Se você limitar manualmente a 10M num equipamento bom, de PC a PC é fácil ver troca de dados a 1,2MB/s, que dá quase 10Mbps mesmo).

Se o teste foi feito com tráfego pela porta ethernet (Com um cabo de rede entre os equipamentos 192.168.5.101 e o equipamento 10.1.1.99), então realmente a ethernet ainda tem problema mesmo.

(Mas pelo que entendi o teste passa por wifi com data rate de 26M, que vai trafegar 13 ou 14Mbps só em condições boas. O datarate de 19M (MCS2) trafega 10M só em PTP, mas em PTMP até um MCS4 (39M) é capaz de sofrer pra passar de 10Mbps estável, porque os outros clientes podem estar com trafego (Mesmo só conectados, existe troca de pacotes de sincronia, a etapa de RF trabalha mesmo que a interface não apresente tráfego pro IP do cliente, lá aparece o tráfego de pacotes do usuário, não o trafego de dados de sincronia e status))

[renanssj5]

Hum, mas você fez o teste rumo a um IP que está conectado via wifi também nesse datarate de 26M?

Se for, é normal o throughput ficar nesses 12,5Mbps, até 14Mbps também. Mas o teste de banda vai ficar abaixo depois do trabalho de trocar pacotes e tal, 8,4 Mbps acho pouco mas toda vez que vi limite na porta o limite era realmente uns 10Mbps (Se você limitar manualmente a 10M num equipamento bom, de PC a PC é fácil ver troca de dados a 1,2MB/s, que dá quase 10Mbps mesmo).

Se o teste foi feito com tráfego pela porta ethernet (Com um cabo de rede entre os equipamentos 192.168.5.101 e o equipamento 10.1.1.99), então realmente a ethernet ainda tem problema mesmo.

(Mas pelo que entendi o teste passa por wifi com data rate de 26M, que vai trafegar 13 ou 14Mbps só em condições boas. O datarate de 19M (MCS2) trafega 10M só em PTP, mas em PTMP até um MCS4 (39M) é capaz de sofrer pra passar de 10Mbps estável, porque os outros clientes podem estar com trafego (Mesmo só conectados, existe troca de pacotes de sincronia, a etapa de RF trabalha mesmo que a interface não apresente tráfego pro IP do cliente, lá aparece o tráfego de pacotes do usuário, não o trafego de dados de sincronia e status))

O teste foi efetuado para um cliente ppoe ilimitado conectado por wifi, mas para matar de vez a questão da porta lan fiz o seguinte agora, mandei um bandwitch teste para o sxt que recebe no ponto a ponto aqui em casa, então ela usou a lan para mandar, passou 25 mb pois estou em mcs 4, o máximo, então a porta lan esta tráfegando dados normalmente, da pra ficar louco.

[renanssj5]

O teste foi efetuado para um cliente ppoe ilimitado conectado por wifi, mas para matar de vez a questão da porta lan fiz o seguinte agora, mandei um bandwitch teste para o sxt que recebe no ponto a ponto aqui em casa, então ela usou a lan para mandar, passou 25 mb pois estou em mcs 4, o máximo, então a porta lan esta tráfegando dados normalmente, da pra ficar louco.

Acho que para fazer um teste para saber se o problema e o número de clientes conectados vale a pena, como vc disse que o radio so de esta logado ocasiona troca de pacotes como eu posso estar bloqueando todos e deixando apenas uma pessoa para testar? Com isso eu poderia filtrar os problemas e liberando um a um e testando, o que eu fiz foi desabilitar o pppoe em outros testes e deixando só um conectado mas vejo que foi inutil então desta maneira.

[rubem]

É que o PPPoE ainda permite a troca de pacote na parte de RF, ele impede a autenticação no gateway mas não impede a troca de dados via RF.

Tipo a entrada do metrô, se tiver muita gente atrás da catraca tudo será lento, mesmo que a catraca impeça a passagem de quem não tem cartão/passagem esse pessoal pode chegar até ela.

A catraca é o PPPoE server, processada no chipset principal via software, e a porta de entrada da estação de metrô é o chipset de RF.

Então teria que criar um VirtualAP com autenticação, conectar nele, e desabilitar temporariamente a wlan principal.

Algo tipo


(Ou mudar alguma coisa a mais, tipo trocar a criptografia, ou COLOCAR criptografia, mas a princípio mantendo o SSID e MAC uns clientes vão fazer tentativa de conexão, não tenho certeza o quanto pesa pro chipset enviar um "Senha errada" pra cada cliente que tenta conexão se apenas mudar a criptografia)

[renanssj5]

É que o PPPoE ainda permite a troca de pacote na parte de RF, ele impede a autenticação no gateway mas não impede a troca de dados via RF.

Tipo a entrada do metrô, se tiver muita gente atrás da catraca tudo será lento, mesmo que a catraca impeça a passagem de quem não tem cartão/passagem esse pessoal pode chegar até ela.

A catraca é o PPPoE server, processada no chipset principal via software, e a porta de entrada da estação de metrô é o chipset de RF.

Então teria que criar um VirtualAP com autenticação, conectar nele, e desabilitar temporariamente a wlan principal.

Algo tipo


(Ou mudar alguma coisa a mais, tipo trocar a criptografia, ou COLOCAR criptografia, mas a princípio mantendo o SSID e MAC uns clientes vão fazer tentativa de conexão, não tenho certeza o quanto pesa pro chipset enviar um "Senha errada" pra cada cliente que tenta conexão se apenas mudar a criptografia)

Uso wpa2 e quando to configurando o sxt eu sempre faço scan primeiro e conecto, mesmo não colocando o perfil de segurança wpa aparece registrado ja dentro da Omni, acho que deve ter algo que bloqueia macs de conectar não tem não?

[renanssj5]

Uso wpa2 e quando to configurando o sxt eu sempre faço scan primeiro e conecto, mesmo não colocando o perfil de segurança wpa aparece registrado ja dentro da Omni, acho que deve ter algo que bloqueia macs de conectar não tem não?

Ja sei vou alterar o ssid e mudar ele tb em um so local.

[renanssj5]

Fiz mais alguns testes conclusivos aqui, fiz um teste dando saida pela LAN dela para um sxt ponto a ponto que resultou em 30MB, fiz um com entrada pela LAN dela que resultou nos malditos 10MBS então o problema e esse com certeza, a LAN não esta entrando mais de 10mb mas dando saída ta ok, sem condições, que problema mais enjoado do planeta, estou desconfiado de loop agora pq não existe a porta passar mais MB dando saida e não conseguir dando entrada a mesma quantidade.

[1929]

Pelo que sempre testo, aí entra a sensibilidade.
Se seto pra MCS15, com sensibilidade em -75dBm, e o sinal que quero está em -55dBm, terei CCQ de 100%, e podem ter meia duzia de SSID's lá pelos -80 a -76dBm que não vai atrapalhar.

Novamente é perfeita tua explicação... Nós procuramos aqui fazer o melhor na conexão, mas tem casos que não resolve mesmo. Fica bom em alguns horários e em outros não... E não adianta ficar trocando de canais. Afinal, estamos em ambiente compartilhado.
O melhor é cuidar da nossa "fazendinha" sem se preocupar muito com a do vizinho.
Como você disse, naquele momento o canal está com alta ocupação, em outro momento isso vai mudar... e para complicar, o rastreamento mostra todos os canais com Noise muito baixo, até aquele que teoricamente teria que ser condenado.. Pouco nos ajuda na tomada de decisões.

O negócio é instalar com o objetivo de manter um nível alto de sinal e deixar rolar...
O que temos procurado fazer é dar um Scan e escolher canais que apareçam menos SSID com sinal alto para aquele painel. Não esquento muito com o rastreio de ocupação.

[renanssj5]

Mais uma prova de que a porta ether 1 mesmo desligada esta influenciando em outras, vejam na imagem o log, todas portas estavam disable menos a Ether 5, loguei habilitei a Ether1 ela derruba a ether 5 em seguida a conexão e restaurada, logo em seguida a porta ether 1 assimila uma conexão de 10mb SÓ QUE ELA NÃO ESTA CONECTADA A NADA!! Depois disso a omni fica louca e começa a derrubar os clientes PPPOE,desligo a Ether 1 tudo volta ao normal mas a entrada na porta Ether 5 não passa de 10mb, solução seria apenas a troca da Omni???

[rubem]

O reparo seria só a troca do chipset. Marquei ele aqui:


A omnitik com POE talvez seja um pouco diferente por dentro, mas é o chipset Atheros. É o chipset principal. Os outros CI's grandes são a memóra Ram, a memória Rom ou a memória flash, e debaixo da latinha que de blindagem tem o chipset de RF, que controla só a parte de RF, entrada e saída de dados pelas antenas, mas isso também pode ter sido afetado NESSE CASO porque as portas ethernet vão direto pro chipset principal. Se fosse RB com um switch, o switch poderia queimar (Ou mesmo ser removido!) que a parte de RF continuaria. É tipo uma placa-mãe ATX, você pode colocar 2 placas de rede ethernet e 2 placas wifi, se as placas ethernet queimarem o resto do PC, incluindo a parte de wifi, continuam funcionando. Só que a Omnitik tem tudo integrado, a placa de rede é soldada no processador, se queima a rede tem que trocar o processador.


Se abrir ela, pode ver que as trilhas de cada porta ethernet vão direto pro chipset, não há um switch entre o chipset e as portas ethernet.

Mas se tivesse um CI de switch, esse CI é que queimaria, teria que trocar um CI igual. Se pegar a RB493 como exemplo, ela tem um switch no meio do caminho, é esse CI escrito IC+ bem no meio, acima das 8 portas ethernet:

Chama switch porque é um switch mesmo, um switch layer 2, é igualzinho os CI's de alguns switch de 8 portas a venda, o mesmo componente.

Ou queima o switch, ou o chipset.


Se você aterrar a Omnitik, a proteção interna dela atua, ele tem uns circuitos de proteção mínima que jogam as descargas pro aterramentos (São os componentes entre o chipset e aquela barra longa e preta atrás dos conectores (Aquilo é um transformador, ele isola os dados no cabo, justo pra evitar queima. Se não houvesse ele, seria como usar cabo coaxial pra ligar computadores, se passar de 15m de cabo e chover, é CERTEZA de queima da porta serial)). Uma mísera haste de 2,4m, de 5/8 de polegada, deve estar uns R$ 30 a 35 no comércio, é só subir um cabo UTP-08 blindado ligado nessa haste, ou subir um cabo qualquer (Até de 1,5mm serve) e ligar num RJ-45 blindado plugado nalguma porta, que a RB estará aterrada. Não é a proteção perfeita mais agora vai gastar uns R$ 70 a 140 pra troca do chipset, convenhamos que um aterramento mínimo de R$ 50 ou 70 (Que evita muitas queimas, não só 1) não é caro.

Se não dá mesmo pra usar como está (Se dá erros até com eth1 desabilitada) o jeito é mandar pra reparo (Não sei indicar nenhum, procura no forum por reparo de mikrotik que achará muitos nomes). Se trocarem certinho, fica como nova, mas pra não repetir o problema seria bom pelo menos um aterramento mínimo. Se quiser colocar um protetor de surto (Protetor de ethernet), fique a vontade, mas esses protetores só atuam com aterramento igual, então aterramento você vai precisar de qualquer jeito, as descargas tem que ir pra algum lugar, sem aterramento elas não tem pra onde ir.

[renanssj5]

O reparo seria só a troca do chipset. Marquei ele aqui:


A omnitik com POE talvez seja um pouco diferente por dentro, mas é o chipset Atheros. É o chipset principal. Os outros CI's grandes são a memóra Ram, a memória Rom ou a memória flash, e debaixo da latinha que de blindagem tem o chipset de RF, que controla só a parte de RF, entrada e saída de dados pelas antenas, mas isso também pode ter sido afetado NESSE CASO porque as portas ethernet vão direto pro chipset principal. Se fosse RB com um switch, o switch poderia queimar (Ou mesmo ser removido!) que a parte de RF continuaria. É tipo uma placa-mãe ATX, você pode colocar 2 placas de rede ethernet e 2 placas wifi, se as placas ethernet queimarem o resto do PC, incluindo a parte de wifi, continuam funcionando. Só que a Omnitik tem tudo integrado, a placa de rede é soldada no processador, se queima a rede tem que trocar o processador.


Se abrir ela, pode ver que as trilhas de cada porta ethernet vão direto pro chipset, não há um switch entre o chipset e as portas ethernet.

Mas se tivesse um CI de switch, esse CI é que queimaria, teria que trocar um CI igual. Se pegar a RB493 como exemplo, ela tem um switch no meio do caminho, é esse CI escrito IC+ bem no meio, acima das 8 portas ethernet:

Chama switch porque é um switch mesmo, um switch layer 2, é igualzinho os CI's de alguns switch de 8 portas a venda, o mesmo componente.

Ou queima o switch, ou o chipset.


Se você aterrar a Omnitik, a proteção interna dela atua, ele tem uns circuitos de proteção mínima que jogam as descargas pro aterramentos (São os componentes entre o chipset e aquela barra longa e preta atrás dos conectores (Aquilo é um transformador, ele isola os dados no cabo, justo pra evitar queima. Se não houvesse ele, seria como usar cabo coaxial pra ligar computadores, se passar de 15m de cabo e chover, é CERTEZA de queima da porta serial)). Uma mísera haste de 2,4m, de 5/8 de polegada, deve estar uns R$ 30 a 35 no comércio, é só subir um cabo UTP-08 blindado ligado nessa haste, ou subir um cabo qualquer (Até de 1,5mm serve) e ligar num RJ-45 blindado plugado nalguma porta, que a RB estará aterrada. Não é a proteção perfeita mais agora vai gastar uns R$ 70 a 140 pra troca do chipset, convenhamos que um aterramento mínimo de R$ 50 ou 70 (Que evita muitas queimas, não só 1) não é caro.

Se não dá mesmo pra usar como está (Se dá erros até com eth1 desabilitada) o jeito é mandar pra reparo (Não sei indicar nenhum, procura no forum por reparo de mikrotik que achará muitos nomes). Se trocarem certinho, fica como nova, mas pra não repetir o problema seria bom pelo menos um aterramento mínimo. Se quiser colocar um protetor de surto (Protetor de ethernet), fique a vontade, mas esses protetores só atuam com aterramento igual, então aterramento você vai precisar de qualquer jeito, as descargas tem que ir pra algum lugar, sem aterramento elas não tem pra onde ir.

Obrigado por mais uma aula, antes de mandar para reparo vou comprar uma no fornecedor aqui restaurar as configurações da atual nela e por pra rodar, se ficar tudo ok acho que vou guardar esta de reserva depois de reparada, infelizmente não posso me dar ao luxo de ficar alguns dias sem ela, o povo aqui me mataria, com a Etho 1 desabilitada ela roda mas roda a 10mb como vimos ao longo do tópico, com a Etho 1 ligada ela fica louca, então vou dar meu jeito de substituir a mesma e resolver de vez toda essa amolação, agradeço muito todos que responderam ao tópico em especial o Rubem pois pude absorver muito conhecimento com as explicações.