Solución de problemas de QoS del firmware del router dd-wrt

¡He estado usando el firmware dd-wrt en mi enrutador y me gusta mucho!

Pero no estoy seguro de que la calidad del servicio (QoS) esté funcionando en ello. Lo tengo configurado de la siguiente manera:

• http, puerto 80 - Premium
• Bittorrent, puerto 6969 - Granel
• https, puerto 443 - Premium
• dns, puerto 53 - Premium

Según la documentación de QoS , estos niveles son:

el ancho de banda se asigna en función de los siguientes porcentajes de valores de enlace ascendente y enlace descendente para cada clase:

• Exento: 100mbps: ignora los límites globales.
• Premium: 75% - 100%
• Expreso: 15% - 100%
• Estándar: 10% - 100%
• Granel: 1.5% - 100%

Sin embargo, esto no parece funcionar del todo: con los torrents ocupados en marcha, obtengo pausas importantes en mi navegación web, ¡lo que apesta!

La documentación de QoS proporciona algunos pasos para verificar la QoS ...

Lo que le interesará ver será el primer conjunto de IP de origen y destino, incluidos los números de puerto. Luego la presencia de l7proto y el campo "marca". Las entradas indican la prioridad actual de QoS de conexión en vivo aplicada en ellas en función del campo "marca". Los valores de "marca" corresponden a lo siguiente

• Exento: 100
• Premium: 10
• Expreso: 20
• Estándar: 30
• Granel: 40
• (sin QoS coincidente): 0

Puede ver "mark = 0" para algunos servicios de l7proto aunque estén configurados en la lista de reglas de QoS. Esto puede significar que el sistema de coincidencia de patrones de la capa 7 no coincide con un encabezado nuevo o modificado para ese protocolo. El servicio personalizado en los partidos de puerto generalmente se encargará de estos.

En el puerto 6969 (bittorrent) veo una extraña mezcla de cosas con mark=0y mark=40así

cat / proc / net / ip_conntrack

udp 17105 src = 98.162.182.42 dst = 1.2.3.4 sport = 64512 dport = 6969 paquetes = 3 bytes = 290 src = 10.0.0.2 dst = 98.162.182.42 sport = 6969 dport = 64512 paquetes = 4 bytes = 202 [ASEGURADO] marca = 0 segmark = 0 uso = 1
tcp 6117 TIME_WAIT src = 98.248.173.174 dst = 1.2.3.4 sport = 51114 dport = 6969 paquetes = 12 bytes = 704 src = 10.0.0.2 dst = 98.248.173.174 sport = 6969 dport = 51114 paquetes = 10 bytes = 440 [ASEGURADO ] marca = 40 segmark = 0 uso = 1
tcp 6 598 ESTABLECIDO src = 165.132.128.201 dst = 1.2.3.4 deporte = 57218 dport = 6969 paquetes = 8024 bytes = 9919881 src = 10.0.0.2 dst = 165.132.128.201 deporte = 6969 dport = 57218 paquetes = 4211 bytes = 239607 [ASEGURADO ] marca = 0 segmark = 0 uso = 1
tcp 6 586 ESTABLECIDO src = 68.46.9.24 dst = 1.2.3.4 deporte = 64688 dport = 6969 paquetes = 6 bytes = 490 src = 10.0.0.2 dst = 68.46.9.24 deporte = 6969 dport = 64688 paquetes = 8 bytes = 944 [ASEGURADO ] marca = 40 segmark = 0 uso = 1
udp 17 45 src = 222.254.228.38 dst = 1.2.3.4 sport = 25438 dport = 6969 paquetes = 5 bytes = 454 src = 10.0.0.2 dst = 222.254.228.38 sport = 6969 dport = 25438 paquetes = 3 bytes = 154 [ASEGURADO] marca = 0 segmark = 0 uso = 1

(archivo completo visible en http://pastebin.com/AZE6EtWm )

¡He estado jugando con este registro durante un tiempo y no puedo ver ningún patrón!

¿Por qué el tráfico de bittorrent del puerto 6969 está etiquetado mark=0(no coincide) por la calidad del servicio de dd-wrt, mientras que otros están etiquetados mark=40(a granel) ... alguna idea?

Aunque solo da forma al tráfico saliente , puede encontrar útil este excelente script de QoS ( espejo en pastebin ) en el blog de Alex Rice. Ha pasado por varios autores y encarnaciones. Asegúrese de configurar UPLINK y DEV correctamente. Para mí, el valor predeterminado para DEV era incorrecto, use el comentado en su $(nvram get wan_ifname)lugar, o el valor correcto de la ejecución a nvram get wan_iframetravés de SSH.

Además, en lugar de usarlo, puede duplicar su configuración dentro de la GUI de QoS. Verá que usa 1024: 65535 para el tráfico masivo, con la otra configuración (80,22,3389, etc.) teniendo prioridad. El script funciona bien para mí y usa HFSC como se recomienda.

Por ejemplo: QoS configurado en WAN envía tráfico de enlace ascendente a la cola de enlace descendente.
Luego, tenga en cuenta que este parche falla porque: Los comandos en el script rc_firewall no se aplican en QoS

Puede solucionar el problema con un script que se ejecuta después de rc_firewall como se indica en el ticket. Personalmente terminé habilitando JFFS y colocando el script con la solución /jffs/etc/config/qos.ipup, como se mencionó.

Me pareció conveniente usar KiTTY y WinSCP . Puede SSH en el enrutador con KiTTY para solucionar problemas / verificar como en el primer ticket, e iniciar directamente la exploración de archivos en el enrutador con el Start WinSCPcomando debajo del icono superior izquierdo de KiTTY. Si esto falla (el enrutador no está ejecutando SFTP por defecto) puede habilitar FTP y conectarse manualmente, o simplemente agregar el archivo con comandos de Unix. Recuerde configurar el permiso de ejecución del propietario en el script.

Me di cuenta de que muchas personas se quejan de que QoS no funciona en DD-WRT, por lo que cambian a Tomato. Funciona bien en tomate (lo uso). Tomato también tiene gráficos muy agradables, lo cual es útil para ajustar la configuración de QoS.

La desventaja de Tomato, en comparación con DD-WRT, es que tiene menos funciones, aunque hay algunas compilaciones de mods que agregan ciertas cosas, como almacenamiento USB y OpenVPN. Sin embargo, como Jeff Atwood menciona a continuación, solo es compatible con los conjuntos de chips Broadcom.

Utilizo el mod Teddy Bear en mi Netgear WNR3500L. Ahora uso el mod Toastman, que se basa en Teddy Bear, con más funciones y mejores clases de QoS predeterminadas que funcionan para la mayoría de las personas.

Personalmente, lo único que me falta en Tomato es el soporte de VLAN y la transmisión de múltiples SSID. (El mod de Toastman los tiene a ambos ahora, así como el Portal cautivo para el SSID secundario).

He descubierto que DD-WRT v24 sp2 build 15362 es muy estable en mi Netgear WNDR3700 v1 PERO a pesar de la gran cantidad de tiempo que pasé tratando de configurar QoS y TCP Vegas (control de congestión) ninguno de los mecanismos parece estar funcionando en este excelente firmware para el tráfico entrante (no necesito control saliente ya que no uso VOIP).

Por ejemplo, no importa qué opciones (Mac Control, Máscara de red, Control de servicio) utilizo en mis intentos de priorizar el tráfico de video entrante y des-priorizar el tráfico de torrente de bits entrantes, nada funciona. He confirmado esto con

• Comandos Telnet sugeridos para confirmar la operación de QoS
• TCP Vegas

En pocas palabras: use DD-WRT si desea todas las demás funciones (particularmente la transmisión de múltiples SSID) pero use Tomato si tiene un conjunto de chips aplicable (Tomato no está disponible para el WNDR3700 basado en Atheros) y le gustan sus características de QoS.

Me di cuenta de lo mismo. No puedo encontrar la publicación exacta ahora, pero al examinar los foros, uno de los desarrolladores declaró que QoS, tal como es, funciona muy bien en las cargas, no tanto en las descargas. El razonamiento detrás de esto es que el enrutador tiene el control del tráfico que sale de la red (enlace ascendente), pero no el tráfico que entra ya que no tiene control sobre el flujo de datos entrantes.

Sé que no eres un gran fanático de navegar por las publicaciones del foro, pero es posible que quieras publicar tus preguntas allí.