Я отправил сообщение об ошибке в FireHol на всякий случай, но, похоже, виновником было мое обновление iproute2
пакета. По какой-то причине версия 4.15.0-1
в хранилище Arch Linux ARM не смогла классифицировать пакеты, как я уже упоминал, в то время как версия 4.14.1-2
была успешной. Сейчас я просто буду использовать старую версию.
Что может заставить tc перестать классифицировать пакеты?
384
Seii
В моем домашнем офисе пропускная способность интернета очень ограничена, поэтому мне приходится довольно сильно использовать QoS для классификации трафика. Для этого я использую FireHol и FireQOS, которые в основном генерируют команды "iptables" и "tc" под прикрытием. В последние две недели это, похоже, перестало работать, так как FireQOS больше не показывает какие-либо пакеты, классифицированные по сегментам.
Что может заставить tc перестать классифицировать пакеты? Как бы я пошел об устранении неполадок этого?
Маршрутизатор: Marvell EspressoBin
ОС: Arch Linux ARM
Ядро: 4.15.7-1 (из пакета Arch Linux ARM "linux-espressobin")
- Использование connmarks для классификации трафика
- Брандмауэр, кажется, работает нормально и маркирует пакеты, как и ожидалось
- Полоса пропускания предварительно регулируется в процентах от максимума, чтобы обеспечить входное QoS
- Внешний интерфейс "extern", автоматически создается устройство IFB для него "extern-ifb"
Подробности:
FIREQOS SUMMARY OF CLASSIFICATIONS: ------------------------------------- : interface extern receive input rate 3217kbps adsl remote bridged-llc (extern-ifb, 26353kbit, mtu 1500, quantum 1500, minrate 263kbit) : class voip commit 90kbps prio 2 (1:11, 737/26353kbit, prio 2) : class work commit 40% prio 3 (1:12, 10541/26353kbit, prio 3) : class default (1:8000, 263/26353kbit, prio 4) : committed rate 11541kbit (43%), the remaining 14811kbit will be spare bandwidth. : interface extern transmit output rate 570kbps adsl remote bridged-llc (extern, 4669kbit, mtu 1500, quantum 1500, minrate 46kbit) : class voip commit 90kbps prio 2 (1:11, 737/4669kbit, prio 2) : class work commit 55% prio 3 (1:12, 2567/4669kbit, prio 3) : class default (1:8000, 46/4669kbit, prio 4) : committed rate 3350kbit (71%), the remaining 1318kbit will be spare bandwidth. TC QDISC SHOW DEV EXTERN --------------------------- qdisc htb 1: root refcnt 2 r2q 3 default 32768 direct_packets_stat 1 direct_qlen 1000 qdisc fq_codel 12: parent 1:12 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 11: parent 1:11 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 13: parent 1:8000 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc ingress ffff: parent ffff:fff1 ---------------- TC CLASS SHOW DEV EXTERN -------------------------- class htb 1:11 parent 1:1 leaf 11: prio rate 737Kbit ceil 4669Kbit burst 1599b cburst 1599b class htb 1:8000 parent 1:1 leaf 13: prio rate 46Kbit ceil 4669Kbit burst 1599b cburst 1599b class htb 1:1 root rate 4669Kbit ceil 4669Kbit burst 1599b cburst 1599b class htb 1:12 parent 1:1 leaf 12: prio rate 2567Kbit ceil 4669Kbit burst 1599b cburst 1599b class fq_codel 13:df parent 13: class fq_codel 13:fd parent 13: class fq_codel 13:3dd parent 13: class fq_codel 13:df parent 13: class fq_codel 13:fd parent 13: class fq_codel 13:3dd parent 13: TC FILTER SHOW DEV EXTERN ---------------------------- filter parent 1: protocol ip pref 10 u32 chain 0 filter parent 1: protocol ip pref 10 u32 chain 0 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:11 not_in_hw mark 0x0004 0x003f (success 0) filter parent 1: protocol ip pref 20 u32 chain 0 filter parent 1: protocol ip pref 20 u32 chain 0 fh 801: ht divisor 1 filter parent 1: protocol ip pref 20 u32 chain 0 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:11 not_in_hw match 00110000/00ff0000 at 8 match c0a8002c/ffffffff at 12 filter parent 1: protocol ip pref 30 u32 chain 0 filter parent 1: protocol ip pref 30 u32 chain 0 fh 802: ht divisor 1 filter parent 1: protocol ip pref 30 u32 chain 0 fh 802::800 order 2048 key ht 802 bkt 0 flowid 1:12 not_in_hw mark 0x0003 0x003f (success 0)
Fireqos все еще работает? Любое обновление ядра?
vera 6 лет назад
0
@vera FireQOS действительно все еще работает, FireHOL также. Я остановился и перезапустился как часть прошлых усилий. Я не вижу никаких очевидных проблем ни с одним из них. Ядро действительно было обновлено, так что я уверен, что это может быть связано - просто не знаю, как устранить неполадки, если нет сообщений об ошибках, которые можно найти.
Seii 6 лет назад
0
Это может быть предметом сообщения о проблеме / ошибке для FireQoS (https://github.com/firehol/firehol/issues). Автор отвечает довольно быстро.
vera 6 лет назад
0
@vera Я думаю, я сообщу об ошибке на всякий случай. Спасибо!
Seii 6 лет назад
0
1 ответ на вопрос
0
Seii
Похожие вопросы
-
9
В чем разница между командами "su -s" и "sudo -s"?
-
4
Требуется хороший бесплатный образ Ubuntu Server VMWare
-
4
Каковы различия между основными дистрибутивами Linux? Я замечу?
-
-
2
Ограничить использование процессора для Flash в Firefox?
-
2
Как мне заставить мой микрофон работать под Debian GNOME?
-
2
Конки установки - образцы / идеи?
-
2
Windows 7 Home Premium запоминает пароли общего доступа к сети?
-
3
Каковы различия между оконными менеджерами Linux?
-
5
Существуют ли беспроводные маршрутизаторы, которые позволяют контролировать и регулировать пропускну...
-
5
Поделитесь XP сетевым подключением без перезагрузки?