solução de problemas de QoS do firmware do roteador dd-wrt

Estou usando o firmware dd-wrt no meu roteador e gosto muito!

Mas - não tenho certeza de que a qualidade de serviço (QoS) esteja funcionando. Eu o configurei da seguinte maneira:

• http, porta 80 - Premium
• bittorrent, porto 6969 - Bulk
• https, porta 443 - Premium
• DNS, porta 53 - Premium

De acordo com a documentação de QoS , esses níveis são:

a largura de banda é alocada com base nas seguintes porcentagens de valores de uplink e downlink para cada classe:

• Isento: 100mbps - ignora os limites globais.
• Prêmio: 75% - 100%
• Expresso: 15% - 100%
• Padrão: 10% - 100%
• Massa: 1,5% - 100%

Porém, isso não parece funcionar totalmente - com torrentes ocupadas, recebo grandes pausas na minha navegação na web, o que é uma merda!

A documentação de QoS fornece algumas etapas para verificar a QoS ...

O que você estará interessado em examinar será o primeiro conjunto de IP de origem e destino, incluindo os números de porta. Em seguida, a presença de l7proto e o campo "mark". As entradas indicam a prioridade de QoS da conexão ao vivo atual aplicada a elas com base no campo "marca". Os valores da "marca" correspondem aos seguintes

• Isento: 100
• Premium: 10
• Express: 20
• Standard: 30
• Massa: 40
• (sem QoS correspondente): 0

Você pode ver "mark = 0" para algum serviço l7proto, mesmo que eles estejam configurados na lista de regras de QoS. Isso pode significar que o sistema de correspondência de padrões da camada 7 não corresponde a um cabeçalho novo ou alterado para esse protocolo. O serviço personalizado em correspondências de portas geralmente cuida delas.

Na porta 6969 (bittorrent), vejo uma estranha mistura de coisas mark=0e mark=40coisas assim

cat / proc / net / ip_conntrack

udp 17 105 src = 98.162.182.42 dst = 1.2.3.4 sport = 64512 dport = 6969 pacotes = 3 bytes = 290 src = 10.0.0.2 dst = 98.162.182.42 sport = 6969 dport = 64512 pacotes = 4 bytes = 202 [ASSURED] mark = 0 secmark = 0 use = 1
tcp 6 117 TIME_WAIT src = 98.248.173.174 dst = 1.2.3.4 sport = 51114 dport = 6969 pacotes = 12 bytes = 704 src = 10.0.0.2 dst = 98.248.173.174 sport = 6969 dport = 51114 pacotes = 10 bytes = 440 [ASSURED ] marca = 40 segundos = 0 use = 1
tcp 6 598 ESTABELECIDO src = 165.132.128.201 dst = 1.2.3.4 esporte = 57218 dport = 6969 pacotes = 8024 bytes = 9919881 src = 10.0.0.2 dst = 165.132.128.201 sport = 6969 dport = 57218 pacotes = 4211 bytes = 239607 [ASSURED ] mark = 0 secmark = 0 use = 1
tcp 6 586 ESTABELECIDO src = 68.46.9.24 dst = 1.2.3.4 sport = 64688 dport = 6969 pacotes = 6 bytes = 490 src = 10.0.0.2 dst = 68.46.9.24 sport = 6969 dport = 64688 pacotes = 8 bytes = 944 [ASSURED ] marca = 40 segundos = 0 use = 1
udp 17 45 src = 222.254.228.38 dst = 1.2.3.4 sport = 25438 dport = 6969 pacotes = 5 bytes = 454 src = 10.0.0.2 dst = 222.254.228.38 sport = 6969 dport = 25438 pacotes = 3 bytes = 154 [ASSURED] mark = 0 secmark = 0 use = 1

(arquivo completo visível em http://pastebin.com/AZE6EtWm )

Estou brincando com esse registro há um tempo e não vejo nenhum padrão!

Por que algum tráfego bittorrent da porta 6969 é marcado mark=0(não correspondido) pela QoS da dd-wrt enquanto outros são marcados mark=40(Bulk) .. alguma idéia?

Embora apenas modifique o tráfego de saída , você pode achar útil esse excelente script de QoS ( espelho na pasta ) no blog de Alex Rice. Já passou por vários autores e encarnações. Certifique-se de definir UPLINK e DEV corretamente. Para mim, o valor padrão para DEV estava incorreto, use o comentado $(nvram get wan_ifname)ou o valor correto da execução nvram get wan_iframevia SSH.

Além disso, em vez de usá-lo, você pode duplicar sua configuração na GUI de QoS. Você verá que ele usa 1024: 65535 para tráfego em massa, com as outras configurações (80,22,3389 etc.) tendo precedência. O script funciona bem para mim e usa o HFSC conforme recomendado.

Por exemplo: QoS definido como WAN envia tráfego de uplink para a fila de downlink.
Então, verifique se esse patch falha porque: Os comandos no script rc_firewall não são aplicados na QoS

Você pode solucionar o problema com um script que é executado após o rc_firewall, conforme observado no ticket. Pessoalmente, acabei ativando o JFFS e colocando o script com a correção /jffs/etc/config/qos.ipup, igual ao mencionado.

Achei conveniente usar o KiTTY e o WinSCP . Você pode fazer o SSH no roteador com o KiTTY para solucionar problemas / verificar como no primeiro tíquete e iniciar diretamente a navegação de arquivos no roteador com o Start WinSCPcomando sob o ícone superior esquerdo do KiTTY. Se isso falhar (o roteador não está executando o SFTP por padrão), você pode ativar o FTP e conectar-se manualmente ou simplesmente adicionar o arquivo com os comandos do Unix. Lembre-se de definir a permissão de execução do proprietário no script.

Percebi que muitas pessoas reclamam que a QoS não funciona no DD-WRT; portanto, elas mudam para o Tomato. Funciona bem no tomate (eu uso). O tomate também possui gráficos muito bons, úteis para ajustar as configurações de QoS.

A desvantagem do Tomato, em comparação com o DD-WRT, é que ele tem menos recursos, embora existam algumas construções de mods que adicionam certas coisas, como armazenamento USB e OpenVPN. No entanto, como Jeff Atwood mencionado abaixo, ele suporta apenas chipsets Broadcom.

Eu uso o mod Teddy Bear no meu Netgear WNR3500L. Agora uso o mod Toastman, que é baseado no Teddy Bear, com mais recursos e melhores classes de QoS padrão que funcionam para a maioria das pessoas.

Pessoalmente, as únicas coisas que sinto falta no Tomato são o suporte a VLAN e a transmissão multi-SSID. (O mod de Toastman possui os dois agora, bem como o Captive Portal para o SSID secundário).

Descobri que o DD-WRT v24 sp2 build 15362 é muito estável no meu Netgear WNDR3700 v1, MAS, apesar de muito tempo gasto tentando configurar QoS e TCP Vegas (controle de congestionamento), nenhum mecanismo parece estar funcionando neste excelente firmware para tráfego de entrada (não preciso de controle de saída, pois não uso VOIP).

Por exemplo, não importa quais opções (Mac Control, Netmask, Service Control) eu uso nas minhas tentativas de priorizar o tráfego de vídeo de entrada e de priorizar o tráfego de torrent de bits de entrada, nada funciona. Eu confirmei isso com

• Comandos Telnet sugeridos para confirmar a operação de QoS
• TCP Vegas

Conclusão: use DD-WRT se desejar todos os outros recursos (principalmente transmissão de vários SSIDs), mas use Tomato se você tiver um chipset aplicável (o Tomato não está disponível para o WNDR3700 baseado em Atheros) e como os recursos de QoS.

Eu notei a mesma coisa. Não consigo encontrar a postagem exata agora, mas, pesquisando nos fóruns, um dos desenvolvedores afirmou que a QoS funciona muito bem em envios, não tanto em downloads. O raciocínio subjacente é que o roteador tem controle do tráfego saindo da rede (uplink), mas não o tráfego entrando, pois não tem controle sobre o fluxo de dados recebido.

Sei que você não é um grande fã de navegar nas postagens do fórum, mas pode postar suas perguntas lá.