<div dir="ltr">Apologies if this is the wrong list, but cerowrt-users is empty and I'm not sure if I should spam the codel or sqm related lists.<div><br></div><div><div>I can't quite wrap my head around how the "Squash DSCP on inbound packets (ingress):" and "Ignore DSCP on ingress" work under the SQM Luci page and how this might affect my rules for --set-dscp</div><div><br></div><div>I'm trying to flag all packets on a certain port to/from a certain interface (sw10) as DSCP 0x2e (or EF), which WMM should set as VoIP (for mumble voice traffic, which the mobile phone app or the server doesn't seem to set properly so the phone thinks it's regular traffic)</div><div><br></div><div>I took a look at the simple.qos script, as well as the mangle table but I'm still a bit confused. Here's the relevant snippet from 'iptables -S -t mangle' with it set to "DO NOT SQUASH" and "ALLOW"</div><div><br></div><div>-N QOS_MARK_ge00<br></div><div>-N fwmark<br></div><div><div>-A PREROUTING -i vtun+ -p tcp -j MARK --set-xmark 0x2/0xff</div><div>-A PREROUTING -i ge00 -m mark --mark 0x0/0xff -g QOS_MARK_ge00</div><div>-A PREROUTING -j fwmark</div></div><div><div>-A POSTROUTING -o ge00 -m mark --mark 0x0/0xff -g QOS_MARK_ge00</div></div><div><div>-A QOS_MARK_ge00 -j MARK --set-xmark 0x2/0xff</div><div>-A QOS_MARK_ge00 -m dscp --dscp 0x08 -j MARK --set-xmark 0x3/0xff</div><div>-A QOS_MARK_ge00 -m dscp --dscp 0x30 -j MARK --set-xmark 0x1/0xff</div><div>-A QOS_MARK_ge00 -m dscp --dscp 0x2e -j MARK --set-xmark 0x1/0xff</div><div>-A QOS_MARK_ge00 -m dscp --dscp 0x24 -j MARK --set-xmark 0x1/0xff</div><div>-A QOS_MARK_ge00 -m tos --tos 0x10/0x3f -j MARK --set-xmark 0x1/0xff</div></div><div><br></div><div>and the full iptables -vnL -t mangle output is here (to reduce spam): <a href="https://pastebin.com/raw.php?i=uba2n1qw">https://pastebin.com/raw.php?i=uba2n1qw</a></div><div><br></div><div>From what I understand, this is just MARKing all incoming packets from ge00 for use in fq_codel based on it's DSCP tag? But does it change the DSCP when coming in and going out? Also curious why this isn't enabled by default, does it cause excessive CPU load? It seems like a gain to me.</div><div><br></div><div>Anyways, back to my other question. I'm trying to flag tcp/udp port 6484 going to/from sw10 and these rules seems to work</div><div><br></div><div><div>-t mangle -I <table> -i sw10 -p udp -m udp --dport 6484 -m comment --comment "reclassify mumble traffic as VoIP" -j DSCP --set-dscp 0x2e</div><div>-t mangle -I <table> -i sw10 -p tcp -m tcp --dport 6484 -m comment --comment "reclassify mumble traffic as VoIP" -j DSCP --set-dscp 0x2e</div></div><div><div>-t mangle -I <table> -o sw10 -p udp -m udp --sport 6484 -m comment --comment "reclassify mumble traffic as VoIP" -j DSCP --set-dscp 0x2e</div><div>-t mangle -I <table> -o sw10 -p tcp -m tcp --sport 6484 -m comment --comment "reclassify mumble traffic as VoIP" -j DSCP --set-dscp 0x2e</div></div><div><br></div><div>However, I'm a bit uncertain which mangle zone to insert them into. My first thought would be to put them in the mangle FOWARD chain since it's traffic passing through the router, which I made two new zones to jump through if it sees traffic to/from sw10 but I'm not entirely certain it was working in the FORWARD chain. I did see pkts and bytes counting upward but I'm not sure it was catching ALL the traffic, or how it is related to WMM/WME which I need to function properly. next I tried the mangle PREROUTING, mangle FORWARD, and mangle POSTROUTING chains, which all 3 showed pkts and bytes but the most were in FORWARD. this is probably redundant so perhaps it only needs PREROUTING/POSTROUTING? or only FORWARD?</div><div><br></div><div>Also, the "fwmark" chain doesn't appear to do anything unless I'm misunderstanding it. I don't see anything else referencing the chain. what is it's purpose? should this have the same MARKing rules as the QOS_MARK_ge00 table, but for forwarding? Or does marking in the PREROUTING table automatically apply to FORWARD traffic making that redundant?</div><div><br></div><div><div>Chain PREROUTING (policy ACCEPT 425K packets, 395M bytes)</div><div> pkts bytes target     prot opt in     out     source               destination</div><div>    0     0 MARK       tcp  --  vtun+  *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>            MARK xset 0x2/0xff</div><div>1705K 2048M QOS_MARK_ge00  all  --  ge00   *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>           [goto]  mark match 0x0/0xff</div><div> 188K   86M fwmark     all  --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a></div></div><div><br></div><div><br></div><div>Thanks in advance, and I appreciate all the work Dave and everyone else here is doing to improve the internet. I understand Cero is more of a proof of concept and testing tool, but I like to stay more on the bleeding edge of this sort of stuff due to my highly latency sensitive traffic requirements.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>