+ Responder ao Tópico



  1. #1

    Padrão PPPOE com disconects ou falhas de conexão por parte dos clientes.

    É isso, uso profiles com velocidades definidas, 1 profile pra 128 e outro pra 256, da seguinte maneira:

    1 name="Link #01 - 128k" local-address=192.168.100.1 remote-address=LINK #01 use-compression=no use-vj-compression=no
    use-encryption=no only-one=default change-tcp-mss=yes rate-limit=64000/128000

    2 name="Link #01 - 256k" local-address=192.168.100.1 remote-address=LINK #01 use-compression=no use-vj-compression=no
    use-encryption=no only-one=default change-tcp-mss=yes rate-limit=64000/220000

    3 name="Link #02 - 128k" local-address=192.168.200.1 remote-address=LINK #02 use-compression=no use-vj-compression=no
    use-encryption=no only-one=default change-tcp-mss=no rate-limit=64000/128000

    4 name="Link #02 - 256k" local-address=192.168.200.1 remote-address=LINK #02 use-compression=no use-vj-compression=no
    use-encryption=no only-one=default change-tcp-mss=no rate-limit=64000/220000

    5 name="Link #01 - Sem Limites" local-address=192.168.100.1 remote-address=LINK #01 use-compression=no
    use-vj-compression=no use-encryption=no only-one=default change-tcp-mss=yes

    6 name="Link #02 - Sem Limites" local-address=192.168.100.1 remote-address=LINK #02 use-compression=no
    use-vj-compression=no use-encryption=no only-one=default change-tcp-mss=yes
    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.

    23:14:54 dhcp,info,debug DHCP WIRELESS assigned 192.168.0.33 to XX:XX:XX:XX:XX
    23:14:54 pppoe,info PPPoE connection established from XX:XX:XX:XX:XX:XX
    23:14:54 pppoe,ppp,info <pppoe-1>: waiting for call...
    23:14:54 pppoe,ppp,info <pppoe-leia>: authenticated
    23:14:54 pppoe,ppp,info <pppoe-leia>: connected
    23:14:54 pppoe,ppp,info,account leia logged in, 200.168.200.253
    23:15:27 pppoe,info PPPoE connection established from 00:14:78:53D:65
    23:15:27 pppoe,info PPPoE connection from 00:14:78:53D:65 was already active - closing previous one
    23:15:27 pppoe,ppp,info,account leia logged out, 32 15279 31050 91 78
    23:15:27 pppoe,ppp,info <pppoe-leia>: terminating... - disconnected
    23:15:27 pppoe,ppp,info <pppoe-leia>: disconnected
    23:15:27 pppoe,ppp,info <pppoe-0>: waiting for call...
    23:15:27 pppoe,ppp,info <pppoe-leia>: authenticated
    23:15:27 pppoe,ppp,info <pppoe-leia>: connected
    23:15:27 pppoe,ppp,info,account leia logged in, 200.168.200.253
    Nunca tinha reparado nessa linha
    23:15:27 pppoe,info PPPoE connection from 00:14:78:53D:65 was already active - closing previous one
    , 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á
    <PPPOE-0>waiting for call...
    <pppoe-0> alguma msg que não lembro
    <pppoe-0>disconnected
    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:
    23:35:52 wireless,info 00:0E:2E:CC:3E:53@wlan1: connected
    23:36:32 wireless,info 00:0E:2E:CC:3E:53@wlan1: disconnected, got disassoc:
    sending station leaving (8)
    23:36:35 wireless,info 00:0E:2E:CC:3E:53@wlan1: connected
    server
    23:35:16 pppoe,ppp,info <pppoe-0>: waiting for call...
    23:35:17 pppoe,ppp,info <pppoe-felipe>: authenticated
    23:35:17 pppoe,ppp,info <pppoe-felipe>: connected
    23:35:17 pppoe,ppp,info,account felipe logged in, 200.168.200.239
    23:35:51 pppoe,ppp,info,account felipe logged out, 34 7743 103242 114 106
    23:35:51 pppoe,ppp,info <pppoe-felipe>: terminating... - disconnected
    23:35:51 pppoe,ppp,info <pppoe-felipe>: disconnected
    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,
    disconnect-timeout=1s
    . 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.
    Última edição por Gosulator; 23-03-2008 às 00:04.

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

    Padrão

    Tem um topico aqui relacionado , e se não me engno tem a ver com o MTU , vou pesquisar aqui e vejo se te respondo novamente.

    *lembrei:


    Seta o ACK TimeOut, e , tira o Periodic Calibration!
    Última edição por luizbe; 23-03-2008 às 00:29.

  3. #3

    Padrão

    vc sabe dizer o que faz o periodic calibration? Vou mexer apenas se começar a dar merda de novo, pq tá legal agora, pararam as quedas.

  4. #4
    Mikrotik inSide Avatar de luizbe
    Ingresso
    Sep 2005
    Localização
    Governador Valadares
    Posts
    1.212
    Posts de Blog
    1

    Padrão

    Periodic quando o sinal do cliente ta ruim e ele da muito loss , o periodic desconecta ele e conecta dinovo..

    que faz ocasionar aquilo que voce viu
    e eu percebi um dia que quando o periodic faz isso com 1 cliente os outros tudo tem um pico de "latencia" ...

    por isso, desativo essa merda. ;}


    se der, vc altera..!
    qualquer coisa estamos aqui.



  5. #5

    Padrão

    desativei o periodic calibration e não mudou, continuaram as quedas. as configs da sua interface wireless tão muito diferentes da minha? Quanto a setar o ack, se eu seto a 30us, o que acontece? os clientes que não conseguirem se conectar a 30us se ferram?

    Pode ser ausência de regras que bloqueiem os clientes de se enxergar? Pq não coloquei as regras nesse ap novo, apenas uma regra que impede clientes com ips dados pelo dhcp de se comunicarem (srcadress 192.168.0.0, dstaddress 192.168.0.0, action=drop). Tá um inferno aqui agora.

    Isso só acontece comigo? Nunca ví ng mais reclamar disso aqui, pppoe caindo sem parar por causa de coisa do ap. E comigo já aconteceu 2 vezes, com 2 aps COMPLETAMENTE diferentes.

  6. #6
    Mikrotik inSide Avatar de luizbe
    Ingresso
    Sep 2005
    Localização
    Governador Valadares
    Posts
    1.212
    Posts de Blog
    1

    Padrão

    ACK 30us?

    nossa ai o seu sinal tem que tá muito mais do que excelente.


    Seta o ACK em 91us , foi o que coloquei aqui usando na torre que tem uma Omni e meio poluido o espectro.

    mas se for painel setorial da hyper de 14db pode por 60us de ack!

    agora se for da tsm deixa em 91us mesmo.. mas pode oscilar de acordo com o espectro ae.

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

  8. #8
    Mikrotik inSide Avatar de luizbe
    Ingresso
    Sep 2005
    Localização
    Governador Valadares
    Posts
    1.212
    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:


  9. #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.

  10. #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

  11. #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

  12. #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 02:47.

  13. #13

    Padrão

    as quedas continuaram com as configurações acima. E o acktimeout das interfaces estava horrível, coisa de 10, 20%. Só voltou ao normal (90% pra cima) depois que eu mudei as data rates. fixei elas em 11mb apenas.

    a config agora é essa:

    name="XXXXXX" mtu=1500 mac-address=XXXXXXXXX arp=enabled
    disable-running-check=no interface-type=Atheros AR5212 radio-name="XXXXX"
    mode=ap-bridge ssid="XXXXXXX" 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=11Mbps
    supported-rates-a/g="" basic-rates-b=11Mbps basic-rates-a/g=""
    max-station-count=2007 ack-timeout=91 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

    Vou ficar de olho pra ver se resolve. Lembrando que o ping dos clientes está com 0% de perda. 0. Média de 10ms.

  14. #14

    Padrão

    Tive esse problema no inicio a solução foi aumentar o keepalive timeout para 90.

  15. #15

    Padrão

    sim, mas isso adianta quandoi você usa pppoe profiles, que setam queues dinânicas e tal, pq eu não vejo onde nas configs dos profiles, tem alguma referência aos pppoeservers, e o keepalive só é configurável nos pppoeservers.

  16. #16

    Padrão

    disconnect-timeout=3s
    Alguém sabe pra que exatamente esse comando serve? é das interfaces wireless, aba "advanced".

  17. #17

    Padrão

    24h sem quedas pessoal. a config atual das interfaces wireless é essa:

    name="" mtu=1500 mac-address= arp=enabled
    disable-running-check=no interface-type=Atheros AR5212 radio-name=""
    mode=ap-bridge ssid="" 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=11Mbps
    supported-rates-a/g="" basic-rates-b=11Mbps basic-rates-a/g=""
    max-station-count=2007 ack-timeout=91 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

  18. #18

    Padrão

    boa noite amigo, vc deve usar um ack time out, entre 30 e 90 e pra nao repassar nada entre clientes vc deve usar o seguinte na bridge (ap):


    / interface bridge filter
    add chain=forward mac-protocol=0x8863 action=accept comment="" disabled=no
    add chain=forward mac-protocol=0x8864 action=accept comment="" disabled=no
    add chain=forward mac-protocol=!0x8863 action=drop comment="" disabled=no
    add chain=forward mac-protocol=!0x8864 action=drop comment="" disabled=no
    / interface bridge broute
    add chain=brouting mac-protocol=0x8863 action=accept comment="" disabled=no
    add chain=brouting mac-protocol=0x8864 action=accept comment="" disabled=no

    essas regras bloqueian tudo exeto o q interessa pro pppoe,... e com isso vai reduzir drasticamente o tregego indesejado no seu ap..
    Última edição por iroti; 07-04-2008 às 21:50.

  19. #19

    Padrão

    Citação Postado originalmente por gosulator Ver Post
    desativei o periodic calibration e não mudou, continuaram as quedas. As configs da sua interface wireless tão muito diferentes da minha? Quanto a setar o ack, se eu seto a 30us, o que acontece? Os clientes que não conseguirem se conectar a 30us se ferram?

    Pode ser ausência de regras que bloqueiem os clientes de se enxergar? Pq não coloquei as regras nesse ap novo, apenas uma regra que impede clientes com ips dados pelo dhcp de se comunicarem (srcadress 192.168.0.0, dstaddress 192.168.0.0, action=drop). Tá um inferno aqui agora.

    Isso só acontece comigo? Nunca ví ng mais reclamar disso aqui, pppoe caindo sem parar por causa de coisa do ap. E comigo já aconteceu 2 vezes, com 2 aps completamente diferentes.


    ola amigo estou com o mesmo problema voc conseguiu solucao ?