From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 66D6121F2F8 for ; Mon, 13 Apr 2015 00:36:54 -0700 (PDT) Received: from hms-beagle.home.lan ([87.164.165.7]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Ledpu-1ZAo8o1lOw-00qU8G; Mon, 13 Apr 2015 09:36:52 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 13 Apr 2015 09:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: leetminiwheat X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:akIvExgvYeZGM5Yl2bhKIgtJsGTRvk6pW19pQ0V5Y69zElh82v+ TOtec0prhFx6vcDhDDJQkvUrk+BNqPn9omqVIdIq6UEbCuvVJo8jjtIYagkF3/ggzWnyzmg Ao5/fgY+kYF6ifMDftI/Y93HNfB9VCCYpFBMCsVFWgiJk2UL0sgHwAHcn4HnOI1fn6JM7yF UzmAn5KbJjdDDmzwspFXQ== X-UI-Out-Filterresults: notjunk:1; Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] squash/ignore DSCP and mangle table questions X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 07:37:24 -0000 Hi, On Apr 13, 2015, at 08:37 , leetminiwheat = wrote: > 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. >=20 > 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 "Ignore DSCP on ingress=94, this basically uses an 1-tier HTB = shaper on ingress, DSCP marks in the packets are simply ignored, but not = touched. "Squash DSCP on inbound packets (ingress):=94 this will replace = all DSCP marks with 0x0 (I believe), but only after the ingress qdisc. In essence this means you can actually interpret ingress DSCP marks from = upstream ("Ignore DSCP on ingress=94 set to ALLOW) but wipe them after = the ingress shaping (with "Squash DSCP on inbound packets (ingress);=94 = active). So the default should be =93Ignore DSCP on ingress=94 and = Squash (the second can be argued, as long as no one bases routing = decisions on the marks they do not hurt). The rest of your questions are = beyond my expertise... Best Regards Sebastian >=20 > 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) >=20 > 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" >=20 > -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 >=20 > and the full iptables -vnL -t mangle output is here (to reduce spam): = https://pastebin.com/raw.php?i=3Duba2n1qw >=20 > =46rom 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. >=20 > 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 >=20 > -t mangle -I -i sw10 -p udp -m udp --dport 6484 -m comment = --comment "reclassify mumble traffic as VoIP" -j DSCP --set-dscp 0x2e > -t mangle -I
-i sw10 -p tcp -m tcp --dport 6484 -m comment = --comment "reclassify mumble traffic as VoIP" -j DSCP --set-dscp 0x2e > -t mangle -I
-o sw10 -p udp -m udp --sport 6484 -m comment = --comment "reclassify mumble traffic as VoIP" -j DSCP --set-dscp 0x2e > -t mangle -I
-o sw10 -p tcp -m tcp --sport 6484 -m comment = --comment "reclassify mumble traffic as VoIP" -j DSCP --set-dscp 0x2e >=20 > 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? >=20 > 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? >=20 > 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 >=20 >=20 > 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. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel