When testing dscpclassify in the beginning i marked my packets with ef and then i was wondering why they appeared as cs6. First i thought there was an issue with my config but then I had a closer look at the code and found out that with option wmm ef gets remarked with cs6 so I disabled it. I mean in the end it doesn’t really make a difference with diffserv4 if its cs6 or ef as it ends in the same tin but for new users i think this could be a bit misleading so i also recommended it to other users who got confused. I think @Dopam-IT_1987 wanted to mark packets with cs3 and it got remapped to cs4 (what actually would make a difference with cake) because of option wmm. I think wmm should by default be disabled to not confuse new users but this i just my personal opinion.
my rules today doesn't appair 
chain static_classify {
ip saddr 192.168.2.160 udp dport != { 80, 443 } counter packets 109 bytes 9284 goto ct_set_cs4 comment "Consoles ps5"
i don't know why
You can just download the the new files from github as instructed in the github readme. Probably the easiest way…
or
You can also build your own firmware image (that’s how i do it) which is well documented in the OpenWrt docs. Just clone the dscpclassify github repo into your packages folder in your build root. If then there is a change within dscpclassify you only have to „git pull“ to get the changes and build a new image. At least that’s how i do
Gotcha, but this is clearly to get packets in the right classification for a WiFi network. But, you are correct, of course.
good evening everybody
i has add this rules for all not that ps5
so hi have just 3 rules now
config rule
option name 'DNS'
list proto 'tcp'
list proto 'udp'
list dest_port '53'
list dest_port '853'
list dest_port '5353'
option class 'cs2'
I would like to prioritize the tcp games also in cs4
but not to include the tcp port 1935 I thought of doing like this
config rule
option name 'ps5 consoles'
option proto 'tcp'
list src_ip '192.168.2.160'
list dest_port '!1935'
option class 'cs4'
option family 'ipv4'
option counter '1'
I would like the 1935 port to remain in cs3 because I apply cake sqm in diffserv4
why I do this because some games on pc play in tcp like WoW or LoL I think
ok but i has just download to github i download where for update i has read the readme
maybe developp to jeverley i has try but not counter in firewall
more simply for me to make by github
This is arguable, also I would propose that on OpenWrt the way to align WiFI ACs with desired priority tiers is to adjust the qos_map instead of manipulating DSCPs, but I accept that this might be a matter of personal taste (and of layering, in a mostly nftable solution it seems attractive to solve this inside nftables as well, compared to dragging in changes to external config files....)
I see people here showing that the input and output ports are being marked by dscp, in my case my input ports are marked but the output ports are not?
06:55:49.187432 IP (tos 0x0, ttl 128, id 31429, offset 0, flags [DF], proto TCP (6), length 40)
10.10.1.160.62297 > 31.13.85.53.443: Flags [.], cksum 0x74d8 (correct), ack 72, win 1025, length 0
06:55:49.407239 IP (tos 0x20, ttl 48, id 20201, offset 0, flags [DF], proto TCP (6), length 40)
139.59.210.197.443 > 10.10.1.160.62359: Flags [.], cksum 0x13d5 (correct), ack 828, win 501, length 0
My DSCP CLASSIFY test settings
config global 'global'
option class_bulk 'le'
option class_high_throughput 'af13'
option client_hints '1'
option threaded_client_min_bytes '10000'
option threaded_service_min_bytes '1000000'
option wmm '0'
config rule
option name 'test'
list proto 'tcp'
list dest_port '443'
option class 'cs1'
SQM
config queue 'eth1'
option enabled '1'
option interface 'pppoe-wan'
option download '75000'
option upload '30000'
option qdisc 'cake'
option script 'layer_cake_ct.qos'
option linklayer 'ethernet'
option debug_logging '0'
option verbosity '5'
option qdisc_advanced '1'
option squash_dscp '0'
option squash_ingress '0'
option ingress_ecn 'ECN'
option egress_ecn 'NOECN'
option qdisc_really_really_advanced '1'
option iqdisc_opts 'nat dual-dsthost ingress diffserv4'
option eqdisc_opts 'nat dual-srchost ack-filter diffserv4'
option overhead '38'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '86'
option linklayer_adaptation_mechanism 'cake'
Where did you capture this?
On the wan interface you should see egress DSCPs set by qosify but not ingress DSCPs (you will instead see whatever DSCPs come in from your ISP, these might or might not make sense for your own network, likely the latter).
On the lan interface(s) like br-lan you will see ingress DSCPÜs set by qosify but not egress DSCPs (instead you will see whatever DSCPs were set by the hosts in your internal network, these often can be made to make sense... but you need to use qosify's '+' notation so these are honored)...
Could you give me some light on what I could do, I'm a layman on the subject, whatever you ask me to do, I'll do it here.
How did you get the tcpdump data you posted above?
06:55:49.187432 IP (tos 0x0, ttl 128, id 31429, offset 0, flags [DF], proto TCP (6), length 40)
10.10.1.160.62297 > 31.13.85.53.443: Flags [.], cksum 0x74d8 (correct), ack 72, win 1025, length 0
06:55:49.407239 IP (tos 0x20, ttl 48, id 20201, offset 0, flags [DF], proto TCP (6), length 40)
139.59.210.197.443 > 10.10.1.160.62359: Flags [.], cksum 0x13d5 (correct), ack 828, win 501, length 0
I did this command
tcpdump tcp port 443 -i br-lan -v -n
Then try:
tcpdump tcp port 443 -i wan -v -n
instead to see the egress DSCPs (assuming your wan interface is called wan, otherwise replace the wan above with the correct interface name, ´ifstatus wan | grep device´ should help finding out the correct L3 device)
I did the command
root@OpenWrt:~# ifstatus wan | grep device
"l3_device": "pppoe-wan",
"device": "wan",
root@OpenWrt:~# tcpdump tcp port 443 -i pppoe-wan -v -n
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
07:42:43.792890 IP (tos 0x20, ttl 127, id 22365, offset 0, flags [DF], proto TCP (6), length 41)
100.90.12.45.49434 > 142.251.129.110.443: Flags [.], cksum 0x3a82 (correct), seq 852488615:852488616, ack 3656462118, win 1020, length 1
07:42:43.803322 IP (tos 0x0, ttl 123, id 255, offset 0, flags [none], proto TCP (6), length 52)
142.251.129.110.443 > 100.90.12.45.49434: Flags [.], cksum 0xbe6f (correct), ack 1, win 264, options [nop,nop,sack 1 {0:1}], length 0
07:42:53.907254 IP (tos 0x0, ttl 51, id 35530, offset 0, flags [DF], proto TCP (6), length 78)
139.59.210.197.443 > 100.90.12.45.65460: Flags [P.], cksum 0x0b8b (correct), seq 403424275:403424313, ack 185368622, win 621, length 38
07:42:53.907254 IP (tos 0x0, ttl 51, id 35531, offset 0, flags [DF], proto TCP (6), length 71)
139.59.210.197.443 > 100.90.12.45.65460: Flags [P.], cksum 0x929e (correct), seq 38:69, ack 1, win 621, length 31
07:42:53.908066 IP (tos 0x20, ttl 127, id 53947, offset 0, flags [DF], proto TCP (6), length 40)
this appeared,please don't hack me
Your ISP uses CG-NAT, so 100.90.12.45 is not really publicly reachable... so you are pretty save (not that I would know howe to hack you let alone that I would want to do that).
But not knowing all your marking rules all I can see that the one packet going out (100.90.12.45.49434 > 142.251.129.110.443) seems to carry tos 0x20 (aka CS1) which fits with your snippet for the test rule.
would you tell me which exit rule is working
The single packet:
07:42:43.792890 IP (tos 0x20, ttl 127, id 22365, offset 0, flags [DF], proto TCP (6), length 41)
100.90.12.45.49434 > 142.251.129.110.443: Flags [.], cksum 0x3a82 (correct), seq 852488615:852488616, ack 3656462118, win 1020, length 1
seems to show this rule working for egress, as the packet is from your router#s CG-NAT address (100.90.12.45) to a google server at port 443, and is marked tos 0x20 which translates to CS1 and since your rule was to mark everything going to remote port 443 as CS1 I take this as evidence that this rule triggered.
Thank you very much for the explanation, because I'm going to take this teaching into life, but just one question, do you think we should make rules in Qos on Windows, would that bring any advantage?
If you want a DSCP to affect e.g. the selection of WiFi priority classes (access classes AC) then the local endpoints should set these DSCPs. Windows offers a number of ways of how to achieve that:
Here are my notes for one way to assign a specific DSCP to all packets of an application:
windows QoS: https://docs.microsoft.com/en-us/powershell/module/netqos/?view=win10-ps
Get-NetQosPolicy
temporary -PolicyStore ActiveStore, otherwise omit -PolicyStore
New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -ThrottleRateActionBitsPerSecond 1MB -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 47 -WhatIf
New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46
Get-NetQosPolicy -Store ActiveStore
Name : putty_ps
Owner : PowerShell / WMI
NetworkProfile : All
Precedence : 127
AppPathName : putty.exe
JobObject :
DSCPValue : 46
Remove-NetQosPolicy -Name "putty_ps" -PolicyStore ActiveStore
Seems to work, and I confirmed via tcpdump that putty's ssh packet originating from the windows VM host actually used DSCP 46 (aka EF). I note that powershell needs to be run as administrator, and the policies do not end up visible in Local Group Policy Editor. "-PolicyStore ActiveStore" will not survive a reboot, but for novice users that might be nice so a reboot cleans the slate in good windows tradition. I assume that after initial testing one could omit the "-PolicyStore ActiveStore" directive and store tested configs more permanently.
https://forum.openwrt.org/t/dscp-marking/134651/28?u=moeller0
@Lynx found out that if you set the regedit key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\QoS
(n.b. you may need to create 'key' QoS')
and input string' "Do not use NLA" with value "1",
then the (local) settings in the GPO take effect:
Mind you I rarely use Windows myself so I do not actually use that, but back when I tested it, it worked. It might require to install microsoft's powershell first
Thanks @moeller0 - yes @Rafumfps I wrote about it here:
Setting application-specific DSCPs using this mechanism definitely works just fine under Windows, although I noticed that the registry entry got reset one time, and I had to set it back. Absent that registry setting, the QoS entries have no effect (Windows 11 Professional).
The alternative is to try to set DSCPs based on ports at the router, but some applications chop and change ports, and setting at the application level seems to me desirable.
My take is to have clients and/or router set DSCPs on upload, then restore the DSCPs per connection using the linux conntrack mechanism on download. And importantly those must be set before CAKE sees the packets.
You can verify correct operation using:
opkg update; opkg install tcpdump
# First check correct flows and DSCPs correctly set by your LAN client on upload
tcpdump -i wan -vv
# Second check correct flows and corresponding DSCPs are getting set by router on download
tcpdump -i ifb-wan -vv
The interface names 'wan' and 'ifb-wan' will need to be set correctly.
And then also looking at the CAKE statistics:
tc -s qdisc
From the latter you should see appropriate tinning of the download packets like this:
qdisc cake 1: dev ifb-wan root refcnt 2 bandwidth 60Mbit diffserv4 triple-isolate nat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 0
Sent 236374165568 bytes 232884367 pkt (dropped 101861, overlimits 253014336 requeues 0)
backlog 0b 0p requeues 0
memory used: 3931044b of 4Mb
capacity estimate: 60Mbit
min/max network layer size: 46 / 1500
min/max overhead-adjusted size: 46 / 1500
average network hdr offset: 14
Bulk Best Effort Video Voice
thresh 3750Kbit 60Mbit 30Mbit 15Mbit
target 5ms 5ms 5ms 5ms
interval 100ms 100ms 100ms 100ms
pk_delay 643us 2.73ms 897us 632us
av_delay 130us 1.78ms 146us 80us
sp_delay 7us 8us 12us 8us
backlog 0b 0b 0b 0b
pkts 1494346 226611352 3249126 1631404
bytes 1675790968 231672299755 2529641413 635956232
way_inds 504 18296482 0 60431
way_miss 6783 328523 896 79681
way_cols 0 0 0 0
drops 1125 100727 4 5
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 1 3 1 2
bk_flows 0 1 0 0
un_flows 0 0 0 0
max_len 67326 68700 10992 3960
quantum 300 1514 915 457
By the way, this matters when saturating the connection - my take on it is that you are telling CAKE to drop certain packets (like Windows update or bulk downloads) before others (like your gaming packets) thereby hopefully to prevent latency increase of your gaming packets during saturation.