Усунення несправностей з вбудованим програмним забезпеченням маршрутизатора dd-wrt QoS

Я використовував прошивку dd-wrt на своєму маршрутизаторі і мені це дуже подобається!

Але - я не впевнений, що якість обслуговування (QoS) працює на це. У мене це налаштовано так:

• http, порт 80 - Преміум
• bittorrent, порт 6969 - Навальний
• https, порт 443 - Преміум
• dns, порт 53 - Преміум

Відповідно до документації щодо якості , ці рівні:

пропускна здатність розподіляється виходячи з таких відсотків значень висхідної та низхідної лінії зв'язку для кожного класу:

• Звільнення: 100 Мбіт / с - ігнорує глобальні обмеження.
• Премія: 75% - 100%
• Експрес: 15% - 100%
• Стандарт: 10% - 100%
• Масова частина: 1,5% - 100%

Це, мабуть, не спрацьовує, однак - із зайнятими торентами я отримую великі паузи у веб-перегляді, який відстій!

Документація QoS дає кілька кроків для перевірки QoS ...

Що вам буде цікаво подивитися, це перший набір джерела і призначення IP, включаючи номери портів. Далі наявність l7proto та поле "позначка". Записи вказують на поточний пріоритет QoS з'єднання в реальному часі, застосований до них на основі поля "позначка". Значення "позначки" відповідають наступному

• Звільнення: 100
• Премія: 10
• Експрес: 20
• Стандарт: 30
• Навальна: 40
• (не відповідає QoS): 0

Ви можете побачити "mark = 0" для деяких служб l7proto, навіть якщо вони налаштовані у списку правил QoS. Це може означати, що система відповідності шарів 7 шару не відповідала новому або зміненому заголовку для цього протоколу. Зазвичай про це піклуються користувацькі сервіси на портових матчах.

На порту 6969 (бітторрент) Я бачу дивну суміш матеріалу з mark=0і mark=40як так

cat / proc / net / ip_conntrack

udp 17 105 src = 98.162.182.42 dst = 1.2.3.4 sport = 64512 dport = 6969 пакетів = 3 байти = 290 src = 10.0.0.2 dst = 98.162.182.42 sport = 6969 dport = 64512 пакетів = 4 байти = 202 [ЗАБЕЗПЕЧЕНО] mark = 0 secmark = 0 використання = 1
tcp 6 117 TIME_WAIT src = 98.248.173.174 dst = 1.2.3.4 sport = 51114 dport = 6969 пакетів = 12 байт = 704 src = 10.0.0.2 dst = 98.248.173.174 sport = 6969 dport = 51114 пакетів = 10 байт = 440 [ЗАСТАНОВЕНО ] позначка = 40 сек. = 0 використання = 1
tcp 6 598 Встановлено src = 165.132.128.201 dst = 1.2.3.4 sport = 57218 dport = 6969 пакетів = 8024 байт = 9919881 src = 10.0.0.2 dst = 165.132.128.201 sport = 6969 dport = 57218 пакетів = 4211 байт = 239607 [ЗАБЕЗПЕЧЕНО ] mark = 0 secmark = 0 використання = 1
tcp 6 586 ВСТАНОВЛЕНИЙ src = 68.46.9.24 dst = 1.2.3.4 sport = 64688 dport = 6969 пакетів = 6 байт = 490 src = 10.0.0.2 dst = 68.46.9.24 sport = 6969 dport = 64688 пакетів = 8 байт = 944 [ЗАЯВЛЕНО ] позначка = 40 сек. = 0 використання = 1
udp 17 45 src = 222.254.228.38 dst = 1.2.3.4 sport = 25438 dport = 6969 пакетів = 5 байт = 454 src = 10.0.0.2 dst = 222.254.228.38 sport = 6969 dport = 25438 пакетів = 3 байти = 154 [ЗАБЕЗПЕЧЕНО] mark = 0 secmark = 0 використання = 1

(повний файл видно на http://pastebin.com/AZE6EtWm )

Я трохи погрався з цим журналом, і я не бачу жодних шаблонів!

Чому деякі порти 6969 bittorrent трафікуються з тегами mark=0(не збігаються) QoS dd-wrt, а інші теги mark=40(масово) .. будь-які ідеї?

Хоча це лише формує вихідний трафік , цей відмінний сценарій QoS ( дзеркало на пастіні ) може бути корисним у блозі Алекса Райса. Пройшло кілька авторів і втілень. Не забудьте правильно встановити UPLINK, а також DEV. Для мене значення DEV за замовчуванням було невірним, використовуйте коментований $(nvram get wan_ifname)замість цього або правильне значення, виконане nvram get wan_iframeза допомогою SSH.

Крім того, замість того, щоб використовувати його, ви можете дублювати його конфігурацію в інтерфейсі QoS GUI. Ви побачите, що він використовує 1024: 65535 для масового трафіку, а інші параметри (80,22,3389 тощо) мають перевагу. Сценарій добре працює для мене і використовує HFSC як рекомендується.

Наприклад: QoS, встановлений на WAN, надсилає трафік висхідної лінії зв'язку в чергу чергової лінії зв'язку.
Потім зрозумійте, що цей патч не вдається, оскільки: Команди в сценарії rc_firewall не застосовуються в QoS

Ви можете вирішити проблему зі скриптом, який виконується після rc_firewall, як зазначено в квитку. Я особисто ввімкнув JFFS та розмістив сценарій із виправленням /jffs/etc/config/qos.ipup, таким же, як було зазначено.

Мені було зручно використовувати KiTTY та WinSCP . Ви можете запустити SSH в маршрутизатор за допомогою KiTTY для усунення несправностей / підтвердження, як у першому квитку, і запустити прямо в перегляд файлів на маршрутизаторі Start WinSCPкомандою під верхньою лівою піктограмою KiTTY. Якщо це не вдається (маршрутизатор за замовчуванням не працює SFTP), ви можете увімкнути FTP та підключитись вручну або просто додати файл за допомогою команд Unix. Не забудьте встановити дозвіл власника на виконання сценарію.

Я помітив, що багато людей скаржаться на те, що QoS не працює в DD-WRT, тому вони переходять на томат. Він прекрасно працює в Томаті (я його використовую). Помідор також має дуже гарні графіки, що корисно для налаштування ваших QoS налаштувань.

Мінус Tomato, порівняно з DD-WRT, полягає в тому, що він має менше функцій, хоча є кілька модних збірок, які додають певні речі, наприклад, USB-накопичувач та OpenVPN. Однак, як згадував нижче Джефф Етвуд, він підтримує лише чіпсети Broadcom.

Я використовую мод Teddy Bear на своєму Netgear WNR3500L. Зараз я використовую мод Toastman, який базується на Teddy Bear, з більшою кількістю функцій та кращими класами QoS за замовчуванням, які працюють для більшості людей.

Особисто мені єдине, що мені не вистачає в Tomato, - це підтримка VLAN та трансляція мульти-SSID. (Мод Toastman має їх як зараз, так і портал для захоплених вторинних SSID).

Я виявив, що збірка DD-WRT v24 sp2 15362 є дуже стабільною на моєму Netgear WNDR3700 v1, АЛЕ, незважаючи на величезну кількість часу, витраченого на налаштування QoS і TCP Vegas (контроль заторів), жоден механізм не працює на цій чудовій прошивці для вхідного трафіку (я не потребую вихідного контролю, оскільки я не використовую VOIP).

Наприклад, незалежно від того, які параметри (Mac Control, Netmask, Service Control) я використовую в своїх спробах визначити пріоритет вхідного відео трафіку та визначити пріоритет вхідного бітового потокового потоку, нічого не працює. Я це підтвердив

• Команди Telnet запропоновані для підтвердження роботи QoS
• TCP Вегас

Підсумок: Використовуйте DD-WRT, якщо ви хочете, щоб усі інші функції (зокрема, трансляція муліпле SSID), але використовуйте Tomato, якщо у вас є застосований чіпсет (Tomato не доступний для базується на Atheros WNDR3700) і подобається його функції QoS.

Я помітив те саме. Зараз я не можу знайти точну публікацію, але, копаючись по форумах, один із розробників заявив, що QoS як це чудово працює при завантаженні, не так у завантаженні. Причина цього полягає в тому, що маршрутизатор має контроль над трафіком, що виходить з мережі (висхідна лінія), але не трафіком, оскільки він не має контролю над вхідним потоком даних.

Я знаю, що ви не великий шанувальник перегляду публікацій на форумі, але ви можете розмістити свої запитання там.