Easiest way to get DSCP working on Ingress?

I have sqm set up, nft firewall dscp rules set up, as well as the layer_cake_ct.qos script selected (and kmod-sched-ctinfo is installed). What am I missing to get DSCP markings working on ingress?

You are missing 3rd party sending dscp markings over internet and your provider not clearing them.

1 Like

layer_cake_ct.qos aims to store the DSCPs from outgoing packets into the conntrack database and restore the same DSCPs on ingressing packets*... so the nauve expectation would be to get some return packets in all priority tins that are used by egressing packets, so tins 1,2, 6, amd 7, but they only see return traffic in tins 2 and 7.

Maybe time to whip out tcpdump and conform the egressing DSCPs first and then see what happens further...

*) That way the ISPs DSCP markings are completely ignored/over-ruled.

Very little effect, input is consumed in gro bulk packets.

This is a bit terse and somewhat cryptic... That said re-assigning DSCPs in a controlled fashion for ingressing packets has the following rationale. It steers packets into one's priority tiers and allows for selective back pressure, e.g. not dropping gaming traffic at all, while reigning in bulk transfers somewhat more aggressively. It can also affect the priority access classes used by WiFi links.
Regrding GRO/GSO cake as a qdisc can and will by default dissect larger meta packets into "normal" roughly MTU sized packets and hence will not be affected by these techniques, for other shaper/schedulker/AQM set ups one might need to first go and disable GRO/GSO on all interfaces that might collect meats and send them to the qdisc...

looks like tcpdump is showing them correctly, and wireshark does as well.

Im a bit new to this stuff and I like learning, but I can't seem to find how to get layer_cake_ct.qos working like how it describes. What am I missing? I can get DSCPClassify and cake-qos-simple to work with no issues, but I would like how to do it myself. Ive looked at the files for all of those and I mostly understand how it all works minus the restoring the dscp on ingress part for each one.

The contrack trick requires 2 components:
a) taking the dscp stored in conntrack and assigning it to incoming packets (IIRC this is done with a simple tc command)
b) iptables/nftables commands/rules to take the dscp from outgoing packets and storing them into conntrack

Are you sure you are doing both things?

I think this would be the part I'm missing. I couldn't find anything about it before. Is there a page / article / post anywhere about how to set it up?

Your beste reference likely is looking at one of the projeczs that have this already implemented like DSCPclassify or cake-qos-simple. You might want to consider writring a wiki article/howto if you figure this out.

cake-qos-simple is designed and written as a template as a sort of springboard for your own customisation using appropriate nftables rules. These can be added in the nftables file or even just using firewall rules in LuCi.

DSCPs are stored to conntrack for outgoing packets here:

DSCPs are restored from conntrack for incoming packets here:


Quick question, what does the or 128 stanza do?

It sets the tc-ctinfo statemask for use in the ingress tc filter.

1 Like

Here is also a short explanation:

I was experimenting with SQM scripts a while ago and created an SQM script with ctinfo and just a few necessary nftables rules, allowing one to use LuCI for marking forwarded traffic. I believe it was working when I tested it.

My original idea was to include this, or at least something similar, as a SQM script in OpenWrt. However, I'm not sure if this is a good approach...

If you want to try it:

wget -O /usr/lib/sqm/Layer_cake_ctinfoHudra.qos https://raw.githubusercontent.com/hudra0/sqm-scripts/main/Layer_cake_ctinfoHudra.qos

wget -O /usr/lib/sqm/Layer_cake_ctinfoHudra.help https://raw.githubusercontent.com/hudra0/sqm-scripts/main/Layer_cake_ctinfoHudra.help

then just activate the sqm instance and mark via luci firewall rules...

1 Like

So this is still on my todo list, to make this optional for sqm scripts, but ATM my own promary router is still on iptables so I can not test this. But I think adding the DSCP saving and restoration capability to coere sqm-scripts seems like a good way forward. This still leaves all the actual clever rules and heuristics out of sqm-scripts and inside those projects that want that.

That said, I am buggy enough with code I actually can test, so I will not create any PR until I can test this myself... (I understand that it will need some checking for recent enough nftables and tc binaries, and it needs some thought on how to undo this cleanly from the sqm-stop routine, and these details require being able to actually test things). I also note that creating a PR does not guarantee that it will end up in sqm-scripts...

This is exactly what I was thinking as well.

The version I provided should do some clean up when stopped but like I said this was just an experiment and is not fully tested.... I guess it would be a starting point...

Is tohojo still maintaining sqm-sritps?

Thank you so much for sharing this. I was able to get what I wanted working by looking through your script and putting "action ctinfo dscp 63 128 mirred egress redirect dev $DEV" in the layer_cake script like you had and by adding + adjusting "add rule inet sqm_dscp sqm_dscp ct mark set ip dscp or 128 counter" to my current nft rules.

I do also agree that your script would be a great addition to sqm scripts (Although, I have not tested it fully).

1 Like

Sure, and he is open to PRs :wink:

1 Like

I would say the capability would be great to add, but preferably not as a new script but as something that can be enabled for the existing scripts...

Also with simple restoration LuCi firewall can be used to set the outgoing DSCPs. Hence everything could be done using a GUI, which I think would be helpful for many.

1 Like

It is bitmask
mark =to become= 32bit value OR bitmask.

you can see that in -c -d netlink

1 Like