☰

Was könnte dazu führen, dass TC die Klassifizierung von Paketen einstellt?

tag-icon • tag-icon linux networking router iptables qos
Was könnte dazu führen, dass TC die Klassifizierung von Paketen einstellt?

In meinem Heimbüro ist die Internetbandbreite sehr begrenzt, daher muss ich QoS sehr stark nutzen, um den Datenverkehr zu klassifizieren. Dazu verwende ich FireHol und FireQOS, die im Grunde im Hintergrund die Befehle „iptables“ und „tc“ generieren. In den letzten zwei Wochen scheint dies nicht mehr zu funktionieren, da FireQOS keine Pakete mehr anzeigt, die in Buckets klassifiziert werden.

Was könnte dazu führen, dass TC die Klassifizierung von Paketen einstellt? Wie kann ich dieses Problem beheben?

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

  • Verwenden von Connmarks zur Verkehrsklassifizierung
  • Die Firewall scheint normal zu funktionieren und markiert Pakete wie erwartet
  • Die Bandbreite wird auf einen Prozentsatz des Maximums vorgedrosselt, um Ingress-QoS zu ermöglichen
  • Die externe Schnittstelle ist „extern“, das dafür automatisch erstellte IFB-Gerät ist „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)

Antwort1

Ich habeeinen Fehler gemeldetmit FireHol, nur für den Fall, aber es scheint, dass der Übeltäter tatsächlich mein Upgrade des iproute2Pakets war. Aus irgendeinem Grund 4.15.0-1konnte Version im Arch Linux ARM-Repository Pakete nicht wie erwähnt klassifizieren, während Version 4.14.1-2erfolgreich war. Im Moment werde ich einfach die ältere Version verwenden.

verwandte Informationen