CAKE w/ DSCPs - cake-qos-simple

IMHO that is one of the few decent settings. (This is also how DSCP usage could have been expedited, by not defaulting to BestEffort, so that doing nothing is a decent setting)
However I think that 3 tiers hit the sweet spot and there I think defaulting to the middle tier while allowing to selectively down- and up-prioritize a few selected traffic-aggregates is a pretty decent generic hierarchy.
Defaulting to Bulk is decent if you have important traffic that is well above the 50 or 25 priority capacity share the higher tiers in diffserv3 and diffserv4 offer (but this is admittedly a work around gor cake's fixed capacity share percentages per tier).

If you know the remote IP address for such traffic (e.g. you can also check on the router's command line:

# outgoing
tcpdump -i pppoe-wan -v -n 'ip and (ip[1] & 0xfc) >> 2 != 0' and dst
# incoming
tcpdump -i pppoe-wan -v -n 'ip and (ip[1] & 0xfc) >> 2 != 0' and src
1 Like

Why CS4 and not EF for Gaming traffic? e.g PS5/Xbox?
Isnt EF class better as is Very Low jitter/loss? @Dopam-IT_1987

Reading @elan post here...


Because the actual DSCP bit patterns carry no meaning by them selves, what matters is the per-hop-behaviour, and for cake really all DSCPs that map to the same priority tier are effectively identical... it does not matter one iota what IETF RFCs describe as PHBs for a specific DSCP, if ou use cake all that matters is what cake does.
In theiry the DSCP pattern might matter upstream, but in all likelyhood your ISP is going to remark or at least ignore DSCPs you set. (Downstream from your router, it can matter when you use WiFi WMM, but there OpenWrt allows to set specific qos_maps that allow to steer individual DSCPs into the 4 WiFi access classes selectively)

1 Like

hi Francisuk i use cs4 çar i play in cable and the dscp are only letters and numbers that are with cake defined in advance for the 4 boxes as moeller0 often repeats cs4 and ef are the same they will go in voice tin

@moeller0 I replaced your command with wan and destination ip but no traffic

this schéma is for diffserv4 if i ça help to understand

If anyone can share a (small) PCAP that is appreciated. Please send it to me at so I can convince my dev team this is a persistent issue. :slight_smile:

You just want a capture of some packets arriving on my non-Xfinity router from the WAN showing tos 0x20?

Yeah that'd be great!

1 Like

Got a few PCAPs - thanks!

We are good now - I found the CS1 issue with my colleagues based on a PCAP sampling on different modems.

Appreciate the help!


@lynxthecat - In general I have assumed that folk using the dual-* options were not setting nat in both directions. Triple-isolate should end up being the best choice with the nat option enabled. IMHO.

glad y'all are taking a look at it. Given a wifi bottleneck, CS1 markings will (IMHO), on any of it, will severely deprioritze CS1 wifi traffic on a busy network. I have seen 100s of ms, just from that impact on the wifi scheduler.

See slide 9 here:

1 Like

That’s confusing. How does CAKE determine internal per-host fairness without nat?

it cannot. so the nonat setting was kind of an error. I wish very much that we had left nat on by default in cake. I am responding to his recent commit turning nat on by default.

How that? IIRC triple is a clever trick if the directionality is not known, if directionality is known (and masquerading can by peeked into) then dual-srchost on egress and dual-dsthost on ingress gives per internal-IP fairness. triple-isolate will for normal traffic mixed essentially give something similar, but:
a) much harder to describe/predict on a packet-by-packet bases
b) will not work as expected in a number of simple test cases

So my advice has always been, if directions are known and masquerading is used use `nat dualxxxhost', if that is incorrect, please elaborate...

Also note that @lynxthecat for the time being has left OpenWrt forum; his posts are labelled anon10117369. He is still active on his github page and probably will respond to issues.

I think nonat is okay, AND I fully agree we should have defaulted to nat... :wink:

Good afternoon,

How does this script work? Can you share some rules?


sorry to ask: but have you read the first post? followed the referenced link? it is nicely documented what this script does and how.

Ok, I understand how it works, can you share some rules?

You might want to ask any question on the github project's page, lynxthecat has unsubscribed from the forum (I still hope he will come back) ...

Thanks moller, I'm going to try to make my internal network travel each packet through its place and try to understand how everything works perfectly.

Here is a example for Zoom for Windows, Right click on WIndows Powershell and run as Administor.


New-NetQosPolicy -Name "Zoom" -AppPathNameMatchCondition "Zoom.exe" -NetworkProfile All -DSCPAction 46 -IPProtocolMatchCondition Both -PolicyStore Localhost


iptables -t mangle -A POSTROUTING -p tcp -dport 80 -j DSCP -set-dscp-class cs1
iptables -t mangle -A POSTROUTING -p udp -dport 80 -j DSCP -set-dscp-class cs1

Update: the config error was identified in a few places, fix is ready, soak testing in 1 - 2 weeks and then deployment to complete in the early part of July. I'll try to remember to post back here when we're done. Thanks again to this list for the heads up!