PTP 224.0.0.x and 224.0.1.x Multicast on 21.02

[systemcrash]

Need some help setting up multicast on an Archer C7 v2, which has eth1 = lan and eth0 = wan. The eth1 MAC shows as LAN.

I run
ptp4l -i eth1 -m -S

And it does its thing. It multicasts/broadcasts to e.g. 224.0.1.x and 224.0.0.x when you also specify -P. The specification mandates as follows:

IANA assigned name	Address
PTP-primary	224.0.1.129
PTP-pdelay	224.0.0.107

Enable multicast support are checked under eth1, wlan0, wlan1 devices (default).

When I run tcpdump on eth1, I see traffic from my WAN IP bound for the multicast networks, instead of the expected 192.168.1.1. tcpdump on eth0 confirms it does not egress there, and tcpdump on br-lan confirms it does not egress there. Local workstation pcaps also confirm this. The pcaps show the LAN MAC but the source IP is the WAN IP....

I tried
route add -net 224.0.0.0 netmask 224.0.0.0 br-lan and route add -net 224.0.0.0 netmask 224.0.0.0 wlan0 etc from the wiki. No joy. Tried also more specific:

route add -net 224.0.1.129 netmask 255.255.255.255 wlan0

What firewall or other magic am I missing, to steer these broadcast packets to the br-lan? Do I need to make a new bridge in DSA?

Edit: tried the recommended options Multicast to unicast for wlan0 and eth1 but still nothing.

[systemcrash]

Also noticed:

ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
	software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
	software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
	software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

but

ethtool -T br-lan
Time stamping parameters for br-lan:
Capabilities:
	software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
	software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

i.e. TX is conspicuously missing, from where TX should probably be done.

Changed LAN from br-lan to eth1, and then packets originate from the LAN IP. BUT... still don't propagate to any other interface on the bridge because it's now disconnected...

[systemcrash]

ptp4l -2 -A -i <LAN> -S now seems to work as intended on 22.03.3