So. I removed wpad-basic-wolfssl and installed wpa-supplicant-mesh-openssl. It helped:
root@rpc149:~# logread | grep -i wpa
Fri Jun 25 10:12:59 2021 daemon.notice wpa_supplicant: Successfully initialized wpa_supplicant
Fri Jun 25 10:13:53 2021 daemon.notice wpa_supplicant: wlan0: leaving mesh
Fri Jun 25 10:13:54 2021 daemon.err wpa_supplicant: wlan0: mesh leave error=-134
Fri Jun 25 10:13:56 2021 daemon.notice wpa_supplicant: wlan0: interface state UNINITIALIZED->ENABLED
Fri Jun 25 10:13:56 2021 daemon.notice wpa_supplicant: wlan0: AP-ENABLED
Fri Jun 25 10:13:56 2021 daemon.notice wpa_supplicant: wlan0: joining mesh meshD
Fri Jun 25 10:13:56 2021 daemon.notice wpa_supplicant: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed [id=0 id_str=]
Fri Jun 25 10:13:56 2021 daemon.notice wpa_supplicant: wlan0: MESH-GROUP-STARTED ssid="meshD" id=0
...but Batman still wasn't working. "batctl o" still produced no output at all. And what's this about "wlan0", an identifier which appears nowhere in my configuration??
Experimentally, I changed "config wifi-iface 'mesh0'" to "config wifi-iface 'wlan0'". No help. So I put it back the way it was. Then I changed "option network 'nwi_mesh0' in that same stanza to "option network 'wlan0'". Accordingly, in /etc/config/network, I also changed "config interface 'nwi_mesh0'" to "config interface 'wlan0'". Now, at last:
There's no need to force names onto radio interfaces, just let it propagate the other way with option network.
The wpad series of packages include both hostapd and wpa-supplicant capability, so you don't need to install wpa-supplicant separately.
Run iwinfo wlan0 assoclist to see if there is a radio link to at least one other node. If there is, you can conclude that the radio and wpad are configured properly, and it should be sending packets to the BATMAN layer.
But BATMAN used to be real critical about only linking with other nodes running the same version of BATMAN-- any node running a different version was invisible to it. Since BATMAN is part of the kernel, getting all your nodes onto the same version means running similar kernels. I think there are some ways to override that now.
Aha! I will take appropriate measures and see what happens then.
It outputs nothing. However, radio0's LED is lit and it blinks every now and then. On the working batman nodes, radio0's LED blinks pretty constantly. And, provided there is at least one other node that is online and a member of the same mesh, iwinfo wlan0 assoclist has output that looks reasonable.
Even if only to eliminate the possibility of malfunctioning hardware, I need to set up at least one more 21.02 node. You can expect a report!
In your files you're using channel 100, a DFS channel. Mesh operation on DFS is an uncertain thing, since the mesh expects to be on a defined channel and if radar is detected there's no defined way to move the whole mesh to another channel. So I'd try a non DFS channel.
Good call, but yeah, I know about that. In fact I have written a cron job that detects when that has happened and reboots in order to revert to the correct channel. (I haven't successfully drunk the Freifunk kool-aid, but they offer a similar watchdog.) Radar interruptions happen to at least some nodes a couple of times per month, usually in the wee small hours. We're in a near-urban environment. Interestingly, local police radars interrupt channels 100 and 116, but not 132.
But for these tests I'm using channel 149 -- it's not a DFS channel.
I have another A7 coming in four days. Evidently my test bed needs to have four nodes lest one of them is ill-behaved, as I currently suspect, and interferes with the others. With only 3 test nodes, I can't tell which one is the culprit.
For the record, and so I can mark this topic "solved" (but see here for a remaining issue having to do with the specification of mac addresses within a mesh network), here are the /etc/config/network and /etc/config/wireless files that actually worked (modulo the mac address problem).
(This one is for the router that plays the "server" role in its mesh, which means that the mesh interface is in the LAN.)
I can no longer edit the previous solution, alas, so I'll just mention here that removing the "option macaddr" from the "config interface wlan0" stanza made a world of difference in both reliability and performance. Moreover, it is now no longer necessary to specify "option mtu '1312'" in the "config interface lan" and "config interface wan" stanzas, and "option mtu '1560'" can be specified in the "config interface 'wlan0'" stanzas (as recommended in a log warning before I did that). None of those things used to work. Now they work. I don't think I ever got reasonable performance from my mesh networks before, but they are performing well now.
So it is not a good idea to attempt to control the MAC address of a mesh interface. I didn't know that. I've updated that discussion here.