[Solved] Setting DSCP marking on a Dumb AP/Switch

I was wondering if it was possible to set DSCP markings on a dumb AP/Switch configuration. According to the OpenWRT documentation, dnsmasq, firewall, and dhcp should be disabled. Would it work to leave the firewall disabled, and put the the commands that mark dscp found in '/etc/firewall.user', in to '/etc/rc.local'?

For example, say the following command was invoked by the firewall, when loading '/etc/firewall.user':

iptables - t mangle -A FORWARD -p udp --dport 3074 -j DSCP --set-dscp-class CS5

Can I just move this command to '/etc/rc.local' and have it executed on it's own at system startup and still work with the firewall disabled?

Likely you'll need to enable iptables for bridging, as a typical "dumb AP" configuration doesn't do any routing.

Following on to that, the DSCP marks generally only impact routing (not bridging). Why not configure them at one point, the router?

My modem does not like SQM on the WAN interface (separate modem, router, and switch). It crashes quite often when it is on it. I've tried a lot of different things to get it to play nice with an instance on the WAN interface. Including two instances of SQM, egress only on the WAN (upstream) and LAN (downstream). Eventually, the modem stalls for a few seconds every now and then. It's an Arris SB6183 with a Broadcom chip (DOCSIS 3.0, no AQM on the head end). The end result is having to reboot my modem. Since SQM is on the LAN interface, configuring DSCP on the router for traffic coming in from the internet works fine, because it goes through the WAN interface, then firewall where it gets marked, then to SQM on the LAN interface. So I need a way to set the DSCP marks on the outgoing traffic, before it hits SQM on the LAN interface on my router. The outgoing traffic I am trying to set is from a Playstation 4, so there is no way for me to explicitly set the marks on the device.

Is there a more optimal solution to achieve this? I've read about veth solutions, but am not sure how to properly implement them.

That makes sense.

I think you can still mark at the central router (only), though I may not have your topology right in my head. What I'm thinking is along the lines of:

  • Playstation is connected to AP
  • AP bridges to Router LAN
  • Router examines packets arriving on LAN, tags those associated with the Playstation
  • SQM does its thing
  • Router strips the DSCP marks on the outbound interface

Yes, that is pretty much the topology of it. Except I'm not sure about stripping the DSCP marks on the outbound interface. Do the packets get tagged on the router when arriving at LAN from the AP before going in to the SQM ingress queue (inward interface) on the LAN so that they go in to the voice queue?

The router is running SQM diffserv4 on the LAN interface, with the following rules in '/etc/firewall.user':

iptables -t mangle -A dscp_mark -p udp --dport 3074 -j DSCP --set-dscp-class CS5
ip6tables -t mangle -A dscp_mark -p udp --dport 3074 -j DSCP --set-dscp-class CS5
iptables -t mangle -A dscp_mark -p udp --sport 3074 -j DSCP --set-dscp-class CS5
ip6tables -t mangle -A dscp_mark -p udp --sport 3074 -j DSCP --set-dscp-class CS5
iptables -t mangle -A dscp_mark -p udp --dport 3478:3479 -j DSCP --set-dscp-class CS5
ip6tables -t mangle -A dscp_mark -p udp --dport 3478:3479 -j DSCP --set-dscp-class CS5
iptables -t mangle -A dscp_mark -p udp --sport 3478:3479 -j DSCP --set-dscp-class CS5
ip6tables -t mangle -A dscp_mark -p udp --sport 3478:3479 -j DSCP --set-dscp-class CS5
iptables -t mangle -A dscp_mark -p tcp --dport 3478:3480 -j DSCP --set-dscp-class CS5
ip6tables -t mangle -A dscp_mark -p tcp --dport 3478:3480 -j DSCP --set-dscp-class CS5
iptables -t mangle -A dscp_mark -p tcp --sport 3478:3480 -j DSCP --set-dscp-class CS5
ip6tables -t mangle -A dscp_mark -p tcp --sport 3478:3480 -j DSCP --set-dscp-class CS5

I just want to make sure the outbound traffic on these ports are sent the appropriate queue in SQM. I'm not clear as if it has to traverse the LAN->WAN before recieving these tags. At that point if it does it would of already left the SQM queue (defeating the purpose).

Iptables runs after the ingress queuing. Is there a separate AP involved? You can mark on the AP then the marks will be there when received by router. Another option is to upgrade your router to one that isn't flaky on wan.

Yes, there is a separate AP involved.

PS4 -> AP -> Router (SQM on LAN) -> Internet

The AP is set up as a dumb AP at the moment with firewall disabled. What configuration steps would I take to enable the firewall or iptables on the AP so that it marks the packets and act as though it was disabled in terms of enforcing other rules? Pretty much minimal routing/rules that allows DSCP marking for an AP/switch setup.

Enable the firewall, You can use your marking code, turn on bridge firewalls in sysctl (look up how, it's a couple of ctls one for ip4 one for ip6) remember to enable forwarding from LAN to LAN via a forwarding rule.

I think it needs a bridge netfilter package too

Thank you for the help. I will give it a try.

kmod-br-netfilter, correct?

Do I have to install the -extra packages and modules for iptables as well?

I think that's the one, not sure what else needed. Just try it and add packages if needed

Wow, that is really strange. And you're not running the problematic PUMA6 chipset either. It's hard to see how the shaping or fairness aspects of SQM could cause a SB6183 hang. Although it seems improbable, your description of workarounds suggests the modem possibly might not like non-zero DSCP, though I've never read about either your stalls or a DSCP problem before...

@mj5030 As part of your troubleshooting with SQM on WAN, did you try disabling prioritization and zeroing any DSCP outbound? Just curious, but if that's the case it might offer a simpler solution for you.

He wants prioritization so disabling it in order to get wan to work isn't a very good solution.

No one suggested that as a solution. As stated above, the point of "disabling prioritization / zeroing any DSCP outbound" is to troubleshooting further by removing DSCP from the equation. If @mj5030's modem stalls are DSCP related and disappear (which would also be odd), then the obvious solution is to bleach/wash/zero DSCP on WAN egress.

Except that of course results in zero prioritization of egress. So it would have to work together with prioritization in LAN ingress, and tagging in the AP and no SQM on WAN. But point taken if modem doesn't like DSCP zero it before sending.

Uh, no. It's entirely possible to configure prioritization and zero DSCP for an interface. A qdisc like CAKE even supports the wash parameter.

The point being, if the modem really doesn't like DSCP, the simplest option is to put prioritized SQM on WAN and zero any egress DSCP. This avoids unnecessary funny business with LAN SQM or tagging in the AP.

But we're all in the dark a bit, and will know more once @mj5030 can share some details of their troubleshooting as requested earlier (their /etc/config/sqm would help too).

I don't think it has to do with DSCP. I've tried it with cake/piece of cake, with no DSCP rules in the 'etc/firewall.user' and it has occurred. When running a download on my PS4 (wired directly to router during test), then running a speed test on my laptop and running a ping on 8.8.8.8 (connected via wireless to the router), after a couple of speed tests my PS4 download stalls for a few seconds. The download drops from ~10-20MB/s to about 0.1MB/s, as well as the speed test, and the ping test jumps to >1000ms-3000ms for a few seconds.

The weird thing is, that after this occurs I have tried turning off all SQM instances, and rebooted the router. After the router boots up I have pinged my ISP's gateway and still have had the ping spikes every 10 seconds or so. It does not go away until the modem itself is rebooted.

Here is the SQM config I have tried when on the WAN and LAN instance (eth0 is WAN, eth1 is LAN, 215Mbps down, 21.5Mbp up, TL-WR1043NDv3 running Fast Path, Gwlim's July 2018 build):

config queue
	option debug_logging '0'
	option verbosity '5'
	option interface 'eth1'
	option upload '195000'
	option qdisc 'cake'
	option qdisc_advanced '1'
	option ingress_ecn 'NOECN'
	option egress_ecn 'ECN'
	option qdisc_really_really_advanced '1'
	option enabled '1'
	option download '0'
	option script 'piece_of_cake.qos'
	option squash_dscp '1'
	option squash_ingress '1'
	option eqdisc_opts 'nat dual-dsthost mpu 64'
	option linklayer 'ethernet'
	option overhead '18'

config queue
	option debug_logging '0'
	option verbosity '5'
	option squash_dscp '1'
	option squash_ingress '1'
	option egress_ecn 'NOECN'
	option interface 'eth0'
	option download '0'
	option upload '18500'
	option qdisc 'cake'
	option script 'piece_of_cake.qos'
	option qdisc_advanced '1'
	option ingress_ecn 'NOECN'
	option qdisc_really_really_advanced '1'
	option iqdisc_opts 'nat dual-srchost mpu 64'
	option linklayer 'ethernet'
	option overhead '18'
	option enabled '1'

I have tried different overheads of 0, 18, 28 and a combination of such (28 and 18 on WAN interface, 0 on LAN). With and without 'mpu 64' and 'nat dual-*host'.

My current SQM config is:


config queue
	option debug_logging '0'
	option verbosity '5'
	option interface 'eth1'
	option upload '195000'
	option qdisc 'cake'
	option qdisc_advanced '1'
	option ingress_ecn 'NOECN'
	option egress_ecn 'ECN'
	option qdisc_really_really_advanced '1'
	option enabled '1'
	option script 'layer_cake.qos'
	option squash_dscp '0'
	option squash_ingress '0'
	option linklayer 'none'
	option iqdisc_opts 'nat dual-srchost diffserv4'
	option download '18500'
	option eqdisc_opts 'nat dual-dsthost diffserv4'

It's working just fine. Just needed to make sure that the packets entering the SQM queue that I need to take priority are being marked properly. @dlakelan has provided me how to achieve this by marking them on the AP.

Thank you for all the help provided by everyone. I'm going to mark this topic as solved as the original issue has been resolved. If anyone can see errors in the SQM configuration that uses both the LAN and WAN interface that would cause my modem to stall please feel free to PM me regarding it. Thank you again!

Got it, I thought you meant to strip it in iptables, where it would be gone already when the queue saw it.

@mj5030 it sounds like you might have some kind of issue with drivers in your particular hardware.

It very well could be. There has been a firmware update for the modem, but the ISP has not pushed it yet. Even though it has been out for a couple years.

I have found this:

Even though I do not have an eero mesh system. It could be something the wireless is doing in conjuction with QoS/SQM that is causing the problem. The firmware listed in that support article is the one currently on my SB6183.

I guess I should contact my ISP and request that they look in to pushing an update.