I'd like to use setup where my wlan interface has its own bridge and be reachable from any lan-bridge devices. The reasons... in short, I'd like to use fasttrack and queues.

I have one normal bridge, where all LAN interfaces are bridged to.
Internet link is on SFP1 interface, a DHCP client. I can put SFP1 to its own bridge and run DHCP client on that bridge. It partially works - MT device itself can reach internet, but devices in the lan-bridge cannot. What should I set more?
Thanks.

it started working when i set wan interface-list to the wan-bridge. just in case anyone sees this.
but... it does not work as i expected from queue tree point of view. parent of download traffic is still only lan-bridge and not wan-bridge, as i'd hoped it would...

To be able to use fasttrack and queues you don't have do mess with bridges too much. You can exempt some traffic from being fasttracked by using proper fasttrack criteria. A couple of threads on this forum have been written about this in past month or two.

My currently favourite solution is to mark connections that are supposed to be affected by queues (marking is done by mangle rules) and fasttrack rule fasttracks only unmarked connections. Works like a charm.

Yes... But. There is always a but.
I figured out my Hap AC maxes its CPU at around 100M download from the internet, so I fasttracked heaviest connections and used queue tree with hardware parent to give connections with no-mark lowest priority. In upload direction it isn't a problem, as I only have one internet interface. Problem is with download, because I need to set bridge-lan as download parent and it has side effects:
1. I can't fasttrack connections inside my LAN (e.g. DNS requests and hairpin-ed connection to my server), as they enqueue lowest in my queue tree and are also limited by its bandwidth.
2. If I have more than one bridge (e.g. another for guests), traffic from other bridge cannot be put into same download tree.
3. Traffic from VPN connections also does not have bridge-lan as its parent, so basically same as previous point.

So, I tried to create bridge-wan to use that as queue's download parent interface. I think that solution maxed CPU even faster
I prefer hairpin NAT rule instead of static DNS entry, because I can remap ports this way (I'm using Synology, which is using non-standard ports for web access).
Any idea how to to fasttrack internal connections without queue seeing the traffic?

Hi

The queue tree attached to an interface will see only traffic linked to the declared packet marks. So if you mark a packet as say "internal" and there is no class for it in queue tree, it will not be accounted.

BUT, fasttracked packets bypass (most of the time) mangling and hence will have no mark set...

Conclusion: once fasttracked, there is no way to differentiate it within queue tree

Exactly. I think the fasttrack right now is half a step in right direction. I'd like to see MT to make that step till the end - it only makes sense to fasttrack heavy traffic and that one needs to be accounted in queues, not make them inpossible to use.

it only makes sense to fasttrack heavy traffic and that one needs to be accounted in queues, not make them inpossible to use.

This can be done already (and I'm doing it in my configs). Only mark bulk traffic as fast-tracked. Any traffic of value, goes the normal / "full" / "slow" path, with full control over it.

Ex possible fasttrack rule
-> you can add any condition you want...

Yes, but as fast track is implemented now, it ruins qos, if you have more than one bridge (guests) or using VPN. Solving this is second half of the step I was talking about.

My understanding is that fasttrack doesn't care about bridges or VPNs, it only fasttracks connections. If you construct fasttrack rule that keeps some connections on "slow" track, you have all the usual tools to deal with those. And, if I understood correctly, you can have more than one fasttrack rule (one after another) if needed to be specific enough.

Indeed. Fast track only ruins qos. Qos was one of key reasons to use MT.

Sent from my E5823 using Tapatalk