Fehlerbehebung bei der Firmware-QoS des dd-wrt-Routers

Ich habe die dd-wrt- Firmware auf meinem Router verwendet und es gefällt mir sehr gut!

Aber - ich bin mir nicht sicher, ob die Servicequalität (Quality of Service, QoS) daran arbeitet. Ich habe es wie folgt eingerichtet:

• http, port 80 - Premium
• Bittorrent, Port 6969 - Bulk
• https, Port 443 - Premium
• DNS, Port 53 - Premium

Gemäß der QoS-Dokumentation sind diese Ebenen:

Die Bandbreite wird basierend auf den folgenden Prozentsätzen der Uplink- und Downlink-Werte für jede Klasse zugewiesen:

• Ausnahme: 100 MBit / s - ignoriert globale Grenzwerte.
• Prämie: 75% - 100%
• Express: 15% - 100%
• Standard: 10% - 100%
• Masse: 1,5% - 100%

Dies scheint jedoch nicht ganz zu funktionieren - mit viel losem Strom bekomme ich große Pausen beim Surfen im Internet, was scheiße ist!

Die QoS-Dokumentation enthält einige Schritte zur Überprüfung der QoS ...

Was Sie interessiert, wird der erste Satz von Quell- und Ziel-IP sein, einschließlich der Portnummern. Als nächstes das Vorhandensein von l7proto und das "mark" -Feld. Die Einträge geben die aktuelle QoS-Priorität der Live-Verbindung an, die basierend auf dem Feld "Mark" auf sie angewendet wurde. Die "mark" -Werte entsprechen den folgenden

• Ausnahme: 100
• Prämie: 10
• Express: 20
• Standard: 30
• Bulk: 40
• (Keine QoS-Übereinstimmung): 0

Möglicherweise wird für einige l7proto-Dienste "mark = 0" angezeigt, obwohl sie in der Liste der QoS-Regeln konfiguriert sind. Dies kann bedeuten, dass das Schicht-7-Mustervergleichssystem keinem neuen oder geänderten Header für dieses Protokoll entspricht. Um diese kümmert sich in der Regel der Zolldienst für Hafenstreichhölzer.

Auf Port 6969 (bittorrent) sehe ich eine komische Mischung von Sachen mit mark=0und mark=40wie so

cat / proc / net / ip_conntrack

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

(vollständige Datei sichtbar unter http://pastebin.com/AZE6EtWm )

Ich habe eine Weile mit diesem Baumstamm rumgespielt und sehe keine Muster!

Warum wird ein Teil des bittorrent-Datenverkehrs von Port 6969 mark=0durch die QoS von dd-wrt markiert (nicht abgeglichen), während andere mit mark=40(Bulk) gekennzeichnet sind. Irgendwelche Ideen?

Obwohl dies nur den ausgehenden Datenverkehr beeinflusst , ist dieses hervorragende QoS-Skript ( Spiegel auf Pastebin ) in Alex Rices Blog möglicherweise hilfreich. Es hat mehrere Autoren und Inkarnationen durchgemacht. Stellen Sie sicher, dass UPLINK und DEV korrekt eingestellt sind. Für mich war der Standardwert für DEV falsch, verwenden Sie $(nvram get wan_ifname)stattdessen den kommentierten oder den korrekten Wert für die Ausführung nvram get wan_iframeüber SSH.

Anstatt es zu verwenden, können Sie auch seine Konfiguration in der QoS-GUI duplizieren. Sie werden sehen, dass 1024: 65535 für den Massenverkehr verwendet wird, wobei die anderen Einstellungen (80, 22, 3389 usw.) Vorrang haben. Das Skript funktioniert gut für mich und verwendet, wie empfohlen, HFSC.

Zum Beispiel: QoS auf WAN gesetzt sendet Uplink-Verkehr zur Downlink-Warteschlange.
Dann wird klar, dass dieser Patch aus folgenden Gründen fehlschlägt: Befehle im Skript rc_firewall werden in QoS nicht angewendet

Sie können das Problem mit einem Skript umgehen, das wie im Ticket angegeben nach rc_firewall ausgeführt wird . Am Ende habe ich persönlich JFFS aktiviert und das Skript mit dem Fix darin platziert /jffs/etc/config/qos.ipup, wie bereits erwähnt.

Ich fand es bequem, KiTTY und WinSCP zu verwenden . Sie können mit KiTTY eine SSH-Verbindung zum Router herstellen, um Fehler wie im ersten Ticket zu beheben / zu überprüfen, und mit dem Start WinSCPBefehl unter dem Symbol oben links von KiTTY direkt das Durchsuchen von Dateien auf dem Router starten. Wenn dies fehlschlägt (der Router führt standardmäßig kein SFTP aus), können Sie FTP aktivieren und manuell eine Verbindung herstellen oder einfach die Datei mit Unix-Befehlen hinzufügen. Denken Sie daran, die Ausführungsberechtigung des Besitzers für das Skript festzulegen.

Ich habe bemerkt, dass sich viele Leute über QoS beschweren, das nicht in DD-WRT funktioniert, und stattdessen zu Tomato wechseln. Es funktioniert gut in Tomate (ich benutze es). Tomate hat auch sehr schöne Grafiken, die zum Anpassen Ihrer QoS-Einstellungen nützlich sind.

Der Nachteil von Tomato im Vergleich zu DD-WRT ist, dass es weniger Funktionen hat, obwohl es einige Mod-Builds gibt, die bestimmte Dinge wie USB-Speicher und OpenVPN hinzufügen. Wie Jeff Atwood weiter unten erwähnte, werden jedoch nur Broadcom-Chipsätze unterstützt.

Ich benutze den Teddy Bear Mod auf meinem Netgear WNR3500L. Ich benutze jetzt den Toastman-Mod, der auf Teddy Bear basiert, mit mehr Funktionen und besseren QoS-Standardklassen, die für die meisten Leute funktionieren.

Persönlich fehlen mir in Tomato nur die VLAN-Unterstützung und die Übertragung mehrerer SSIDs. (Toastmans Mod hat sie jetzt beide, sowie Captive Portal für die sekundäre SSID).

Ich habe festgestellt, dass DD-WRT v24 sp2 Build 15362 auf meinem Netgear WNDR3700 v1 sehr stabil ist, ABER trotz der enormen Zeit, die für die Einrichtung von QoS und TCP Vegas (Überlastungskontrolle) aufgewendet wurde, scheint keiner der beiden Mechanismen auf dieser ausgezeichneten Firmware zu funktionieren für eingehenden Datenverkehr (ich brauche keine ausgehende Kontrolle, da ich kein VOIP verwende).

Egal welche Optionen (Mac-Steuerung, Netzmaske, Dienststeuerung) ich verwende, um eingehenden Videodatenverkehr zu priorisieren und eingehenden Bit-Torrent-Datenverkehr zu deaktivieren, funktioniert nichts. Ich habe dies mit bestätigt

• Vorgeschlagene Telnet-Befehle zur Bestätigung des QoS-Vorgangs
• TCP Vegas

Fazit: Verwenden Sie DD-WRT, wenn Sie alle anderen Funktionen (insbesondere die Übertragung mehrerer SSIDs) möchten, aber verwenden Sie Tomato, wenn Sie einen geeigneten Chipsatz haben (Tomato ist für den Atheros-basierten WNDR3700 nicht verfügbar) und dessen QoS-Funktionen mögen.

Mir ist dasselbe aufgefallen. Ich kann den genauen Beitrag jetzt nicht finden, aber beim Durchstöbern der Foren gab einer der Entwickler an, dass QoS beim Hochladen großartig funktioniert, nicht so sehr beim Herunterladen. Der Grund dafür ist, dass der Router die Kontrolle über den aus dem Netzwerk ausgehenden Datenverkehr (Uplink) hat, nicht jedoch über den eingehenden Datenverkehr, da er keine Kontrolle über den eingehenden Datenfluss hat.

Ich weiß, dass Sie kein großer Fan des Durchsuchens von Forenbeiträgen sind, aber Sie möchten vielleicht Ihre Fragen dort posten.