Dépannage de la qualité de service du firmware du routeur dd-wrt

J'utilise le firmware dd-wrt sur mon routeur et je l'aime beaucoup!

Mais - je ne suis pas sûr que la qualité de service (QoS) y travaille. Je l'ai configuré comme suit:

• http, port 80 - Premium
• bittorrent, port 6969 - Vrac
• https, port 443 - Premium
• DNS, port 53 - Premium

Selon la documentation QoS , ces niveaux sont:

la bande passante est allouée en fonction des pourcentages suivants de valeurs de liaison montante et de liaison descendante pour chaque classe:

• Exempt: 100mbps - ignore les limites globales.
• Premium: 75% - 100%
• Express: 15% - 100%
• Standard: 10% - 100%
• En vrac: 1,5% - 100%

Cela ne semble pas entièrement fonctionner, cependant - avec des torrents occupés, j'obtiens des pauses majeures dans ma navigation sur le Web, ce qui est nul!

La documentation QoS donne quelques étapes pour vérifier la QoS ...

Ce qui vous intéressera, ce sera le premier ensemble d'adresses IP source et de destination, y compris les numéros de port. Ensuite, la présence de l7proto et le champ "mark". Les entrées indiquent la priorité actuelle de QoS de connexion en direct qui leur est appliquée en fonction du champ "Mark". Les valeurs de "marque" correspondent aux valeurs suivantes

• Exonéré: 100
• Premium: 10
• Express: 20
• Standard: 30
• En vrac: 40
• (pas de QoS correspondant): 0

Vous pouvez voir "mark = 0" pour certains services l7proto même s'ils sont configurés dans la liste des règles de QoS. Cela peut signifier que le système de correspondance de modèle de couche 7 ne correspond pas à un en-tête nouveau ou modifié pour ce protocole. Un service personnalisé sur les correspondances de ports s'en occupera généralement.

Sur le port 6969 (bittorrent) je vois un mélange bizarre de trucs avec mark=0et mark=40j'aime

cat / proc / net / ip_conntrack

udp 17 105 src = 98.162.182.42 dst = 1.2.3.4 sport = 64512 dport = 6969 paquets = 3 octets = 290 src = 10.0.0.2 dst = 98.162.182.42 sport = 6969 dport = 64512 paquets = 4 octets = 202 [ASSURÉ] 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 paquets = 12 octets = 704 src = 10.0.0.2 dst = 98.248.173.174 sport = 6969 dport = 51114 paquets = 10 octets = 440 [ASSURÉ ] mark = 40 secmark = 0 use = 1
tcp 6 598 ESTABLISHED src = 165.132.128.201 dst = 1.2.3.4 sport = 57218 dport = 6969 paquets = 8024 octets = 9919881 src = 10.0.0.2 dst = 165.132.128.201 sport = 6969 dport = 57218 paquets = 4211 octets = 239607 [ASSURÉ ] mark = 0 secmark = 0 use = 1
tcp 6 586 ESTABLISHED src = 68.46.9.24 dst = 1.2.3.4 sport = 64688 dport = 6969 paquets = 6 octets = 490 src = 10.0.0.2 dst = 68.46.9.24 sport = 6969 dport = 64688 paquets = 8 octets = 944 [ASSURÉ ] mark = 40 secmark = 0 use = 1
udp 17 45 src = 222.254.228.38 dst = 1.2.3.4 sport = 25438 dport = 6969 paquets = 5 octets = 454 src = 10.0.0.2 dst = 222.254.228.38 sport = 6969 dport = 25438 paquets = 3 octets = 154 [ASSURÉ] mark = 0 secmark = 0 use = 1

(fichier complet visible sur http://pastebin.com/AZE6EtWm )

Je joue avec ce journal depuis un petit moment et je ne vois aucun motif!

Pourquoi le trafic bittorrent du port 6969 est-il étiqueté mark=0(sans correspondance) par la QoS de dd-wrt alors que d'autres sont étiquetés mark=40(en vrac) ... des idées?

Bien qu'il ne modifie que le trafic sortant , vous pouvez trouver cet excellent script QoS ( miroir sur pastebin ) sur le blog d'Alex Rice. Cela a été à travers plusieurs auteurs et incarnations. Assurez-vous de régler correctement UPLINK ainsi que DEV. Pour moi, la valeur par défaut pour DEV était incorrecte, utilisez $(nvram get wan_ifname)plutôt le commentaire ou la valeur correcte lors de l'exécution nvram get wan_iframevia SSH.

De plus, plutôt que de l'utiliser, vous pouvez dupliquer sa configuration dans l'interface graphique de QoS. Vous verrez qu'il utilise 1024: 65535 pour le trafic en vrac, les autres paramètres (80,22,3389, etc.) étant prioritaires. Le script fonctionne bien pour moi et utilise HFSC comme recommandé.

Par exemple: QoS défini sur WAN envoie le trafic de liaison montante vers la file d'attente de liaison descendante.
Ensuite, réalisez que ce correctif échoue, car: les commandes du script rc_firewall ne sont pas appliquées dans QoS

Vous pouvez contourner le problème avec un script qui s'exécute après rc_firewall comme indiqué dans le ticket. Personnellement, j'ai fini par activer JFFS et placer le script avec le correctif /jffs/etc/config/qos.ipup, comme indiqué.

J'ai trouvé pratique d'utiliser KiTTY et WinSCP . Vous pouvez SSH dans le routeur avec KiTTY pour dépanner / vérifier comme dans le premier ticket, et lancer directement la navigation dans les fichiers sur le routeur avec la Start WinSCPcommande sous l'icône en haut à gauche de KiTTY. Si cela échoue (le routeur n'exécute pas SFTP par défaut), vous pouvez activer FTP et vous connecter manuellement, ou simplement ajouter le fichier avec les commandes Unix. N'oubliez pas de définir l'autorisation d'exécution du propriétaire sur le script.

J'ai remarqué que beaucoup de gens se plaignent du fait que la QoS ne fonctionne pas dans DD-WRT, alors ils passent à la place à Tomato. Cela fonctionne bien dans Tomato (je l'utilise). Tomato a également de très beaux graphiques, qui sont utiles pour ajuster vos paramètres de QoS.

L'inconvénient de Tomato, par rapport à DD-WRT, est qu'il a moins de fonctionnalités, bien qu'il existe quelques versions de mod qui ajoutent certaines choses, comme le stockage USB et OpenVPN. Cependant, comme Jeff Atwood l'a mentionné ci-dessous, il ne prend en charge que les chipsets Broadcom.

J'utilise le mod Teddy Bear sur mon Netgear WNR3500L. J'utilise maintenant le mod Toastman, basé sur Teddy Bear, avec plus de fonctionnalités et de meilleures classes de QoS par défaut qui fonctionnent pour la plupart des gens.

Personnellement, la seule chose qui me manque dans Tomato est le support VLAN et la diffusion multi-SSID. (Le mod de Toastman les a maintenant tous les deux, ainsi que le portail captif pour le SSID secondaire).

J'ai trouvé que DD-WRT v24 sp2 build 15362 était très stable sur mon Netgear WNDR3700 v1 MAIS malgré une énorme quantité de temps passé à essayer de configurer à la fois la QoS et TCP Vegas (contrôle de la congestion) aucun mécanisme ne semble fonctionner sur cet excellent firmware pour le trafic entrant (je n'ai pas besoin de contrôle sortant car je n'utilise pas VOIP).

Par exemple, quelles que soient les options (Mac Control, Netmask, Service Control) que j'utilise dans mes tentatives pour hiérarchiser le trafic vidéo entrant et dé-prioriser le trafic torrent bit entrant, rien ne fonctionne. Je l'ai confirmé avec

• Commandes Telnet suggérées pour confirmer le fonctionnement QoS
• TCP Vegas

Conclusion: utilisez DD-WRT si vous voulez toutes les autres fonctionnalités (en particulier la diffusion de plusieurs SSID) mais utilisez Tomato si vous avez un chipset applicable (Tomato n'est pas disponible pour le WNDR3700 basé sur Atheros) et comme ses fonctionnalités QoS.

J'ai remarqué la même chose. Je ne peux pas trouver le message exact maintenant, mais en fouillant dans les forums, l'un des développeurs a déclaré que la qualité de service, comme elle fonctionne, était excellente pour les téléchargements, pas tant pour les téléchargements. Le raisonnement derrière cela est que le routeur contrôle le trafic sortant du réseau (liaison montante), mais pas le trafic entrant car il n'a aucun contrôle sur le flux entrant de données.

Je sais que vous n'êtes pas un grand fan de la navigation dans les messages du forum, mais vous voudrez peut-être y poster vos questions.