Think I got the same error once when I did the same. A reboot fixed it for me.
Thanks! A reboot fixed this for me as well.
Results when using SQM with layer_cake.qos - rrul and rrul_be
=> I would say that the SQM rrul_be looks somewhat less consistent compared to the Qosify rrul_be results?
Hello again, I'm doing some search about hostapd and trying to solve an issue. However, reading the man for hostapd I see the qos_map_set option.
So my question is, how should this map be set compared to Qosify? Should we, or do we need to change anything?
From the hostapd man:
# QoS Map Set configuration
#
# Comma delimited QoS Map Set in decimal values
# (see IEEE Std 802.11-2012, 8.4.2.97)
#
# format:
# [<DSCP Exceptions[DSCP,UP]>,]<UP 0 range[low,high]>,...<UP 7 range[low,high]>
#
# There can be up to 21 optional DSCP Exceptions which are pairs of DSCP Value
# (0..63 or 255) and User Priority (0..7). This is followed by eight DSCP Range
# descriptions with DSCP Low Value and DSCP High Value pairs (0..63 or 255) for
# each UP starting from 0. If both low and high value are set to 255, the
# corresponding UP is not used.
#
# default: not set
#qos_map_set=53,2,22,6,8,15,0,7,255,255,16,31,32,39,255,255,40,47,255,255
Default openwrt config:
qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
I'm just curios 
Thanks!
This really only depends on how you want to map different DSCPs to different UPs and more importantly to the 4 APs that most WiFi gear supports. The main difference between the different ACs is the likelihood of accessing transmit opportunities and the amount of time they can continuously "hog" airtime (that is for how long they are allowed to aggregate packets). The problem is that AC VO typically has both higher access to airtime but also lower limits for the duration of the aggregates (for good reason, if you combine unlimited aggregation and high airtime access probability you will essentially near-starve all traffic in lower-priority ACs, not what most folks expect), a consequence of the limited aggregates however is that the relative size of the WiFi overhead consumes a higher fraction of airtime and that in turn affects the whole over-the-air capacity negatively...
I guess my point is, when using priorities over WiFi make sure to test realistic traffic patterns instead of trying to design a QoS hierarchy based on first principles, as things get messy pretty fast.
1 Like
Great reply. 
Is this also in relation to Class of service?
I've created a little note for myself earlier, gathering information from different brands to compare them. This is not up to date tho.
But if I look at the tables, some of them use different settings to achieve the same thing.
When we talk about DSCP, in general, is it better if the router and switch has matching DSCP settings?
The first thing to do is get rid of the assumption DSCPs would mean anything special, these really are just 6bit values that each packet can carry that can be used to treat packets differently. E.g. they can be used to steer packets to different priority tiers, but for that the only thing that matters is that the part that sets the DSCPs is aligned with the part that evaluates the DSCPs. For example in your home network you are free to define CS1 (or more modern LE) to denote the highest priority and treat packets with that DSCP better than all other packets... In RFC language what matters is the per-hop-behaviour and the DSCP is just a means to get that.
That said some gear has some default behaviour of DSCPs and it is worthwhile to keep that in mind to avoid unexpected side-effects. For many users WiFi/WMM is one of these cases, but for OpenWrt all you need to do is modify the qos_map to your liking...
P.S.:
here is my qos map:
option iw_qos_map_set '1,1,18,3,20,3,22,3,24,4,26,4,28,4,30,4,32,4,34,4,36,4,38,4,40,5,44,5,46,6,48,7,56,7,0,63,255,255,255,255,255,255,255,255,255,255,255,255,255,255'
I aimed for setting everything to BE, and 17 well known DSCPs to the typical values... I especially wanted to move DSCP 45 out of anything higher that BE, as there is a misguided IETF RFC coming that will abuse DSCP 45 to gain higher WiFi priority, but not in my network 
Sidenote: I do not think that RFC8325 is a useful instruction here, yes it tries to map a few well known DSCPs to WiFi ACs that attempt to sort of honor the PHBs these DSCPs come from, bit it absolutely lacks any data of whether the proposed mapping actually achieves its goals in a real deployment especially if multiple PHBs/DSCPs are used. So that RFC describes the "how" quite well, but is a bit scarce on the "why" and "whether at all"...
1 Like
Ah, that is very interesting. Thanks for sharing and also explaining. 
Now I really need to try your map set to see what it does...
Hi all. Do any of you know where qosify went in make menuconfig?
I'm trying to find qosify under Base system. https://openwrt.org/packages/index/base-system but it's missing.
I'm trying to build an v23.05.0 image. I checked my rc4 too, but no luck there.
Happy for any input
Edit: I can see it here tho https://git.openwrt.org/feed/packages.git^0da9f622975aa1e4efe452da4acbae15479bee63 but not in the builder.
Make sure youâve chosen a BPF toolchain option. Search the thread for LLVM.
Thanks for the fast reply. Found the instructions here:
Edit: That worked. Download, unpack and make menuconfig. Done.
My WiFi router D-Link DIR-860L B1 is used as AP, it's wan (ip 192.168.1.2) is connected to the main router APU2 (ip 192.168.1.1).
How can I apply qosify rules only to packets that access the big internet, and waive the traffic that access my internal server (192.168.1.0/24)?
Another question is that, the qosify config file has 'option bandwidth_up'. In my case, the ISP fiber offers bandwidth 1Gbps, enough for full capacity of both 2.4G and 5G WiFi. If I use 5G WiFi to set the bandwidth_up, there's trouble with 2.4G WiFi udp voice communication, if I set as 2.4G WiFi, the speed of 5G WiFi has to limited to 2.4G level.
Is there a way for qosify to separate 2.4G and 5G bandwidth limits?
I cant install this package in this build
@EXREYFOX
What package? What is the error?
"Qosify"
And it is kernel error
@EXREYFOX
Please post the actual error in full.
collected errors:
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.135-1-9a43e285051994120ba2225f1c9c56a4) for kmod-sched-core
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.135-1-9a43e285051994120ba2225f1c9c56a4) for kmod-sched-cake
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.135-1-9a43e285051994120ba2225f1c9c56a4) for kmod-sched-bpf
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-sched-bpf found, but incompatible with the architectures configured
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.135-1-9a43e285051994120ba2225f1c9c56a4) for kmod-ifb
* satisfy_dependencies_for: Cannot satisfy the following dependencies for qosify:
* kernel (= 5.15.135-1-9a43e285051994120ba2225f1c9c56a4)
* opkg_install_cmd: Cannot install package qosify.
So the Qosify only work for the kernel 5.15!!
No, itâs probably because the custom build cannot match the kernel version magic number due to different kernel build options.
Whatâs your version in opkg info kernel?
root@OpenWrt:~# opkg info kernel
Package: kernel
Version: 6.1.55-1-c278869ae024a8d24ec85ea84d77ffcb
Depends: libc
Status: install user installed
Architecture: arm_cortex-a9_vfpv3-d16
Installed-Time: 1696562444
Whatâs in /etc/opkg/distfeeds.conf?