Rozwiązywanie problemów z QoS oprogramowania wewnętrznego routera dd-wrt

Korzystam z oprogramowania dd-wrt na routerze i bardzo mi się podoba!

Ale - nie jestem pewien, czy jakość usługi (QoS) działa na tym. Mam to ustawione w następujący sposób:

• http, port 80 - Premium
• bittorrent, port 6969 - luzem
• https, port 443 - Premium
• dns, port 53 - Premium

Zgodnie z dokumentacją QoS te poziomy to:

przepustowość jest przydzielana na podstawie następujących wartości procentowych wartości łącza w górę i łącza w dół dla każdej klasy:

• Wyjątek: 100 Mb / s - ignoruje globalne limity.
• Premium: 75% - 100%
• Ekspresowa: 15% - 100%
• Standard: 10% - 100%
• Luzem: 1,5% - 100%

Nie wydaje się to jednak do końca działać - przy zajętych torrentach mam poważne przerwy w przeglądaniu sieci, co jest do bani!

Dokumentacja QoS zawiera pewne kroki, aby sprawdzić QoS ...

Będziesz zainteresowany pierwszym zestawem źródłowego i docelowego adresu IP, w tym numerów portów. Następnie obecność l7proto i pole „mark”. Wpisy wskazują bieżący zastosowany na nich priorytet QoS połączenia na podstawie pola „znak”. Wartości „znacznika” odpowiadają poniższym

• Zwolniony: 100
• Premium: 10
• Ekspres: 20
• Standard: 30
• Luzem: 40
• (bez dopasowania QoS): 0

Możesz zobaczyć „mark = 0” dla niektórych usług l7proto, mimo że są one skonfigurowane na liście reguł QoS. Może to oznaczać, że system dopasowywania wzorca warstwy 7 nie pasuje do nowego lub zmienionego nagłówka dla tego protokołu. Zwykle zajmą się nimi usługi niestandardowe dotyczące meczów portów.

Na porcie 6969 (bittorrent) widzę dziwną mieszankę rzeczy mark=0i mark=40tak dalej

cat / proc / net / ip_conntrack

udp 17105 src = 98.162.182.42 dst = 1.2.3.4 sport = 64512 dport = 6969 pakietów = 3 bajty = 290 src = 10.0.0.2 dst = 98.162.182.42 sport = 6969 dport = 64512 pakietów = 4 bajty = 202 [ZAPEWNIONE] 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 pakietów = 12 bajtów = 704 src = 10.0.0.2 dst = 98.248.173.174 sport = 6969 dport = 51114 pakietów = 10 bajtów = 440 [ZAPEWNIONY ] znak = 40 sekund = 0 użycie = 1
tcp 6598 ESTABLISHED src = 165.132.128.201 dst = 1.2.3.4 sport = 57218 dport = 6969 pakietów = 8024 bajtów = 9919881 src = 10.0.0.2 dst = 165.132.128.201 sport = 6969 dport = 57218 pakietów = 4211 bajtów = 239607 [ASSURED ] mark = 0 secmark = 0 use = 1
tcp 6586 ESTABLISHED src = 68.46.9.24 dst = 1.2.3.4 sport = 64688 dport = 6969 pakietów = 6 bajtów = 490 src = 10.0.0.2 dst = 68.46.9.24 sport = 6969 dport = 64688 pakietów = 8 bajtów = 944 [ASSURED ] znak = 40 sekund = 0 użycie = 1
udp 17 45 src = 222.254.228.38 dst = 1.2.3.4 sport = 25438 dport = 6969 pakietów = 5 bajtów = 454 src = 10.0.0.2 dst = 222.254.228.38 sport = 6969 dport = 25438 pakietów = 3 bajty = 154 [ZAPEWNIONE] mark = 0 secmark = 0 use = 1

(pełny plik widoczny na stronie http://pastebin.com/AZE6EtWm )

Od jakiegoś czasu bawię się tym dziennikiem i nie widzę żadnych wzorów!

Dlaczego niektóre ruchy bittorrent dla portu 6969 są oznaczone mark=0(niepasowane) przez QoS dd-wrt, podczas gdy inne są oznaczone mark=40(luzem)… jakieś pomysły?

Chociaż kształtuje on tylko ruch wychodzący , ten doskonały skrypt QoS ( dublowanie na pastebin ) może być przydatny na blogu Alexa Rice'a. Odbyło się to przez kilku autorów i inkarnacje. Upewnij się, że poprawnie ustawiłeś UPLINK, a także DEV. Dla mnie domyślna wartość DEV była niepoprawna, $(nvram get wan_ifname)zamiast tego użyj skomentowanego lub poprawnej wartości z wykonania nvram get wan_iframeprzez SSH.

Zamiast używać go, możesz powielić jego konfigurację w graficznym interfejsie QoS. Zobaczysz, że używa 1024: 65535 do masowego ruchu, przy czym inne ustawienia (80, 22, 3389 itp.) Mają pierwszeństwo. Skrypt działa dla mnie dobrze i używa HFSC zgodnie z zaleceniami.

Na przykład: QoS ustawiony na WAN wysyła ruch w łączu w górę do kolejki w dół, a
następnie zdaj sobie sprawę, że ta poprawka się nie powiedzie, ponieważ: Polecenia w skrypcie rc_firewall nie są stosowane w QoS

Możesz obejść ten problem ze skryptem, który wykonuje się po rc_firewall, jak zaznaczono w bilecie. Osobiście skończyłem włączanie JFFS i umieszczanie skryptu z poprawką /jffs/etc/config/qos.ipup, tak jak wspomniano.

Uznałem, że wygodnie jest używać KiTTY i WinSCP . Możesz włączyć SSH do routera za pomocą KiTTY, aby rozwiązać problemy / zweryfikować jak w pierwszym zgłoszeniu, i uruchomić bezpośrednio przeglądanie plików na routerze za pomocą Start WinSCPpolecenia pod lewą górną ikoną KiTTY. Jeśli to się nie powiedzie (router nie obsługuje domyślnie SFTP), możesz włączyć FTP i połączyć się ręcznie, lub po prostu dodać plik za pomocą poleceń Uniksa. Pamiętaj, aby ustawić uprawnienia właściciela do wykonywania skryptu.

Zauważyłem, że wiele osób narzeka na brak QoS w DD-WRT, więc zamiast tego przechodzą na Tomato. Działa dobrze w Pomidorze (używam go). Pomidor ma również bardzo ładne wykresy, które są przydatne do dostosowywania ustawień QoS.

Minusem Tomato, w porównaniu do DD-WRT, jest to, że ma mniej funkcji, chociaż istnieje kilka kompilacji modów, które dodają pewne rzeczy, takie jak pamięć USB i OpenVPN. Jednak, jak wspomniano poniżej Jeff Atwood, obsługuje tylko chipsety Broadcom.

Używam modu Teddy Bear na moim Netgear WNR3500L. Teraz używam modu Toastman, który jest oparty na Teddy Bear, z większą liczbą funkcji i lepszymi domyślnymi klasami QoS, które działają dla większości ludzi.

Osobiście jedyne, czego mi brakuje w Tomato, to obsługa VLAN i transmisja wielu SSID. (Mod Toastmana ma je teraz zarówno, jak i Captive Portal dla dodatkowego identyfikatora SSID).

Odkryłem, że DD-WRT v24 sp2 build 15362 jest bardzo stabilny na moim Netgear WNDR3700 v1 ALE pomimo ogromnej ilości czasu poświęconego na konfigurację zarówno QoS, jak i TCP Vegas (kontrola przeciążenia), żaden mechanizm nie wydaje się działać na tym doskonałym oprogramowaniu dla ruchu przychodzącego (nie potrzebuję kontroli ruchu wychodzącego, ponieważ nie używam VOIP).

Na przykład, bez względu na to, jakie opcje (Mac Control, maska ​​sieci, kontrola usług) używam w moich próbach ustalania priorytetów przychodzącego ruchu wideo i bez priorytetów przychodzącego ruchu bitowego torrentów nic nie działa. Potwierdziłem to za pomocą

• Zalecane polecenia Telnet do potwierdzania działania QoS
• TCP Vegas

Konkluzja: Użyj DD-WRT, jeśli chcesz mieć wszystkie inne funkcje (szczególnie rozgłaszanie wielu identyfikatorów SSID), ale użyj Tomato, jeśli masz odpowiedni chipset (Tomato nie jest dostępny dla WNDR3700 opartego na Atheros) i podoba ci się jego funkcje QoS.

Zauważyłem to samo. Nie mogę teraz znaleźć dokładnego postu, ale przeglądając fora jeden z twórców stwierdził, że QoS działa świetnie w przypadku przesyłania, a nie tyle w przypadku pobierania. Wynika to z faktu, że router ma kontrolę nad ruchem wychodzącym z sieci (łącze uplink), ale nie z ruchem przychodzącym, ponieważ nie ma kontroli nad przychodzącym strumieniem danych.

Wiem, że nie jesteś wielkim fanem przeglądania postów na forum, ale możesz tam zadawać pytania.