A) If the IFB goes away for what ever reason (say the underlaying pppoe interface ceased to exist) the action will also be gone for good? Or put differently is there anything else required than a $TC qdisc del dev $DEV root to get rid of the action?
B) What requirement for additional packets exists for using this (I would like to add this great capability to a variant of layer_cake.qos in the main repository, but want to make it safe even on systems lacking the requirements)
Please note: my idea is to keep actual egress marking rules out of the scripts and delegate users to using the firewalls DSCP classification action to set egress DSCPs to their hearts content, so all we need would be two additional tc lines guarded by a check whether the required functionality exists on the system...
Hrm, that is a bit of a show stopper for me right now, as my iptables tells me:
root@turris:~# iptables -t mangle -A MANGLE_CHAIN_HERE -j CONNMARK --set-dscpmark help
iptables v1.8.3 (legacy): unknown option "--set-dscpmark"
Try `iptables -h' or 'iptables --help' for more information.
Yes, the command would fail as exercised anyway, but I guess unknown option "--set-dscpmark" also tells my that my iptables is not usable right now, which makes testing a tad tricky...
Also, if I want to use the firewall GUI to set the marking rules, I guess (naively?) that I need a generic mangle rule here that copies the existing DSCP into the connmark somehow.
That is the actual text in the GUI, which admittedly is not correct, since adjusting the MPU is required as the default of 0 is correct only increasingly rarely (on some ATM encapsulations).
For cable/DOCSIS you really should set mpu 64 how you do that, via the e/ingress options or via the GUI does not matter anymore (cake will honor the mpu value in the GUI.
As a non-gamer I would say probably, I might try to add the ingress keyword to the advanced option string for ingress, but that is all I can see. However if gaming sucks you might want to switch to layer_cake.qos and carefully up-priritize only the gaming packets. But that is a whole different kettle of fish.
Personally I would always first try without prioritization, but then I stopped reaction-time gated gaming shortly after the original quake came around, so have little first hand experience to base my recommendations on.
Same here. For various reasons, I need to stay on 19.07.x, is there a patch I can apply to that version of iptables (1.8.3 in my case) that would add in the set-dscpmark function ?
even if it's not reaction time gated... it can still suffer a lot from lag and lost packets. Something like Minecraft or Rocket League, you can get rubber-banding or crashing into things that you don't know are there or it doesn't register a jump... etc if that happens often enough even a game that can be played without fast reactions will be no fun.
@N1K - I (perhaps mistakenly) assume that since you're gaming, you're using a Windows desktop or laptop. If so, and if you're using a professional version of Windows, you can fairly easily add DSCP markings to the outgoing traffic by using gpedit.msc, the Group Policy Editor.
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.
@Dopam-IT_1987 how do you see the call of duty ports ? my game (cod warzone) always crashes because of wireshark but csgo and wireshark is working perfectly.
Yep, like moeller0 said, you can do it this way, or by including "mpu 64" in the advanced options strings for ingress and egress. I would point out dont do it in both spots, you will end up setting it to 128! (64+64) At least it used to do this years ago, as I found out to my embarrassment.
You could run tcpdump on the router's br-lan interface to see internal IP addresses and ports, no need to use wireshark on the gaming computer to capture the packets.
You can even direct tcpdump to write to file, and the use wireshark to load that file so you can use wireshark's convenient GUI and tooling.
I have not tried that myself, for the overhead keywords that behavior is intended, so that one can request accounting for vlan tags in addition to any other encapsulations, not sure why the same also applies to mpu, but I guess there is no good reason to request the same mpu twice....
