Página 2 de 4 PrimeiroPrimeiro 1234 ÚltimoÚltimo
+ Responder ao Tópico



  1. #7

    Padrão

    com o ack dinamico 90% dos clientes pegam 30us, tanto no painel (tsm) quanto na omni (hypertec porca), não parece haver nenhum padrão. Mas a pergunta é, se eu setar o acktimeout em 60us por exemplo, pode ter gente que não consiga se conectar ao ap? Aqueles que entravam com 200us, por exemplo (quase nunca acontecia, mas vez por outro rolava, um nego conectava com 200us, ai eu desconectava ele e ele voltava com 30us).

    Valeu pela atenção luizbe

  2. #8
    Mikrotik inSide Avatar de luizbe
    Ingresso
    Sep 2005
    Localização
    Governador Valadares
    Posts
    1.214
    Posts de Blog
    1

    Padrão

    é exatamente esse que ta a 200us que ta te atrapalhando,
    seta ae o ACK e faz o teste.
    qualquer coisa posta aqui...


    e vamos:




  3. #9

    Lightbulb

    Olá amigos, eu uso PPPoE aqui e ja tive um problema parecido.
    Resolvi configurando todos os clientes só com 11MbB e as minhas antenas eu coloco com 2Mb , 5.5Mb, 11Mb isso em Supported Rates B e Basic Rates B, com isso vc força o cliente a se conectar no mino a 2Mb aqui quando o cliente tava apenas com 1Mb ele dava erro no PPPoE.

    Boa sorte.

  4. #10

    Padrão

    Citação Postado originalmente por Gosulator Ver Post
    É isso, uso profiles com velocidades definidas, 1 profile pra 128 e outro pra 256, da seguinte maneira:

    Esses sem limites só quem usa sou eu. Notem que todos têm local address iguais.

    Estava tudo em ordem até pouco tempo atrás, até uma semana atrás pra ser mais exato. Começou a frescura quando eu mudei meu ap (tenho um servidor mkt no chão, e um ap-bridge mkt, com apenas a seguinte regra; 0 chain=forward src-address=192.168.0.0/24 dst-address=192.168.0.0/24
    action=drop).

    Mudei o ap pq o outro era mal ventilado e uma placa mãe que eu não confiava. Mudei as antenas também, tirei 1 das omnis e coloquei 3 paineis. O sinal de todos os clientes melhoraram 200%, e a taxa máxima de tráfego quadruplicaram, além dos pings em média muuito mais baixos.

    Acontece que depois dessa alteração, sem mudar NADA no server, e com o ap novo com as mesmas configurações do antigo (apbridge, sem nada demais, a única diferença são os pings, 10.0.0.2 pro ap antigo e 10.0.0.3 pro atual, e não, não tem nenhuma regra no servidor usando esse ip do ap), começa a dar essas maluquices, de o cliente discar o pppoe e dar aquela mensagem de "o computador remoto não respondeu", ou então o cliente fica caindo do pppoe constantemente.

    Nunca tinha reparado nessa linha
    , não sei se dá isso toda vez que o cliente cai. E tem as mais toscas, que é a que o cliente disca e não tem resposta. Fica lá
    Sem nem dizer qual o mac que tentou a conexão. Acabo sabendo quem foi pq ele tenta denovo em poucos minutos e eu vejo quem era, e alguns me ligam relatando o problema e eu vou checar o horário e acho no log.

    Que diabos pode ser isso? Lembrando que não tinha esses problemas antes de trocar o ap, mesmo com sinal lixo e taxa de transferência baixa. A comunicação do servidor com o ap está perfeita, tive uns problemas com a ether onboard do ap, e por isso subi uma offboard, resolveu. O ap usa uma versão 2.9.27 crackeada (Mikrotik 2.9.27 ok (Full License Level 6 by NGR).iso), e no servidor está uma 2.9.27 crackeada pelo RouterClub. Já recebi conselhos a respeito da montanha de bugs que a versão routerclub tem. Só que não quero comprar 2 licenças originais, pra por em hds velhos (ou ter que comprar 2 novos ou 1 +cartão flash), e continuar tendo problemas. Alguém já passou por algo do tipo? Lembrando que isso tudo acontece sem que o cliente se desconecte do ap.

    ap:
    server

    O mac que deu o disconect no ap por alguns segundos é o desse cliente que deslogou no pppoe. A maioria dos disconnects no ap é por causa de "extensive data loss", e creio que o efeito é o mesmo, o cliente cai do pppoe. Mas isso acontecia com a omni e os clientes não caiam. Creio que eu possa pelo menos aumentar esse tempo pra o disconnect do pppoe. Aumentar pra dar tempo do cliente que for desconectado do ap voltar a se conectar. Onde eu ajeito isso usando profiles diferenciados?

    Isso tá parecendo um diário, mas aí vai;

    esse comando, está setado pra 3s por padrão, . Eu coloquei pra 1s, e junto com isso tirei o default forward das interfaces (troquei o ap recentemente, e pros clientes não terem problemas demais deixei livre pra conectar, e ia ajustando aos poucos) e pararam os logs de disconnected do ap. Vou ver como fica a situação do pppoe nos próximos minutos e venho aqui escrever mais uma página dessa bíblia.

    grato pela paciência de quem estiver lendo isso.

    Depois de ler todas as mensagens deste post, estou enviando a minha contribuição.

    *Fixe a velocidade de todos os clientes em 1MB, isso vai evitar muito processamento por parte do seu AP na negociação do RATE com o cliente e tornará sua rede mais robusta, permitindo a entrada de um maior número de clientes por interface.

    *Utilize regra para bloqueio de trafego entre clientes, se o AP estiver ocupado transferindo altas taxas de dados entre clientes não irá sobrar muita coisa para a autenticação.

    *Veja como esta o processamento deste MK, processamento muito elevado pode gerar um tempo de espera na conexão. Hardware fraco ou um defeito no mesmo podem ser um problema.

    *Verifique se não tens algum cliente com sinal muito fraco ou com potência demais no equipamento (potência demais no cliente pode causar interferências)e corrija, sinal fraco pode gerar uma negociação excessiva entre seu AP e o seu cliente.

    *Como você disse, o sinal melhorou 200%, talvez seja necessário baixar a potência em algum equipamento de cliente para obter o resultado adequado.

    *Quarto, se tiver problemas com quedas constantes pode e deve aumentar o valor do Keepalive Timeout e comparar os resultados.

    *Em connection tracking aumente entre 50%/100% os valores padrões e compare os resultados.

    Agradeço se postar aqui os resultados obtidos, juntamente com:

    Qual versão do MK está utilizando ?
    Em qual hardware PC/MK?
    O problema é constante ?
    Ocorre em todos os painéis ?

    Grato

    M4D3



  5. #11

    Padrão

    Citação Postado originalmente por m4d3 Ver Post
    Depois de ler todas as mensagens deste post, estou enviando a minha contribuição.

    *Fixe a velocidade de todos os clientes em 1MB, isso vai evitar muito processamento por parte do seu AP na negociação do RATE com o cliente e tornará sua rede mais robusta, permitindo a entrada de um maior número de clientes por interface.

    Vou fazer isso e checar.

    *Utilize regra para bloqueio de trafego entre clientes, se o AP estiver ocupado transferindo altas taxas de dados entre clientes não irá sobrar muita coisa para a autenticação.

    As seguintes regras foram adicionadas agora:
    0 chain=forward protocol=udp src-port=135-139 dst-port=135-139 action=drop

    1 chain=forward protocol=udp src-port=445 dst-port=445 action=drop

    2 chain=forward protocol=tcp src-port=135-139 dst-port=135-139 action=drop

    3 chain=forward protocol=tcp src-port=445 dst-port=445 action=drop
    *Veja como esta o processamento deste MK, processamento muito elevado pode gerar um tempo de espera na conexão. Hardware fraco ou um defeito no mesmo podem ser um problema.

    Processamento ok, não passa de 2%. Memória completamente livre, o ap não tem nenhuma função extra. Sempre tem mais de 106mb livres, de 128mb.

    *Verifique se não tens algum cliente com sinal muito fraco ou com potência demais no equipamento (potência demais no cliente pode causar interferências)e corrija, sinal fraco pode gerar uma negociação excessiva entre seu AP e o seu cliente.

    Nenhum cliente com sinal muito baixo, um ou outro com sinal -69 no ap, mas como dito antes, no outro ap, com a omni, esses mesmos clientes ficavam -75 sem que a conexão caísse.

    *Como você disse, o sinal melhorou 200%, talvez seja necessário baixar a potência em algum equipamento de cliente para obter o resultado adequado.

    Todos meus clientes estão com potência default. Pode ser que os que estejam muito próximos (sinais que chegam a -40, -45) estejam causando problemas? todos com placas pci em seus pcs, com potência padrão.

    *Quarto, se tiver problemas com quedas constantes pode e deve aumentar o valor do Keepalive Timeout e comparar os resultados.

    Eu comecei a usar os pppoe profiles pra definir a velocidade de acesso do cliente, e nesses profiles não existe a opção pra mudar o keepalive, apenas nos pppoe servers. E os pppoe servers que estão no meu server estão às moscas, só estão lá pq ng deletou-os. Pra ser sincero, como 80% da config do meu server foi feita por um parceiro, nem sei se existe a necessidade daqueles pppoe servers alí atualmente.

    *Em connection tracking aumente entre 50%/100% os valores padrões e compare os resultados.

    Onde fica essa opção? Nunca a ví. Lembrando que uso a versão 2.9.27 no ap e no server.

    Agradeço se postar aqui os resultados obtidos, juntamente com:

    *Qual versão do MK está utilizando ?
    2.9.27 no ap e no servidor, crackeadas. A do servidor é a versão do routerclub, a do ap não menciona nada a respeito.

    *Em qual hardware PC/MK?
    a7v8xx, atlhon 1,5ghz, 128mb pc333, hdd40gb, 4 pci AR5212 (greatek), 1 ethernet RHINE III. 3 paineis 90º 12,5dbi TSM a 35mt, 1 omni hypertec 15dbi a 20mt.
    # DEVICE VENDOR NAME IRQ
    0 01:00.0 nVidia Corporation NV18 [GeForce4 MX 4000 A... 11
    1 00:12.0 VIA Technologies, Inc. VT6102 [Rhine-II] (rev: ... 7
    2 00:11.1 VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B... 255
    3 00:11.0 VIA Technologies, Inc. VT8235 ISA Bridge (rev: 0) 0
    4 00:0f.0 Atheros Communications, Inc. unknown device (rev: 1) 12
    5 00:0e.0 Atheros Communications, Inc. unknown device (rev: 1) 10
    6 00:0d.0 Atheros Communications, Inc. unknown device (rev: 1) 11
    7 00:0c.0 Atheros Communications, Inc. unknown device (rev: 1) 4
    8 00:0b.0 VIA Technologies, Inc. VT6105 [Rhine-III] (rev:... 4
    9 00:01.0 VIA Technologies, Inc. VT8237 PCI Bridge (rev: 0) 0
    10 00:00.0 VIA Technologies, Inc. VT8377 [KT400/KT600 AGP]... 0
    *O problema é constante ?
    Sim, em determinados momentos poucos clientes caem, e conseguem rediscar em seguida, as vezes metade dos clientes não consegue conectar no pppoe, e a outra metade conecta e cai sem parar.
    As vezes, normalmente após ligar o ap ou após um restart ou mudança de config nas interfaces, os clientes não conseguem se conectar à interface. Apenas um cliente se conecta à interface, e os outros não conectam de jeito algum. Quando um segundo cliente consegue se conctar, cai em menos de 4 segundos. Lembrando que isso é relativo às interfaces apenas, pode estar acontecendo isso em 1 painel, e no outro estar tudo em ordem. Creio que nisso esteja a chave do problema, embora mesmo quando isso não acontece, os clientes caem do pppoe (obviamente têm que estar conectados ao ap pra poderem usar o pppoe)

    *Ocorre em todos os painéis ?
    Sim, desconfio que aconteça mais em um deles, mas é apenas desconfiança.

    - Lembrando que não consigo usar o canal 1 pelo fato de algum gato filho da puta estar com alguma antena debaixo do meu nariz, no canal 1, e o tráfego na interface vai a 0kbps quando eu seto pra usar o canal 1. Qualquer um dos meus paineis. Atualmente tenho taxas de 3,5 - 4mb dl dos clientes no meu painel com melhor desempenho, e taxas de 2-3,1mb dl no painel mais afetado por poluição. O upload depende muito de onde o cliente está localizado, varia um bocado, mas a maioria fica em 2,5mb no melhor painel e variando de 300kbps a 3mb no pior painel (isso são os picos, a variação costuma ficar entre 1,2mb e 2mb)

    M4D3
    Valeu pela atenção, vou implementar algumas das suas sugestões e de manhã vejo como fica o pepino. Outra coisa, que você não comentou, não sei se pelo fato do amigo Luizbe já ter sugerido ou porque você não usa; é a respeito do acktimeout. Você como ele, também sugere fixa-lo?

    Grato pela atenção

  6. #12

    Padrão

    Implantei as mudanças, as interfaces estão da seguinte maneira:

    0 R name="nomedoradio" mtu=1500 mac-address=00:19:E0:8A:1D:52 arp=enabled
    disable-running-check=no interface-type=Atheros AR5212 radio-name="nomeradio"
    mode=ap-bridge ssid="ssiddoradio" area="" frequency-mode=manual-txpower
    country=no_country_set antenna-gain=0 frequency=2427 band=2.4ghz-b
    scan-list=default rate-set=configured supported-rates-b=1Mbps
    supported-rates-a/g="" basic-rates-b=1Mbps basic-rates-a/g=""
    max-station-count=2007 ack-timeout=60 tx-power=22
    tx-power-mode=card-rates noise-floor-threshold=default
    periodic-calibration=default periodic-calibration-interval=60
    burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled
    wds-default-bridge=none wds-default-cost=100 wds-cost-range=50-150
    wds-ignore-ssid=no update-stats-interval=disabled
    default-authentication=no default-forwarding=no default-ap-tx-limit=0
    default-client-tx-limit=0 proprietary-extensions=post-2.9.25
    hide-ssid=no security-profile=default disconnect-timeout=1s
    on-fail-retry-time=100ms preamble-mode=long compression=no
    allow-sharedkey=no
    os pings estão legais no painel mais poluido, e no painel menos poluido tenho apenas um cliente conectado, e que não está com pppoe ativo, não posso checar seu ping (não consigo pingar pelo ap, provavelmente por causa da faixa do ip do ap e da faixa que o dhcpserver no meu servidor dá aos clientes, que é diferente [posso adicionar um segundo ip à bridge do ap, na mesma faixa da ippool do dhcp, pra que o ap possa pingar os clientes?]). Na omni os pings estão legais também.

    edit: já conectou um segundo cliente nesse outro painel, e também está pingando perfeito, o negócio é esperar a hora do rush, a partir das 9 da manhã.

    edit2: a respeito do segundo ip da bridge pra pingar os clientes, funcionou. Vocês sabem se isso pode dar alguma birra na bridge? 2 ips?
    Última edição por Gosulator; 24-03-2008 às 01:47.