Komme eher auf 12 Bytes pro Client (MAC Adresse) hier: batadv_packet.h - include/uapi/linux/batadv_packet.h - Linux source code (v6.8.8) - Bootlin
Andererseits mit IPv6 und den batman-adv Multicast Optimierungen kommen da noch neben der Unicast MAC Adresse noch mindestens eine Multicast MAC Adresse hinzu. Bei mir auf dem Laptop sind’s mit den IPv6 Privacy Extensions und somit 3 sehr verschiedenen IPv6 Adressen (link-local, ULA, global) sowie mDNS gerade 4 Multicast MAC Adressen. So wäre ich bei 1500*16/((4+1)*12) bei ungefähr, überschlagen 400 Clients pro Knoten. BATMAN IV vs. BATMAN V sollte keinen Unterschied machen, die benutzen das gleiche Translation-Table Protokoll dadrunter. Nur compat14 vs. compat15 (bzw. altes vs. aktuelles batman-adv) sollte einen Unterschied machen.
Müsste aber vll. nochmal wer in der Praxis verifizieren, dieses Limit.
Ansonsten kommt’s denke ich auch auf den WLAN-AP selber an. Wenn man da was mit 802.11n hat, hat man da natürlich weniger Bandbreite als mit ax. Evtl. macht dass bei 11n dann mit 200 Clients schon wegen fehlender Bandbreite einfach keinen Spaß mehr.
Prinzipiell sollten aber die FQ-Codel und Airtime-Fairness Patches im Linux Kernel da schon eine Menge für aktuelle Gluon/OpenWrt Versionen geholfen haben. Also dass da nicht mehr ein schlecht verbundener Client alles ausbremsen kann. Bin mir nur nicht ganz sicher, ob die Airtime-Fairness neben ath9k, ath10k und mt76 auch bei ath11k Anwendung findet. Zumindest sehe ich hier spontan nur die ersten drei WLAN-Treiber: ieee80211_sta_register_airtime identifier - Linux source code (v6.8.8) - Bootlin