Что может заставить 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) 
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

Я отправил сообщение об ошибке в FireHol на всякий случай, но, похоже, виновником было мое обновление iproute2пакета. По какой-то причине версия 4.15.0-1в хранилище Arch Linux ARM не смогла классифицировать пакеты, как я уже упоминал, в то время как версия 4.14.1-2была успешной. Сейчас я просто буду использовать старую версию.

Похожие вопросы