Nach der Feststellung, daß ich das Problem fälschlich bei hostapd suchte, habe ich mal alle ebtables*-Pakete rausgeworfen — bingo!
Genau das war’s; das Package hatten wir bislang nicht drin, war aber im übernommenen site.mk dabei — mit Gluon v2022 haben wir den FW-Bau umgestellt und nur unsere Pakete hinzugefügt: Schade Schokolade.
Hintergrund: prefix4 haben wir schon länger nicht mehr drin, da next_node.ip4 bei (unseren) Builds irgendwie unsinnig ist: die IP ist je Mesh („Domain“) unterschiedlich, kann sich somit eh’ keiner merken. prefix6 ist bei uns ein ULA-/64 – und die next_node.ip6 war auch von Client ansprechbar, Public-IPv6 – der Prefix (/64 aus verschiedenen 2001:bf7-/44 je Mesh) samt Gateway kommt per RA von den GWs – halt nicht.
Ich entsinne mich dunkel, die Doku zum Paket mal gelesen und es für uns als untauglich angesehen zu haben; aber mit der Änderung haben wir es uns nun eingetreten: shit happens.
Wünschenswert wäre, daß – wie bei vielen anderen Paketen – eine Überprüfung stattfindet; hier: ob prefix4 gesetzt ist und mehr als ULA-Adressen in prefix6 bzw. extra_prefixes6 definiert sind, wenn ebtables-source-filter eingebunden wird. Weil, für Sie getestet, so ist’s kacke. Hrmpft.