CAKE QoS Script (OpenWrt)

Looks cool. One thing though - so that includes a map between a special user config and nftables? But why not just have the user edit nftables directly? Either something could go wrong in the mapping or nftables coding seems easy enough?

3 Likes

can we disable this script in the download direction i tried it but stopping the script only works with upload as mentioned above thank you

1 Like

because i have a problem with pppoe thats keeps disconnecting ,so i switched from regular bridge mode to this method poor man's bridge mode
so my question is do these dscp markings still work with this method ? considering my gateway(non openwrt) has its own qos which is disabled but im wondering if this messes with the markings?

i was trying to capture my gaming packets
here is a picture from wireshark using sshdump


why the same packet have diffrent marking ?

Look at the destination address, the CS0 marked packet goes to 192.168.2.3, the CS4 marked packet goes to 192.168.1.144, so these are clearly different flows. You will need to look into your marking rules to decide whether that makes sense or not...

So sqm-scripts itself leverages OpenWrt's hotplug system to automatically restart if an interface reconnects, not sure how/if that works with veth interfaces...

192.168.1.244 is my pc LAN adress that im using for gaming and 192.168.2.3 is my WAN(eth0.2) adress
are my markings working right according to wireshark? considering i want my game packets to be marked with CS4

Well, assuming it is the same packet it's DSCP was changed from CS0 to CS4, and roughly where you expect it after the network address translation. So far so good.

Question: How did you set-up this capture? I tend to capture from individual interfaces and hence do not see the same packet twice?

However that does not strictly prove that the marking happened before your priority scheduler got hold of the packet. For this you should also look at the output of tc -s qdisc and confirm that the byte and packetcounter of the priority tier carrying CS4 increases when you see such packets in your captures.

There are two things to consider here:
a) are the re-marking rules work as documented
b) do your marking rules adequately describe your intent

Not much I can say for any of those questions (I have no first-hand experience with the script of this thread).

im using remote ssh capture feature with username and password that allows wireshark to sniff traffic directly from router .

root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 357989272 bytes 543773 pkt (dropped 0, overlimits 0 requeues 5)
 backlog 0b 0p requeues 5
  maxpacket 1399 drop_overlimit 0 new_flow_count 30 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev wlan0 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 800c: dev eth0.2 root refcnt 2 bandwidth 800Kbit diffserv8 dual-srchost nat wash ack-filter split-gso rtt 47ms atm overhead 40
 Sent 1105468 bytes 7618 pkt (dropped 255, overlimits 5500 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 89440b of 4Mb
 capacity estimate: 800Kbit
 min/max network layer size:           28 /    1492
 min/max overhead-adjusted size:      106 /    1696
 average network hdr offset:           14

                  Tin 0        Tin 1        Tin 2        Tin 3        Tin 4        Tin 5        Tin 6        Tin 7
  thresh        800Kbit      700Kbit    612496bit    535928bit    468936bit    410312bit    359016bit    314136bit
  target         22.8ms         26ms       29.7ms         34ms       38.8ms       44.4ms       50.7ms         58ms
  interval       67.4ms       70.7ms       74.4ms       78.6ms       83.5ms         89ms        101ms        116ms
  pk_delay          0us       97.6ms       5.42ms       20.2ms         40us          0us       1.18ms       2.03ms
  av_delay          0us        3.5ms        262us       3.65ms          1us          0us         86us         39us
  sp_delay          0us       1.22ms         31us         80us          1us          0us         28us         21us
  backlog            0b           0b           0b           0b           0b           0b           0b           0b
  pkts                0           46         4622          566           10            0         2549           80
  bytes               0        59658       321666       192623          900            0       549271         5892
  way_inds            0            0            0            0            0            0           21            0
  way_miss            0           11          225           58           10            0          104            4
  way_cols            0            0            0            0            0            0            0            0
  drops               0            2            0            0            0            0            1            0
  marks               0            0            0            0            0            0            0            0
  ack_drop            0            0          252            0            0            0            0            0
  sp_flows            0            0            1            1            0            0            0            1
  bk_flows            0            0            0            0            0            0            1            0
  un_flows            0            0            0            0            0            0            0            0
  max_len             0         5864         1506         1270           90            0         1342          393
  quantum           300          300          300          300          300          300          300          300

qdisc cake 800b: dev br-lan root refcnt 2 bandwidth 12Mbit diffserv8 dual-dsthost nonat nowash ingress no-ack-filter split-gso rtt 47ms atm overhead 40
 Sent 74528683 bytes 56463 pkt (dropped 414, overlimits 81583 requeues 0)
 backlog 7530b 5p requeues 0
 memory used: 183276b of 4Mb
 capacity estimate: 12Mbit
 min/max network layer size:           28 /    1492
 min/max overhead-adjusted size:      106 /    1696
 average network hdr offset:           14

                  Tin 0        Tin 1        Tin 2        Tin 3        Tin 4        Tin 5        Tin 6        Tin 7
  thresh         12Mbit    10500Kbit     9187Kbit     8039Kbit     7034Kbit     6154Kbit     5385Kbit     4712Kbit
  target         2.35ms       2.35ms       2.35ms       2.35ms       2.58ms       2.95ms       3.37ms       3.85ms
  interval         47ms         47ms         47ms         47ms       47.2ms       47.6ms         48ms       48.5ms
  pk_delay          0us          0us       6.39ms          0us        809us          0us       2.51ms         92us
  av_delay          0us          0us       5.24ms          0us         52us          0us        797us          5us
  sp_delay          0us          0us       4.35ms          0us         52us          0us         92us          5us
  backlog            0b           0b        7530b           0b           0b           0b           0b           0b
  pkts                0            0        48489            0           40            0         8317           36
  bytes               0            0     68834493            0         5724            0      6311000         8043
  way_inds            0            0            0            0            0            0           21            0
  way_miss            0            0          212            0            2            0           98            2
  way_cols            0            0            0            0            0            0            0            0
  drops               0            0          414            0            0            0            0            0
  marks               0            0            0            0            0            0            0            0
  ack_drop            0            0            0            0            0            0            0            0
  sp_flows            0            0            0            0            1            0            1            1
  bk_flows            0            0            1            0            0            0            0            0
  un_flows            0            0            0            0            0            0            0            0
  max_len             0            0         7530            0          518            0         1322          353
  quantum           366          320          300          300          300          300          300          300

qdisc noqueue 0: dev eth0.1 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

Not sure about the exact numbers, but according to cake's code:

and comments:

static int cake_config_diffserv8(struct Qdisc *sch)
{
/*	Pruned list of traffic classes for typical applications:
 *
 *		Network Control          (CS6, CS7)
 *		Minimum Latency          (EF, VA, CS5, CS4)
 *		Interactive Shell        (CS2, TOS1)
 *		Low Latency Transactions (AF2x, TOS4)
 *		Video Streaming          (AF4x, AF3x, CS3)
 *		Bog Standard             (CS0 etc.)
 *		High Throughput          (AF1x, TOS2)
 *		Background Traffic       (CS1)
 *
 *		Total 8 traffic classes.
 */

CS4 maps into Tin 6, and your cake statistics show some packets in Tin 6 so things might work as expected. Only you can figure out whether the number of packets meets your expectation.

This BTW also illustrates why I personally would always try with the most minimal prioritization rules (e.g. only for the game in question) because then confirmation might be done by just checking if packets arrive in the targeted Tin instead of having to look closely at the counts. But maybe you are lucky and no other application but your game gets its packets marked CS4.

when i used tc -s qdisc i was running the game so the traffic that is mapped in tin 6 is for sure belongs to the game and it doesn't require much bandwith anyway , so i think its working as intended.

I think you can only make this inference if no other rule marks packets with either EF, VA, CS5, or CS4, but I am sure you checked that either no other rule assigns these DSCPs or that no application was active that might trigger such rules.

1 Like

what is nat ingress and nat egress ?

i has only 'at egress but i think active thé two is right ?

Yes, nat should be enabled for both directions to make sure cake sees the internal IP addresses (this only really matters for IPv4).

1 Like

i want to ask about the veth method is it enabled by default when running the script ? or do i need to manually create it then run the script because i don't see any veth interface when running

ip link show

If you use the script with the official version, you need to create a verh0 interface and add it to the one that the script creates when you start it.

1 Like

no is wrong xato the veth is created automaticly in interface in inside br-lan veth0 and veth1 but again a time the script final doesn't work at my home for the gaming

You have to run script after installing it, once you run it it creates device veth0 and veth1 You go into network and create interface veth0 and assign device veth0 unmanaget and assign it to lan firewall. That's the correct way to get the script to work with veth.

ok you explain for dont Lost connexion ?

I just do that and it works perfectly julian, the same you put your wan interface wrong.

1 Like

why would the wan interface be wrong?

Send me how you got it and I'll tell you if I see any errors.