CAKE w/ DSCPs - cake-qos-simple

plater · November 21, 2023, 5:01am

I’m interested in applying cake-qos-simple to only specific MAC’s. I’ve commented out the necessary parts and it appears to work. Is there a better way to go about it?

ether saddr { XX:XX:XX:XX:XX:XX, XX:XX:XX:XX:XX:XX } oifname wan ct mark & 128 == 0 goto store-dscp-in-conntrack

Edit:
Looks like there’s more I would need to do and I’m not sure it’s within this projects scope. Sorry for the noise.

Lynx · November 22, 2023, 3:45pm

Looks fine to me - only classify connections coming from certain source MACs that have yet to be classified?

Seems well within scope to me. Helpful to explore ways to customize things.

plater · November 22, 2023, 4:18pm

I‘ve been running with it since I posted about it and it’s working well. I just feel more comfortable applying conntrack to only machines that need it and that I’m in complete control of. It limits the potential for abuse and unforeseen issues.

I thought I could make it more efficient if I did it via the ‘tc filter’ portion of the script but my knowledge is lacking. It seems I would need to add a new line per MAC if I go that route. I didn’t get too far. I just have this in my notes should I get motivated to come back to this.

u32 match ether src XX:XX:XX:XX:XX:XX

Dopam-IT_1987 · November 22, 2023, 5:58pm

@Lynx do we agree that with this script we need to add our own dscp marks for it to be effective and fair?

Lynx · November 22, 2023, 6:05pm

plater:

I thought I could make it more efficient if I did it via the ‘tc filter’ portion of the script but my knowledge is lacking. It seems I would need to add a new line per MAC if I go that route. I didn’t get too far. I just have this in my notes should I get motivated to come back to this.
u32 match ether src XX:XX:XX:XX:XX:XX

I wouldn't go that route. What you could do instead is have nftables apply a mark and then match on that mark in tc - like so:

github.com

lynxthecat/cake-dual-ifb/blob/17b7eacd80056f326384acd14f8ebdfe8a810364/cake-dual-ifb.nft#L80


      
          	chain process-lan-to-wan {
          
          		# Handle DNS hijacking (effectively resulting in openwrt-to-wan)
          		tcp dport 53 mark set 2 goto process-openwrt-to-wan
          		udp dport 53 mark set 2 goto process-openwrt-to-wan
          
          	}
          
          	chain process-wan-to-lan {
          
          		oifname $IFACE_NAMES mark set 1
          		
          		# Handle DNS hijacking
          		tcp sport 53 mark set 0
          		udp sport 53 mark set 0
          
          	}
          
          	# OpenWrt->wan dscp classication by router
                  chain classify-dscp {

github.com

lynxthecat/cake-dual-ifb/blob/master/cake-dual-ifb#L30


      
          
          		tc qdisc add dev $iface handle ffff: ingress
          		tc qdisc add dev $iface handle 1: root prio
          
          		# capture $if (ingress) -> wan 
          		# filter on fwmark 1
          		tc filter add dev $iface parent ffff: protocol all handle 1 fw flowid 1:1 action mirred egress redirect dev ifb-ul
          
          		# capture wan -> $iface (egress) and restore DSCPs from conntracks
          		# filter on fwmark 1
          		tc filter add dev $iface parent 1: protocol all handle 1 fw flowid 1:1 action ctinfo dscp 63 128 action mirred egress redirect dev ifb-dl
          
          	done 
          
          	tc qdisc add dev wan handle ffff: ingress
          	tc qdisc add dev wan handle 1: root prio
          
          	# capture OpenWrt -> wan (egress)
          	# filter by fwmark 2 (use nftables to skip over WireGuard traffic with fwmark 3 and apply fwmark 2 to the remainder)
          	tc filter add dev wan parent 1: protocol all handle 2 fw flowid 1:1 action mirred egress redirect dev ifb-ul

But I'm not sure what the advantage of that would be versus instead just limiting classification in nftables to source MAC as you do already.

Correct - it's up to the user to set the outbound DSCPs as desired using nftables and/or by setting it in the individual LAN clients. I personally have mixture - e.g. router sets stuff like DNS requests or NTP requests to 'voice' and my office computer sets Teams/Zoom traffic to mixture of 'video' and 'voice'.

Dopam-IT_1987 · November 22, 2023, 6:08pm

ok thanks for your reply
to be clear, the rules I want to set are not to be added in the script itself, but in luci traffic rules for example.

or an own .nft script

Lynx · November 22, 2023, 6:16pm

You can tweak /root/cake-qos-simple/nft.rules and follow template or add your own rules. Or use LuCi.

plater · November 22, 2023, 6:17pm

That’s reassuring, thank you! If you think this feature is worthy of addition then I’d be happy to test.

Lynx · November 22, 2023, 6:19pm

It's difficult to generalise. My thinking is that with the custom nft.rules file users can easily add their own rules for individual use cases by following the nftables format. I don't see the point in making a separate system for cake-qos-simple that translates to nftables rules.

plater · November 22, 2023, 6:28pm

That’s a big reason why I chose this solution. It’s easily hackable!

Lynx · November 22, 2023, 7:23pm

Yes it’s very powerful. I think leveraging connection tracking is super useful to enable setting of DSCPs on upload at router and/or by individual LAN clients, saving those to conntrack, and then restoring DSCPs on download. And harnessing nftables directly provides the flexibility and power that comes with that.