So this test is a pretty simple setup. Single RB962 (hAP ac) serving the whole network. Running 6.43.4.

I am attempting to account for the network usage of a Chromecast.

I created a firewall rule that matches the Chromecast's MAC address and adds that IP address to an address list.
This works, and adds 172.16.44.193 (the verified internal IP address) to the address list, corresponding to that Chromecast's MAC address.

The reason I need the address list is because the Firewall Filter allows for Src MAC Address but does not allow for Dst MAC Address. So fine, I use the rule above to create the address list with an IP that I can match against. This way whenever the IP address of the Chromecast changes, I can continue to account for its usage.

Unfortunately no matter what I do, whether using Filter or Mangle, I cannot get more than a trickle of usage matched. The most it ever shows is around 100 kbps in a 1-second interval; and most often far less. I am testing this by sending a 4k stream to the Chromecast, and I can see an 8 Mbps throughput in Torch.

As I said above, I have tried Filter and Mangle, and I have used dst-address-list, with no other parameters (not even an interface or protocol), with all the chains (prerouting, postrouting, forwarding), and nothing changes. I have Fast Forward and Fast Path disabled, and have Use IP Firewall enabled on the bridge, just to be safe.

The other oddity is that when I Torch the Wi-Fi interface, the internal IP address (172.16.44.193) shows up as a Src Address for the 8 Mbps throughput. I would have expected this to be the Dst Address. Given that, I tried using src-address-list instead, and that didn't help. I have also tried using the exact IP address in both src-address and dst-address, and still nothing.

I've made sure the Filter or Mangle rule is at the top of the list, too.

This has to be something simple I'm just missing... Any ideas?

I am not a expert on this but some things are explainable.

MAC addresses outside your router are not know so you can only use MAC addresses inside your local network.
The device is requesting the traffic and that could be why it is shown as source.

I would add the dst-IP to the addresslist on basis of the MAC in RAW. Then filter in RAW incomming on that IP comming in and then being a src-IP.

Then a differen IP can sent back the stream and so not seen by the RAW filter on src-IP. This is called related and if you remove related and only keep established. This is posible in MASQ and filter.

I hopeI helped in the correct direction.

Thanks for your reply. Turns out I did not fully disable Fast Path, doh.

Now that it is off, I have created a Mangle that marks the connection based on the dst-address-list, and a Mangle that marks the packet from the connection.

The next issue is that I am attempting to make this more efficient on the router by only looking at new connections instead of all, similar to how I do a 2-step egress QoS, where the new connection is marked first, and then only the packets belonging to that connection are marked. This saves CPU time by not having to deep inspect every packet, but only the first packet of a new connection.

Unfortunately I am not having any luck. This is probably due to the way masquerade works. I suppose the new connection is marked on the egress to WAN, not on the ingress from WAN. So I probably just have to turn around my connection-marking rule to look for the source of the Chromecast to WAN, rather than the destination to Chromecast from WAN.

Alright, here's what I ended up doing, in case anyone else would be interested in the same thing without using queues.

Unfortunately I couldn't get the mangle rules to work when trying to 2-step connection-mark and packet-mark. Maybe I will revisit again at a later time. So far the RB962 (hAP ac) CPU can keep up with this method. If anyone has any ideas how to do this more efficiently, please let me know.

Now I can use the statistics on those two mangle rules to see the current rate and how much data has been consumed.

The Chromecast downloads a new background image every minute by default, and with a 4-minute sample from power-on, it extrapolates out to 102 GB per month of data. I am capped at 200 GB.

There is a new low-bandwidth mode available in the experimental section of the ambient settings now, and supposedly when enabled the Chromecast will not download backgrounds. But with a 10-minute sample, it extrapolates out to 52 GB per month. Okay better, but still... that's outrageous. What is it doing? LOL. I'll update this after the 20-minute sample has finished.

Edit: ok, after a 3-hour sample it extrapolates out to 6 GB monthly, and continuing to fall. At this point the counters are at only 23 MB ingress and 3.2 MB egress. That sure seems like a lot of egress, but overall it's small, so the extrapolation will continue to drop. My hypothesis is that when it's in the "low-bandwidth" mode, it downloads the first five background images, and then does not download anymore, and just rotates between those.