Actually, I can specify the mac address of a batman node on its mesh, and I can use that specified mac address in /etc/bat-hosts. And it works very well, but only until the third node arrives in the mesh. Then it keeps working (usually) for up to ten seconds, whereupon "batctl p" stops working from/to any pair of the 3 nodes, despite the fact "batctl o" shows all nodes present and accounted for at all 3 nodes.
Perhaps weirdly, I did not have this problem with my post-19.07 "lucky snapshot". However, when I (ultimately successfully, thanks to mk24) began to migrate to 21.02-rc3, I found it necessary to move the "option macaddr" from the "config interface lan" stanza to the new "config device" bridge declaration before batman would work at all. Having made that move, batman worked, but with no more than 2 nodes in the mesh, as already explained. After removing the "option macaddr" line from the "config wifi-iface 'mesh0' stanza in /etc/config/wireless, everything began to work correctly from a batman perspective, but mac addresses in the mesh network are now unpredictable. This makes management awkward. I'd prefer to be in a position to tell the hardware how it should behave, so that, for example, a failed node can be quickly replaced with a working one after simply configuring it, carrying it to its location, and plugging it in. Modularity. But here I seem to have a situation where the hardware has to be configured and made to run batman in order to discover how I should then reconfigure both it and all the other members of its mesh. Not as modular as I would like.
Is there a safe, stable way to specify the mac address of a node within its mesh? I wonder: am I having these problems because of the way in which batman depends on the 802.11s implementation in the non-CT QCA-988x driver (ath10k-qca988x)?
Or is it really necessary to fall back on the batadv-vis/A.L.F.R.E.D. runtime solution to the problem? Am I being too much of a control freak, demanding a layer-3 level of control in a mixed layer-3/layer-2 arena?