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

Ola a todos este e meu primeiro post e a ultima alternativa que vi foi vir ate aqui antes de comprar outra antena, eu possuo aqui 2 adsl Velox de 15mb ligados a um balanceador de carga TPlink e tenho a Omnitik conectada a ele e mantenho 10 pessoas da minha família conectadas a OMNitik e tudo estava funcionando perfeitamente bem, na minha casa que e a mais próxima com um sinal de -50db eu estava conseguindo passar 28mb pela omnitik tranquilamente quando usava Torrent ou baixava algo pelo Steam, o balanceador somava os links direitinho e passava pela Omni, semana passada caiu uma chuva pesada aqui com raios próximos, depois de cair um raio uma porta do balanceador queimou (tinha um desktop direto nela), a Omni estava conectada a ele pela ETHER5 dela e a ETHER 1 estava conectada apenas para alimentar a mesma pelo injetor POE pois acho que a minha só na porta 1 vai energia, o cabo do injetor ficava solto e não fazia diferença, desliguei tudo depois do raio pesado.

Quando voltou os PPOEE de algumas pessoas não estava conectando, fui ate o LOG da Omnitik e tinha uma mensagem assim:

Ether1: Bridge port received packet with own address as source address (mac aqui) ,probably LOOP.

E ficava nisso repetindo o tempo todo, o que fiz foi desabilitar a porta e tudo voltou ao normal, só que agora reparei o seguinte, com todos usuários usando ou apenas uma pessoa o throughput maximo que ela esta dando e 10MB, as vezes da um pico de 11-12 mas sempre limitada abaixo de 10MB, ja fucei tudo, pensei que era o balanceador mas testando nas portas dele diretamente o mesmo envia os 30MB dos 2 ADSL totalmente, estou ficando louco com esse problema, séra que queimou algum outro componente na antena? Uso MCS 4 e NV2 ativado, CCQ da galera ta 90/90 em media mas estou passando por este problema, espero que alguém tenha uma luz.

e a porta sincronizou como em 10 mbs vc viu isso ?

Anexo 63227pelo visto esta em 100MB a ether 5, se eu habilito a 1 mesmo ela nem estando conectada a nada começa dar a msg do LOOP.

Mesmo problema comigo hoje tenho uma sxt e só 10mb funciona.... Tem concerto?

tem q testar outra porta

Então vc tb sofreu um raio? Esqueci de mencionar que todos clientes são SXT, vejam agora que interessante, se eu faço um bandwitch test por dentro da Omni para meu IP ta passando 18+- quando vou fazer um Speedtest pela net so vejo passar 10MB, acho que vou surtar com isso.

Citação:

---

Postado originalmente por Bendertk

Mesmo problema comigo hoje tenho uma sxt e só 10mb funciona.... Tem concerto?

---

Deve ter conserto sim Bendertk

Séra que a porta 5 pode estar em alguma especie de curto com a 1?? Acredito que se estivesse ferrada também nem funcionar ela iria, mas pode ser uma possibilidade.

Citação:

---

Postado originalmente por JhoniVaz

tem q testar outra porta

---

Mas vc mudou as config das portas pra mudar da 1 para 5 ?

Desde que comprei sempre funcionou assim, ela ja veio com uma pré configuração e aprendi algumas coisas e aperfeiçoei, a 5 sempre recebeu o link e a 1 somente alimentava a mesma, o que fiz desta vez foi desligar a porta 1 em Interfaces para parar de dar a MSG de LOOP e deixar logar os clientes que estava logando e caindo.

Citação:

---

Postado originalmente por JhoniVaz

Mas vc mudou as config das portas pra mudar da 1 para 5 ?

---

Mas Vc não usava o POE Dela ? A porta 1 é poe, mas mesmo assim tem q mudar de porta para ver, passe para 4, mas tera q mudar as config

Citação:

---

Postado originalmente por JhoniVaz

Mas Vc não usava o POE Dela ? A porta 1 é poe, mas mesmo assim tem q mudar de porta para ver, passe para 4, mas tera q mudar as config

---

Usava a porta 1 unicamente para alimentar ela, amanhã vou trocar para a porta 4 então, parece que tenho que mecher e na parte dhcp client pelo que vi aqui.

Anexo 63228Pessoal troquei a porta para 4 e continuou inalterado, fui olhar como estava o sinal da turma e estava um terror na frenquencia que eu estava, fiz um Scanner e a frequência de 5765 que eu ultilizava nela esta com um uso louco de quase 50% todo o tempo, o canal melhor que encontrei foi o 5300 que consegui as taxas de CCQ atuais, porem tem um cliente ( meu tio) que mora em uma baixada, a frequência de 5765 entregava pra ele 90/90 de CCQ, nessa mudança o sinal dele foi de 66/68 pra 72/74 e o ccq ficou como esta, la tem poucas chances de mudar de lugar o equipamento, a Mikrotic tem algo mais potente pra colocar la que use NV2?

Anexo 63229

Citação:

---

Postado originalmente por renanssj5

Anexo 63229

---

O uso aí está intenso hein.
Mas o seu scan esta muito espaçado. Habilite o super channel e faça as varreduras com a opção scan list habilitada e informe os limites.

Enviado via GT-I9300I usando UnderLinux App

Este print você fez depois de mudar para o canal 5300, ou ainda estava nele?

Uma coisa que me chama a atenção é o Noise Floor. Pela leitura todos os canais tem um noise baixo o que favorece o SNR. Pelo que tenho lido , se o SNR for alto vai permitir navegação normal.
Ou será que esta leitura é "falsa"? Uma vez já li alguma coisa que o @rubem comentou sobre estes firmwares...

O chipset da Ominitik é o mesmo usado em alguns equipamentos Ubiquiti... no caso AR7241... esse tipo de defeito é muito comum em Ubnt, então provavelmente se resolve trocando o chipset.

Apos estar nele, agora estou operando em 5200, ta melhor ainda que 5300, o restante esta tudo detonado pelos provedores locais.

Segue o scanner completo conforme o pedidoAnexo 63244

Citação:

---

Postado originalmente por chocobama

O uso aí está intenso hein.
Mas o seu scan esta muito espaçado. Habilite o super channel e faça as varreduras com a opção scan list habilitada e informe os limites.

Enviado via GT-I9300I usando UnderLinux App

---

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?

Citação:

---

Postado originalmente por renanssj5

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.

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.

@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?

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).

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.

Citação:

---

Postado originalmente por 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.

---

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?

Citação:

---

Postado originalmente por 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.

---

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:
Anexo 63261

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.

Anexo 63262Anexo 63263

Citação:

---

Postado originalmente por renanssj5

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)

Citação:

---

Postado originalmente por rubem

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.Anexo 63266

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))

Citação:

---

Postado originalmente por 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))

---

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.

Citação:

---

Postado originalmente por 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.

É 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
Anexo 63269

(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)

Citação:

---

Postado originalmente por 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
Anexo 63269

(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?

Citação:

---

Postado originalmente por 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.

Anexo 63270Anexo 63271Fiz 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.

Citação:

---

Postado originalmente por rubem

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.

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??? Anexo 63273

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

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:
Anexo 63275
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.

Citação:

---

Postado originalmente por rubem

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

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:
Anexo 63275
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.

Pessoal estou com a nova Omnitik em mãos, minha duvida agora e a seguinte, como importar todas configurações para a nova? ja vi que não posso simplismente criar o arquivo de Backup e restaurar na outra, ambas estão na ultima versão do router OS, como devo proceder?

Se for em files e criar backup, pode restaurar ele em outra RB igual sim, vai mudar mac e cia mas funcionar funciona.

Outro jeito é ir no terminal e simplesmente digitar
export
Copia tudo aquilo, muda algo se quiser, se não, é só ir em outro terminal, e ir em partes colando (Botão direito do mouse> paste).