Fortsetzung der Diskussion von Großveranstaltung – 6000 Gäste:
Ich habe kurz gegoogelt und zum 2xx Limit nichts gefunden. Lohnt es folgende Test zu machen?
Batman-DOmain — Knoten A → client LANA → client LANB → Knoten B → lokales Mesh – Laptop.
Am Knoten B sollten dann alle Knoten der Domain zu zu sehen sein, und passende Einträge im batman des Laptop erzeugen. Auf die Weise sollte man also leicht über 2xx Geräte am Interface des Knoten B kommen. Oder?
ich habe das limit von 2xx user pro router im hinterkopf finde aber nix dazu …
Da muss irgendwie ein Limit in den Batman - Tabellen bzw dessen Routinggraphen sein.
Mag aber sein, dass die Limits Batman15 angehoben wurden.
ich habe ehh nur BAT 2014
Es gibt diverse DHCP-DoS-Scripte, die sich dutzende IPs holen (REQ/ACK).
Das müsste man aufbohren dahingehend, dann auch Alias-IPs (oder einen vswitch mit entsprechenden vielen Interfaces dahinter, ggf. eien Kombination daraus) zu bauen.
Und dann zu schauen, ob diese auch Dienste nutzen können. Einzelne Pings mit großem Abstand sollte eigentlich völlig reichen.
Das wäre doch mal ein Projekt für eine Nachwuchshackperson!
ich kann das auch in echt betrieb testen … 
Ach ja, ich erinnere mich da an „Todessterne“… mit echten Clients.
Ich wäre an realen Messwerte interessiert.
Vieleicht hilft es ja, ggf. ein SNAT dazwischen zu setzen… (ja, unschön, ich weiss.)
siehste alles kommt wieder
nur dieses mal habe ich ein noch besseres Opfer gefunden …
kea liefert ein „performance“ Tool mit. Das wäre schon ein schöner Startpunkt. Scheint mir aber OFF TOPIC. Oder? Gehört in die Sammlung „1001 Ways to DOS Freifunk“. DDOS ist hier nicht nötig.
obacht, nicht batman-adv Version mit batman-adv Compatversion verwechseln!
du meinst vermutlich compatlvl 14, denn alle Versionen ab 2014 hatten compatlvl 15
Hat jemand eine Lösung für die Eingangsfrage gefunden?
Denn die Antwort „es unterscheidet sich bei Batman IV/compat 14, Batman IV/compat 15 und BatmanV“ hilft leider nur begrenzt.
Der Doku auf
entnehme ich folgenden Satz, bei dem mir aber gefühlt Variablen für die Rechnung fehlen.
Too many local clients: The size of the local translation table depends on the number served clients. This size cannot exceed the maximum fragmented packet size and if the limit is reached, new clients are ignored. This is a virtual value given by the smallest MTU among all the hard-interfaces in use multiplied by the maximum number of allowed fragments (default to 16). This means that at compile time the user could potentially increase the number of fragments a node can send, thus increasing the local translation table maximum size.
Hallo Ingrid,
was ich bis jetzt verstanden habe (oder das zumindest glaube):
Der batman-Knoten mit den Clients announced das über seine TranslationTable (TL).
Diese Tabelle muss in 16 ethernet-frames passen, deren Grösse über die MTU auf dem Batman-adv-Interface bestimmt wird (afaik 1500 bei Gluon und Supernodes).
Ein Client braucht 32Bytes.
d.h. das Limit liegt bei 720Clients pro Knoten, evtl. etwas weniger, wenn da noch Präabel und anderer Overhead drauf kommt.
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
Die Frage bezieht sich zumindest für mich auf die Anzahl der Clients am LAN-Port eines batman-knotens. WLAN ist zumindest für mich kein Thema an dieser Stelle.