Was kann dazu führen, dass tc die Klassifizierung von Paketen beendet?

447
Seii

Mein Heimbüro verfügt über eine sehr begrenzte Internet-Bandbreite, daher muss ich QoS ziemlich stark verwenden, um den Verkehr zu klassifizieren. Ich verwende dazu FireHol und FireQOS, die im Wesentlichen die Befehle "iptables" und "tc" unter den Deckblättern generieren. Innerhalb der letzten zwei Wochen scheint dies aufgehört zu haben, da FireQOS keine Pakete mehr zeigt, die in Buckets klassifiziert werden.

Was kann dazu führen, dass tc die Klassifizierung von Paketen beendet? Wie gehe ich bei der Fehlerbehebung vor?

Router: Marvell EspressoBin
Betriebssystem: Arch Linux ARM
Kernel: 4.15.7-1 (aus dem Arch Linux ARM-Paket "linux-espressobin")

  • Verwendung von Konnemarken zur Verkehrsklassifizierung
  • Die Firewall scheint normal zu funktionieren und Pakete erwartungsgemäß zu markieren
  • Die Bandbreite ist auf einen Prozentsatz von max vorgedrosselt, um die Eingangs-QoS zu aktivieren
  • Externe Schnittstelle ist "extern", das dafür erstellte IFB-Gerät ist automatisch "extern-ifb".

Einzelheiten:

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
Laufen die Feuerlöcher noch? Irgendein Kernel-Update? vera vor 6 Jahren 0
@vera FireQOS läuft in der Tat noch, FireHOL ebenfalls. Ich habe aufgehört und beides im Rahmen früherer Bemühungen neu gestartet. Ich sehe keine offensichtlichen Probleme mit beiden. Der Kernel wurde in der Tat aktualisiert, also bin ich mir sicher, dass dies verwandt sein könnte - nur keine Ahnung, wie etwas behoben werden soll, bei dem keine Fehlernachrichten gefunden werden können. Seii vor 6 Jahren 0
Dies kann Gegenstand eines Problem- / Fehlerberichts für FireQoS sein (https://github.com/firehol/firehol/issues). Der Autor antwortet ziemlich schnell. vera vor 6 Jahren 0
@vera Ich denke ich werde einen Fehler nur für den Fall einreichen. Vielen Dank! Seii vor 6 Jahren 0

1 Antwort auf die Frage

0
Seii

Ich habe einen Fehler mit FireHol eingereicht, nur für den Fall, aber es scheint, dass der Täter tatsächlich mein Upgrade des iproute2Pakets war. Aus irgendeinem Grund konnte die Version 4.15.0-1im Arch Linux ARM-Repository nicht wie oben erwähnt Pakete klassifizieren, während die Version 4.14.1-2erfolgreich war. Im Moment verwende ich nur die ältere Version.