[Cerowrt-devel] squash/ignore DSCP and mangle table questions

leetminiwheat LeetMiniWheat at gmail.com
Mon Apr 13 02:37:06 EDT 2015


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.

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

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)

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"

-N QOS_MARK_ge00
-N fwmark
-A PREROUTING -i vtun+ -p tcp -j MARK --set-xmark 0x2/0xff
-A PREROUTING -i ge00 -m mark --mark 0x0/0xff -g QOS_MARK_ge00
-A PREROUTING -j fwmark
-A POSTROUTING -o ge00 -m mark --mark 0x0/0xff -g QOS_MARK_ge00
-A QOS_MARK_ge00 -j MARK --set-xmark 0x2/0xff
-A QOS_MARK_ge00 -m dscp --dscp 0x08 -j MARK --set-xmark 0x3/0xff
-A QOS_MARK_ge00 -m dscp --dscp 0x30 -j MARK --set-xmark 0x1/0xff
-A QOS_MARK_ge00 -m dscp --dscp 0x2e -j MARK --set-xmark 0x1/0xff
-A QOS_MARK_ge00 -m dscp --dscp 0x24 -j MARK --set-xmark 0x1/0xff
-A QOS_MARK_ge00 -m tos --tos 0x10/0x3f -j MARK --set-xmark 0x1/0xff

and the full iptables -vnL -t mangle output is here (to reduce spam):
https://pastebin.com/raw.php?i=uba2n1qw

>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.

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

-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
-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
-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
-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

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?

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?

Chain PREROUTING (policy ACCEPT 425K packets, 395M bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 MARK       tcp  --  vtun+  *       0.0.0.0/0
0.0.0.0/0            MARK xset 0x2/0xff
1705K 2048M QOS_MARK_ge00  all  --  ge00   *       0.0.0.0/0
0.0.0.0/0           [goto]  mark match 0x0/0xff
 188K   86M fwmark     all  --  *      *       0.0.0.0/0
0.0.0.0/0


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20150413/1f66390a/attachment-0002.html>


More information about the Cerowrt-devel mailing list