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



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

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



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

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



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






Tópicos Similares

  1. Limite de Conexao por grupo de porta e cliente
    Por AndrioPJ no fórum Redes
    Respostas: 1
    Último Post: 02-11-2009, 01:11
  2. URGENTE erros, falha de conexão, aiaiai
    Por amatrizatende no fórum Redes
    Respostas: 1
    Último Post: 23-11-2007, 16:00
  3. Erro com placa ou driver de som...
    Por Lipse no fórum Sistemas Operacionais
    Respostas: 6
    Último Post: 28-11-2005, 16:02
  4. Limitar numero de conexão por usuario
    Por dumato no fórum Servidores de Rede
    Respostas: 0
    Último Post: 05-10-2005, 10:16
  5. Gerenciamento por parte do cliente do qmail
    Por vini_alpha no fórum Servidores de Rede
    Respostas: 1
    Último Post: 07-05-2005, 00:17

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L