Source address ?
Destination adress ? IP from my pc
CS5 ? Best prioritization ?
anything else i have to change ?
except Layer_cake.qos
internal IP address of you gaming PC, firewall based marking only works for egress/upload, for download the problem is that cake/sqm handle the incoming packets before the firewall code gets hold of them, if you need DSCP remarking for ingress qosify is your best bet right now (but qosify currently can not see the internal IP addresses as it runs outside of NAT).
Not going to work for ingress/download, so leave this empty and configure Source address instead.
You need to pick something which cake will put in the high priority tin, EF will work for both diffserv3 and diffserv4 (see here for details).
Looks about right, but this needs testing...
i found that:
/* List of traffic classes in RFC 4594:
-
(roughly descending order of contended priority) -
(roughly ascending order of uncontended throughput) - Network Control (CS6,CS7) - routing traffic
- Telephony (EF,VA) - aka. VoIP streams
- Signalling (CS5) - VoIP setup
- Multimedia Conferencing (AF4x) - aka. video calls
- Realtime Interactive (CS4) - eg. games
- Multimedia Streaming (AF3x) - eg. YouTube, NetFlix, Twitch
- Broadcast Video (CS3)
- Low Latency Data (AF2x,TOS4) - eg. database
- Ops, Admin, Management (CS2,TOS1) - eg. ssh
- Standard Service (CS0 & unrecognised codepoints)
- High Throughput Data (AF1x,TOS2) - eg. web traffic
- Low Priority Data (CS1) - eg. BitTorrent
- Total 12 traffic classes.
wouldn´t it be better to take CS7 ?
and on the advanced settings tab source mac address my pc ?
Some ISPs will actively drop CS7 marked packets entering their networks, so I would first test this out, orvuse cake's wash option, which will first use the dscp value to select the correct tin but then remark the packet to DSCP0.
okay thanks for your help ! 
@elan the goal here is to do minimal QoS by just expediting game traffic to one isolated host in the LAN. For egress iptables/nftables are just fine, and for ingress qosify does not allow marking by internal addresses yet. So respectfully this is not a problem where qosify will do much better than the method described above. Also not sure whether your config is as minimal as the OP aimed at?
Now if game traffic can be easily identified by port numbers with minimal false positives for ingress a qosify rule could be used, but in that case a tc filter could also be employed....
1 Like
Yes, I would very much appreciate if we would not discuss your unconditional support for qosify in every QoS related thread.
Especially if qosify is not well suited for the problem at hand....
This is IMHO not a beauty contest which QoS framework/tool is 'better' overall, but the question should be every time which of the available tools is suited for the problem at hand...
For DSCP-marking by internal IP address in the egress direction qosify simply is not suited.
The available options are:
a) mark at source: (for windows10/11 see here) E.g. for setting EF for putty on windows use:
New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46
To do that for a game one needs to replace putty.exe with the correct binary name, but it is not 100% clear if that will work (I neither play games nor use windows10/11 so can not really test that very well, that said, I did test and confirm the EF-marking for putty as shown above in a windows10 VM).
b) use iptables/nftables to create a DSCP-marking rule: this can be done either by "raw" [ip|nf]tables command or by using the LuCI GUI to create a traffic rule using "DSCP classification" as action
c) use a "raw" tc command (tc-filter and tc-pedit) to achieve the same
All of these will work equally well with sqm (simple.qos, layer_cake.qos) or qosify. None of these will solve the problem of treating incoming gaming packets to a higher priority. That can be ameliorated however by using a purely port based classification/marking rule for ingress, and that is actually something that qosify excels at.
So in the OP's shoes I would:
0) install and configure your choice of sqm or qosify to instantiate traffic shaping for ingress/download and egress/upload
-
assign a static lease to the gaming computer so it will reliably get the same internal IPv4 address (your.game.host.address)
-
create a packet-capture during a short game session to figure out which source and destination ports are used by the game's traffic (I would capture traffiv both in the internal network/LAN as well as on the WAN interface to see which addresses ports are stable and which get fudged by NAT/masquerading)
-
create a traffic rule (within LuCI's firewall->Traffic Rules page) to mark all packets from source your.game.host.address with the appropriate destination port (or port range) the game uses (I am guessing here that the destination port will be stable) to set the DSCP to EF
-
potentially use qosify to also EF-mark incoming packets with the appropriate ports (you can also try to hook into qosify's DNS integration to hook into the source IP addresses, but given how CDNs work that can have false positives)
-
report back what you tried and how it worked
And please keep in mind, that in prioritization for every packet that gets preferential treatment other packets will need to wait longer if there are no lower-priority packets available prioritization does not gain much anymore, hence it helps to only up-prioritize a few flows/packets (less restraint is required for down-prioritizing flows, but care needs to be taken to only do that to flows where completion time does not matter that much).
2 Likes
i think its not working wireshark tells me for DSCP: Default and not EF
Well possible, what exactly did you try?
hi nik try like this for dscp classification in traffic rules
config rule
option name 'CS4 gaming'
list proto 'udp'
option src '*'
option dest 'lan'
list dest_ip 'ip of my device'
option target 'DSCP'
option set_dscp 'CS4'
option enabled '0'
your rules must be postrouting for see
postrouting = mark dscp exemple for see in wireshark ...
i tried this and it didnt marked the packets in wireshark
This is not going to do much... this will DSCP mark incoming packets, but only after cake is already done with them. As I said this method only works for egress traffic.
I just confirmed that on my OpenWrt19 based router with firewall3 the following rule:
config rule
option src '*'
list src_ip '192.168.42.201'
option target 'DSCP'
option dest '*'
option set_dscp 'EF'
list proto 'tcp'
list proto 'udp'
list proto 'icmp'
option enabled '1'
does work and result on marked packets on my WAN side. For testing I ran ping -c 5 8.8.8.8 on 192.168.42.201 while running
tcpdump -i pppoe-wan -v -n 'host 8.8.8.8 and icmp'
on my router and when ever I sent packets on 201 tcpdump showed packets with (tos 0xb8 which according to https://linuxreviews.org/Type_of_Service_(ToS)_and_DSCP_Values is exactly the 8bit hexadecimal TOS value for EF...
Note however if I capture on br-lan the same packets are not yet marked EF but are still at CS0, but that is expected, also when capturing packets directly on the windows host CS0 will be visible unless method a) from my earlier post is used.
1 Like
But where (on which interface) did you run wireshark? As I just wrote, I only see the changed DSCP on my WAN interface not on the 192.168.42.201 host or on br-lan. I also confirmed that the counters for the tin carrying EF in tc -s qdisc for the egress cake instance increase when 192.168.42.201 produces traffic, so I am 100% confident that on my machine with firewall3 it works as can be expected, but that might be different for firewall4.
ok thanks for the information but do you have to create a veth interface for the input?
or should I create once with the rule that I said and once with what you propose to me?
yes i'm on fw4
on my gaming pc which is connected via a switch to my openwrt router
I put like this ip.dst==192.168.2.160 and there I see the traffic marked CS5 or CS4
on the other hand if I put ip.Src==192.168.2.160. packages are CS0
in the past with iptables i make like that
##CALL OF DUTY
iptables -t mangle -A POSTROUTING -p udp --dst 192.168.2.160 -j DSCP --sport 30000:45000 --dport 3074 --set-dscp-class CS5 -m comment --comment "Dopam-IT_1987-UDP-1"
iptables -t mangle -A POSTROUTING -p udp --src 192.168.2.160 -j DSCP --sport 3074 --dport 30000:45000 --set-dscp-class CS5 -m comment --comment "Dopam-IT_1987-UDP-2"
iptables -t mangle -A POSTROUTING -p tcp --dst 192.168.2.160 -j DSCP --dport 50000:65535 --sport 3074 --set-dscp-class CS5 -m comment --comment "Dopam-IT_1987-TCP-3"
iptables -t mangle -A POSTROUTING -p tcp --src 192.168.2.160 -j DSCP --dport 3074 --sport 50000:65535 --set-dscp-class CS5 -m comment --comment "Dopam-IT_1987-TCP-4"
iptables -t mangle -A POSTROUTING -p udp --src 192.168.2.160 -j DSCP --sport 3074 --dport 3074 --set-dscp-class CS5 -m comment --comment "cod-UDP-6"
i don't remember but i can make the same things in traffic rules
I've always wondered why I didn't wash the packages at the entrance, an important question is raised in my opinion.
Ingress is different kettle of fish, I am just trying to address the fact that the otherwise impressive qosify does not yet allow classification by internal IP addresses, and I had realized that for egress traffic existing firewall/iptables/nftables methods already suffice. Since egress is often much narrower than ingress, even just the capability to do ip/port based marking for prioritisation for egress might already be helpful.
For ingress either a veth pair or instantiating the download shaper on a LAN-interface (in a dual-port wired only router) would allow the same method to work.
2 Likes
it's really interesting how to create the lanveth suddenly,
I know you need kmod-veth and in unmanaged interface then firewall lan but it tells me device not present
config rule
option name 'BROADCAST VIDEO TWITCH'
list proto 'tcp'
option src '*'
option src_port '1935 1936 2935 2396'
list dest_ip '192.168.2.160'
option target 'DSCP'
option set_dscp 'CS3'
option enabled '0'
list src_ip '192.168.2.160'
option dest '*'
option dest_port '1935 1936 2935 2396'
I live on twitch from time to time and according to your very good explanation it could be fair to classify like that, right? for TWITCH
Well, if you only see the default DSCP0/TOS0 on there that is expected, as the firewall rule will change the DSCP of the packets once they reach the router. So think like:
gaming pc (DSCP 0) -> router br-lan (DSCP 0) -> once the packets are received the router changes the DSCP according to the rule -> router wan (DSCP EF)
since sqm/qosify should live on wan as well they will see EF and hence will be able to steer packets from the gaming PC to a higher priority tin.
BUT be careful, cake does not work with hard rate limits for the tiers, so if you push too much traffic into the higher tins, some of that traffic will end up in the Best Effort tin... for typical gaming traffic that will not matter, but if you download say a big game update (and your priority rule included TCP) that will cause issues, but I assume nobody will download big data files while playing ayways.
1 Like