Im a total networking noob. Ive been experimenting with openwrt and all its configurations. Im stuck on this particular one and any help is greatly appreciated.
I have docker and wireguard running. Im using vpn policy to route my torrent docker through wireguard and using cake on eth0. Im using qosify at the moment but ive tried two cake instances on eth0 and eth1 but none are populating diffserv4 ingress. Ive been trying to set up veth 0 and veth 1 with veth1 bridged to br-lan and instance on veth 0. Seems to work but dosent populate the docker traffic.
My goal is to get diffserv working with wireguard and wan on ingress and egress. I have 1 lan and 1 wan port on nanopi r4s and use an ap on lan for wifi. eth0 is wan and eth1 is lan I think.
Any ideas on what I could do?
I think you need to instantate cake on those interfaces that see wireguard traffic in un-encrypted form, otherwise all that is visible is the wireguard "envelope" header and that will not allow differential treatment. For egress traffic there is a way of having wireguard convey information about packets flow identity to cake (IIRC via firewall marks?), but that will not work for ingress and also is incompatible with some of cake's more sophisticated fairness modes (but for most use-cases the flow-fairness it does allow will already help a lot).
I only have one ip (the torrent docker) going thorugh wireguard so I dont mind if it see it as a single flow. Is there a way to shift all this traffic into bulk?
Or do I need to assign all traffic to bulk and then target which ip and ports to go into the tins, would that work?
edit: Would dscp marking the wireguard network device mac address make any difference?
Fair enough, that will be the default behaviour if cake runs on an interface that only sees encrypted wireguard traffic...
For egress probably yes, for ingress it depends on how much work you are willing to perform and how stable your remote wireguard IP address is. I think qosify in the current snapshots might actually allow to filter on external addresses, but have never tried myself.
That would work as well, but the bulk tin has little guaranteed throughput, so I would hesitate to move everything into bulk. My approach is more like, keep everything in best effort, and only gently steer a few select and unambiguous cases to lower or higher priority tins; torrents into bulk seems a decent case for bulk.
Foe egress traffic that would probably work, the big problem with DSCP marking typically is on ingress, SQMS's default ingress shaping happens on an IFB and at that stage neither the internal MAC address nor the internal IP address is really available for DSCP marking filters. (Cake itself can peek into the conntrack table to get information about internal IP addresses and hence can share ingress capacity fairly between all active internal IPs, but neither nftables nor tc, know this trick, hence DSCP remarking based on internal MAC/IP addresses for ingress is hard).
1 Like