ich möchte in meiner Wolke unnötige Meshverbindungen vermeiden.
Hierzu habe ich der Datei /etc/config/wireless unter dem Abschnitt config wifi-iface ‚ibss_radio1‘ die Option option maclist ‚c4:e9:84:be:23:74‘ hinzugefügt und das Wifi mit dem Befehl wifi neugestartet. Der gewünschte Erfolg, nämlich die Verbindung zwischen Offloader und CPE2 via WLAN zu verhindern, blieb aus.
Mal versucht mit allow umzudrehen, um zu schauen ob whitelisting funktioniert? Hilft Dir dann für Deine Anwendung vielleicht nicht weiter aber zeigt ob wir es grundsätzlich richtig verstanden haben.
Alternativ noch auf der CPE versuchen - sie sollte dann ja garnicht erst aufbauen, das dürfte noch effizienter sein. Vielleicht gibt es ja einen Bug auf Dualbandgeräten…
Habe ich nun auch mal getestet, klappt auch leider nicht.
Auch hier leider Fehlanzeige. Sowohl mittels allow als auch mit der deny Option. Kann es sein, dass sich IBSS AdHoc Verbindungen nicht Macfiltern lassen?
Also in Düsseldorf machen wir das mit Vlans Auf dem Wifi IBSS Interface ist immer ein Vlan, so kann man einfach die Vlan ID ändern wenn die Geräte sich nicht via Batman vermaschen sollen.
So nach einigem probieren bleibt nun die Antwort:
Es ist nicht möglich mit IBSS Verbindungen mit dem MAC Filter zu verhindern.
Diese Funktion wird nur von 802.11s unterstützt und muss dann mittels iw dev $MESH_IFACE station set $HW_ADDR plink_action [open|block] gesetzt werden.
ebtables sollte ebenfalls funktionieren, dort hätte man dann den Vorteil tatsächlich einzelne Verbindungen kappen zu können, oder?
Allerdings sparen vermutlich weder vlan noch ebtables airtime tippe ich.
Ebtables funktioniert nur mit einer Bridge, d.h. man müsste das Wifi Interface in eine Bridge setzen.
Es gibt aber noch das Iptables mac module, evtl geht es damit auch
Hm ich meine mal gelesen zu haben das mcast_rate die minimale Geschwindigkeit angibt mit der die Geräte verbinden können, hab das aber in den Dokus nicht gefunden.
basic_rate / supported_rates sind allerdings dokumentiert und explizit für den adhoc-mode angegeben. Das trifft dann wieder alle Verbindungen und nicht nur einzelne und hat auch mit Macfilter nichts zu tun, sollte dann aber airtime sparen.
Damit könnte man dann zumindest ungeliebte schwache Verbindungen los werden, hilft aber nicht gegen ungeliebte starke.
Meines Wissens ist das falsch und die mcast_rate betrifft nur die Meshing-Verbindungen.
Siehe dazu auch die diversen Diskussionen in github issues beim gluon repository.
Hm, was genau ist denn falsch? Wir haben es ja schließlich nur von den Mesh-Verbindungen (s. Betreff).
Meinst Du Unterschied zwischen Luftnutzung und Verbindung am Batman?
Die „diversen Diskussionen“ habe ich nicht gefunden unter Issues · freifunk-gluon/gluon · GitHub - welche meinst Du?
in deinem letzten Post sprachst du nur von „Geräten“, daher wollte ich nochmal präzisieren, dass es eben Clients nicht betrifft.
Die Diskussion war zu Pull Requests zum Thema basic_rate/supported_rates.