No, I won't do it. You go and find all ldir's posts about it. It's clearly explained, requires certain knowledge to understand it and I lack moeller0's or grrr2's patient to explain it.
thanks i has done well
ctinfo_4layercake.qos 100% 40 51.7KB/s 00:00
ctinfo_4layercake.qos.help 100% 248 357.7KB/s 00:00
ctinfo_5layercake.qos 100% 40 63.8KB/s 00:00
ctinfo_5layercake.qos.help 100% 262 410.0KB/s 00:00
ctinfo_layercake.qot 100% 18KB 8.8MB/s 00:00
defaults.sh 100% 4128 4.7MB/s 00:00
functions.sh 100% 29KB 12.9MB/s 00:00
layer_cake.qos 100% 1615 1.9MB/s 00:00
layer_cake.qos.help 100% 323 583.1KB/s 00:00
piece_of_cake.qos 100% 1543 2.2MB/s 00:00
piece_of_cake.qos.help 100% 343 705.2KB/s 00:00
run.sh 100% 4385 5.1MB/s 00:00
simple.qos 100% 11KB 9.2MB/s 00:00
simple.qos.help 100% 85 155.7KB/s 00:00
simplest.qos 100% 4216 3.3MB/s 00:00
simplest.qos.help 100% 76 144.1KB/s 00:00
simplest_tbf.qos 100% 2967 4.1MB/s 00:00
simplest_tbf.qos.help 100% 146 304.0KB/s 00:00
start-sqm 100% 2108 576.5KB/s 00:00
stop-sqm 100% 1606 1.4MB/s 00:00
update-available-qdiscs 100% 370 665.4KB/s 00:00
i has cofnigurate for my console
i always get this with my ssh:
-ash: /etc/config/qosify: Permission denied
and i cant find qosify in the gui
but i installed the package
he has not interface for qosify in luci
i'm test actually script of idir
I want to prioritize outgoing and incoming UDP packets to my gaming pc. Is Qosify my only option to do that ? It´s hard for me to get into qosify and to set up cake for my cable connection without a gui, I saw many configs with a lot of different prioritizations but i just need a really simple config that prioritizes my gaming ports...
Does that mean i can´t prioritize my gaming pc with qosify, i can only prioritize the overall traffic from port xyz? Also if i go the simple way and only prioritize the upload with a dscp mark - >
would this be the perfect configuration ? How do i check if its working or not ? When i monitor the packets with Wireshark the dscp values are default.
No. for egress, as I have shown, you can leverage iptables/nftables to apply DSCP mark before the packets hit the traffic scheduler. For ingress that is considerably harder, because due to NAT/masquerading incoming packets on the WAN side all have your public IPv4 address as destination IP address so a simple marking rule looking at the destination address is not going to work.
There are a number of options:
a) you could teach your remarking qdisc to consult the kernels connection tracking table to figure out the internal IP address from the external visible destination port (cake does that internally to implement its per-internal-IP-fairness modes).
b) you could move the ingress/download traffic shaper/scheduler from outside of the NAT to inside of the NAT (where the destination IP addresses are now showing the "correct" privat internal addresses). There are a number of scripts that use veth interfaces to make this possible, IMHO @dlakelan is the resident expert on that (he is generally an expert on traffic shaping/QoS, but also for the veth method)
c) use @ldir's special qdisc (which @Dopam-IT_1987 mentioned recently) that will copy the egress DSCP mark of a flow (wich you can set via the firewall GUI) to the corresponding ingress flow.
None of these are terribly easy. Qosify can not do that btw, but it wuld allow a much easier method to mark by looking at port numbers (albeit some reports indicate that that feature might not work as intended currently).
Well it should be possible to simplify a qosify configuration, if only be setting all classes DSCP to 0 except for the gaming packets...
As far as I understand yes, currently qosify does not know internal IP addresses at all and hence can not do anything based on those.
That looks about right, I dod however not test port ranges with that.
As I tried to explain before, wireshark on the game computer is the wrong place, because there the DSCP truly is zero, only on the router they will be changed to EF.
So you could try something like that on your router:
`opkg update ; opkg install tcpdump ; tcpdump -i wan -n -v 'host 1.2.3.4'
(assuming 1.2.3.4 is your internal IP, which is really not worth redacting out, because internal addresses can not be reached from the outside, but I digress).
This should show all packets to/from the gaming host as well as the hexadecimal TOS byte and the port number, you could/should check whether packets from (or to?) the configured port are marked EF (0xB8 as hexadecimal TOS byte).
1 Like
I get :
tcpdump: wan: No such device exists
(SIOCGIFHWADDR: No such device)
when i insert my gaming pc ip
Ah sorry, I did not explain my cryptic instruction well enough. 'wan' was supposed to be a stand-in for your true wan interface. Just post the output of:
ifstatus wan | grep -e device
Here is an example of mine:
root@turris:~# ifstatus wan | grep -e device
"l3_device": "pppoe-wan",
"device": "eth2.7",
and I would use tcpdump -i pppoe-wan -n -v 'host 1.2.3.4`. BUT I just realized that this is not going to work, as on pppoe-wan the internal 1.2.3.4 address is not visible...
enter the uci command as below
# uci show network.wan.device
network.wan.device='eth1'
it will tell what is your physical device used as wan. for me it is eth1. for you it maybe something else but use your's in tcpdump.
but if you use tcpdump -i <lan> -Q out 'host 1.2.3.4' will provide all packets sent outward to 1.2.3.4 via the lan interface. or similarly -Q in will tell anything coming from 1.2.3.4 via lan interface. -Q inout or simply omitting -Q will show both direction.
uci show network.lan.device will tell the lan device.
1 Like
So
tcpdump -i YOURWAN -n -v 'src port 3074 or src port 3478 or src portrange 4370-4380 or src portrange 27000-27031 or src port 27036`
should restrict the displayed packets to those with the expected port range, then play the game a see what TOS byte gets reported....
You still need to generate traffic...
But here is a beauty I just googled:
tcpdump -i eth0 -v -n 'ip and (ip[1] & 0xfc) >> 2 == 0x2E'
This should report all packets marked EF (hexadecimal DSCP(6bit) of EF is 0x2E, but the full TOS(8bit)byte value is 0xB8). Here is my result for ping -c 10 8.8.8.8 on a machine that is unconditionally up-marked to EF:
root@turris:/srv/persistent/captures# tcpdump -i pppoe-wan -v -n 'ip and (ip[1] & 0xfc) >> 2 == 0x2E'
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
19:59:20.618575 IP (tos 0xb8, ttl 63, id 28703, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 1, length 64
19:59:21.619633 IP (tos 0xb8, ttl 63, id 28892, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 2, length 64
19:59:22.620737 IP (tos 0xb8, ttl 63, id 28893, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 3, length 64
19:59:23.622585 IP (tos 0xb8, ttl 63, id 29016, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 4, length 64
19:59:24.623865 IP (tos 0xb8, ttl 63, id 29171, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 5, length 64
19:59:25.625738 IP (tos 0xb8, ttl 63, id 29175, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 6, length 64
19:59:26.627777 IP (tos 0xb8, ttl 63, id 29280, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 7, length 64
19:59:27.628956 IP (tos 0xb8, ttl 63, id 29450, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 8, length 64
19:59:28.630085 IP (tos 0xb8, ttl 63, id 29566, offset 0, flags [DF], proto ICMP (1), length 84)
78.50.41.171 > 8.8.8.8: ICMP echo request, id 26, seq 9, length 64
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel
Repeating the same game on br-lan, shows no marked packets yet, which is to be expected, only after a packet is received by the kernel via br-lan its DSCP value will be changed...
Respect where it is due, the indirect addressing of the TOS byte and masking out of the two ECN bits was described in http://darenmatthews.com/blog/?p=1199
Well possible, but the problem is that on br-lan, the packets still have the origibal DSCP set by the end-host, in my case DSCP 0.
now i can see this:
That is only part of the output (I understand that you want to maintain your privacy by not exposing your public IPv4 address onto the forum, but it is easier if you post the complete output and just redact that one sensitive address)... but tos 0xb8 is EF with both ECN bits at 0...
In case that is all of the output try -vv or even -vvv instead of the single -v that should dump a bit more information....
You can by the way also write the capture output of tcpdump into a file (by adding -w capture_file_name.cap to the command, you can load these with wireshark, but you will need to a) copy them from your router b) keep in mind that capture files can grow quite fast and overwhelm your routers memory, c) if you run this on a router make sure to either save to /tmp which is RAM-backed or onto a USB medium, as typical NOR or FLASH in routers only allows few write cycles).
Excellent, these show both the IP addresses (which you might want to avoid for your public IP*) and the port numbers, which will allow to refine the required port ranges and figure out whether these are the remote/server or the local/client ports.
*Many ISPs will give you a fresh IPv4 address every X days (often every single day, but sometimes every 180 days or more). If your IPv4 is stable for a long time, keeping it off public forum posts seems useful, but for every 24 hour renewals I would not bother (unless in a flame-war thread, where an exposed IP might be DOSed instantaneously, not sure that ever happens, let alone in this friendly forum).
i cant fully delete it
I took the liberty to ask the moderators to contact you about deleting the image, let's hope they are still awake 
But again, the risk of exposing an IPv4 address is IMHO often over-rated, but it certainly is > zero.
1 Like
As a point of order 'act_ctinfo' is a tc action not a q(ueuing)disc(ipline)
A typical usage for an IFB redirect ingress scenario is something like
# tc filter show dev eth0 ingress
filter parent ffff: protocol all pref 49152 matchall chain 0
filter parent ffff: protocol all pref 49152 matchall chain 0 handle 0x1
not_in_hw
action order 1: ctinfo zone 0 pipe
index 2 ref 1 bind 1 dscp 0x0000003f 0x00000800
action order 2: mirred (Egress Redirect to device ifb4eth0) stolen
index 1 ref 1 bind 1
The 1st action is 'ctinfo' where we hope to find that the conntrack firewall entry has a DSCP stored for this connection in the conntrack MARK field and if so, set that stored DSCP value into the current packet.
The 2nd action is 'mirred' (mirror/redirect) where we redirect this packet to the ingress port of another interface, in this case 'ifb4eth0'
iptables is typically used to copy the DSCP from an existing (usually egress) packet into the conntrack firewall MARK - openwrt's iptables has a patched CONNMARK module which understands '--set-dscpmark' which copies the DSCP field into connmark and sets a flag.
classification rules here - put the desired DSCP into the packet
iptables -t mangle -A MANGLE_CHAIN_HERE -j CONNMARK --set-dscpmark 0x3f/0x800
Most of the time you only need to set the DSCP on connection startup, so if you're clever with iptables rules and the DSCP_IS_STORED flag you can save yourself going through the classification decisions for every packet - sort of set and forget.
To set a decided DSCP on egress (to wan) you need something like
# tc filter show dev eth0
filter parent 8011: protocol all pref 49152 matchall chain 0
filter parent 8011: protocol all pref 49152 matchall chain 0 handle 0x1
not_in_hw
action order 1: ctinfo zone 0 pipe
index 1 ref 1 bind 1 dscp 0x0000003f 0x00000800
I should add that at present nftables does not have equivalent functionality of --set-dscpmark. You should cheer on Jeremy Sowden's efforts to enhance nftables to do so here https://marc.info/?l=netfilter-devel&m=164907445630634&w=2
Not to be too down on nftables, I was wondering why my old raspberry pi was running openwrt with fw4 and I'd forgotten I had been experimenting with how far I could get. It would be nice if you could do something as simple as "nft add rule t c ct mark set ip dscp" or even better "nft add rule t c ct mark set ct mark and 0xffffff00 or ip dscp" and it not throw a syntax error. You can get close with "meta nfproto ipv4 ct mark set @nh,8,6" and "meta nfproto ipv6 ct mark set @nh,4,6" but they both destroy the existing mark value rather than nicely masking themselves in - that's why Jeremy's work is so useful. I had sort of given up / got occupied with work but I'll see if I can work around the limitation.
4 Likes