Unnötige Mesh-Verbindungen mit MAC-Filter verhindern

Lösung: Unnötige Mesh-Verbindungen mit MAC-Filter verhindern - #10 von anon68922371

Moin Freifunker,

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.

Wo ist der Fehler?

Danke für eure Hilfe.

Gruß
Tarnatos

1 „Gefällt mir“

ibbs_radio1 klingt nach dem zweiten radio, 5Ghz. Funktioniert das Ganze bei ibss_radio0 besser? macfilter deny gesetzt?

Ne beim WDR4900 ist bei mir 0 5GHz.

Deny hab ich gesetzt, aber das ist ja eigentliche nur für 11s. Wir nutzen IBSS.

[Quote] cat /etc/config/wireless

config wifi-device ‚radio0‘
option type ‚mac80211‘
option hwmode ‚11a‘
option path ‚ffe09000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0‘
option htmode ‚HT20‘
option channel ‚44‘
option country ‚DE‘
option txpower ‚20‘

config wifi-device ‚radio1‘
option type ‚mac80211‘
option hwmode ‚11g‘
option path ‚ffe0a000.pcie/pci0001:02/0001:02:00.0/0001:03:00.0‘
option htmode ‚HT20‘
option channel ‚5‘
option country ‚DE‘
option txpower ‚20‘

config wifi-iface ‚client_radio0‘
option ifname ‚client0‘
option network ‚client‘
option disabled ‚0‘
option device ‚radio0‘
option mode ‚ap‘
option macaddr ‚66:68:b4:de:ed:33‘
option ssid ‚nord.freifunk.net

config wifi-iface ‚client_radio1‘
option ifname ‚client1‘
option network ‚client‘
option device ‚radio1‘
option mode ‚ap‘
option macaddr ‚66:68:b5:de:ed:33‘
option ssid ‚nord.freifunk.net
option disabled ‚0‘

config wifi-iface ‚ibss_radio0‘
option ifname ‚ibss0‘
option network ‚ibss_radio0‘
option device ‚radio0‘
option bssid ‚5c:c0:ac:00:d1:4c‘
option mcast_rate ‚12000‘
option mode ‚adhoc‘
option macaddr ‚66:69:b4:de:ed:33‘
option ssid ‚5c:c0:ac:00:d1:4c‘
option disabled ‚0‘

config wifi-iface ‚ibss_radio1‘
option ifname ‚ibss1‘
option network ‚ibss_radio1‘
option device ‚radio1‘
option bssid ‚5c:c0:ac:00:d1:4c‘
option mcast_rate ‚12000‘
option mode ‚adhoc‘
option macaddr ‚66:69:b5:de:ed:33‘
option ssid ‚5c:c0:ac:00:d1:4c‘
option disabled ‚0‘
option macfilter ‚deny‘
option maclist ‚c4:e9:84:be:23:74‘[/Quote]

Testweise nun auch bei Radio0 reingeschrieben. Kein Erfolg.

Obligatorische Sinnfrage: Warum willst du das tun?

Ist eh Shared Medium.

https://www.lede-project.org/docs/uci_wireless.html beschreibt es im Bereich „common options“ - sollte also eigentlich bei allen Modi tun.

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 :slight_smile: 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.

1 „Gefällt mir“

Gibts da Doku zu?

202020

Kannst halt hier in die site.conf von uns schauen:

https://github.com/ffddorf/site-ddorf/blob/master/site.conf

Ist ja fetzig.

Erfordert das noch Änderungen am Server Backend?

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.

Siehe: HOWTO · o11s/open80211s Wiki · GitHub

Eine gute Alternative stellt da die von @CyrusFox vorgeschlagene VLAN Varriante dar.

Erfordert das noch Änderungen am Server Backend?

Nein das ist pur auf der Wifi Seite von den Nodes :slight_smile:

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 :slight_smile:

Das war eigentlich der Gedanke dahinter.

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.

Das ist korrekt. Mcastrate bestimmt die minimale Verbindungsgeschwindigkeit.

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.