Gluon >= v2021 — kein Mesh auf DFS-Kanälen

Technik Gluon
1

Moin,

für’s Setup sei auf die Grafik verwiesen. »Node X« eine AVM FRITZ!Box 4040 (19.07-SNAPSHOT / Gluon v2021.1.x), »Node A« ein GL.iNet GL-MT1300 (22.03-SNAPSHOT / Gluon v2022.1.x).

Aus $Gründen möchte ich mit VHT-20, VHT-40, VHT-80 rumspielen, und daher wollte ich auf Frequenzen jenseits UNII-1 zurückgreifen — sprich auf DFS-pflichtige Känäle. Allein, weder auf Kanal 104 (UNII-2 Extended) noch auf Kanal 52 (UNII-2) kommt ein Link zustande:

root@33332-MT7615E-v2022-cd9d:~# iwinfo client1 info
client1   ESSID: "bielefeld.freifunk.net"
          Access Point: BE:79:5B:EB:6D:4C
          Mode: Master  Channel: 100 (5.500 GHz)  HT Mode: HT40
          Center Channel 1: 102 2: unknown
          Tx-Power: 23 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -87 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1
root@33332-MT7615E-v2022-cd9d:~# iwinfo mesh1 info
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: BE:79:5B:EB:6D:4D
          Mode: Mesh Point  Channel: unknown (unknown)  HT Mode: NOHT
          Center Channel 1: unknown 2: unknown
          Tx-Power: 23 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -87 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: 14C3:7615 7615:14C3 [MediaTek MT7615E]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

root@33332-4040-v2021-c3a7:~# iwinfo client1 info
client1   ESSID: "FF_OFFLINE_33332-40...021-c3a7"
          Access Point: 6E:AA:42:F2:B8:64
          Mode: Master  Channel: 100 (5.500 GHz)
          Tx-Power: 26 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -103 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy1
root@33332-4040-v2021-c3a7:~# iwinfo mesh1 info
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 6E:AA:42:F2:B8:65
          Mode: Mesh Point  Channel: unknown (unknown)
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -103 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy1

Hmm?

EDIT: augenscheinlich eine Regression aus OpenWrt 21.02.3. Auch als OpenWrt-Issue existent, unresolved seit 28.02.2023. Lovin’ it … (Gäbe es doch nur einen Gluon- unter den OpenWrt-Entwicklern. Oh, wait …)

So I’ve now updated both the R7800 and the AVM3000 to the latest 22.03 snapshot and things have started to deteriorate even more. With the AVM on 22.03, the mesh doesn’t even work with option country 'US' anymore. At least not reliably. Every once in a while when poking various parameters, everything would start to work miraculously, until the next boot. Maybe I should have a look at the mainline ath10k firmware again?

Anyway, on the R7800, iw dev if-mesh mesh_param dump has stopped working, it just lists the help text instead. Getting and setting individual parameters (e.g. iw dev if-mesh get mesh_param mesh_ttl) works fine however.

Meh!

1 „Gefällt mir“
2

(Gäbe es doch nur einen Gluon- unter den OpenWrt-Entwicklern. Oh, wait …)

Guten Morgen @wusel.
Deinen Frust kann ich gut verstehen, persönliche Spitzen kannst du dir meiner Meinung nach allerdings besser sparen.
Das steigert (entgegen deinem Interesse) nicht die Hilfsbereitschaft der Leute die du hier niedermachst, es wirkt auch so, als ob dir ein wenig Wertschätzung für die Arbeit der entsprechenden Entwickler fehlt.

Wie gesagt, versteh’ ich, dass es nervig ist, dass dein Problem noch niemand für dich gelöst hat;
aber guck doch mal, ob du deinen Frust in Zukunft auf die Bugs kanalisieren kannst, statt auf die Leute, die schon echt viel Zeit in das Projekt stecken,

Davon ab die dringende Empfehlung an alle lesenden: OpenWrt und Gluon-Entwicklung ist kein Hexenwerk, wenn auch Umfangreich und macht meistens beides zufriedener als ziellos im Forum rumzubollern.

2 „Gefällt mir“
3

Du verkennst die Situation. Es ist nicht »mein« Problem. Als sarkastischer, weitgehend schmerzbefreiter Pragmatiker setze ich einfach Hardware auf die Einkaufsliste, deren proprietäre Firmware solche Probleme nicht hat, packe da einen ollen Thin-Client mit Gluon x86 davor und mein Freifunk tut einfach, was die Nutzer erwarten. Das ist nicht zwingend das, was ich bauen möchte, aber das, was ich ggf. mangels offener Alternativen bauen muß.

Solange es operativ ein Risiko ist, sich auf ein neues Gluon-Release einzulassen, solange wird das Upgrade-Geschehen zäh bleiben. Und das ist dann nicht mein, sondern ein Problem für Gluon per se — siehe Gluon v2017, siehe CVE-2022-24884, …

Ich denke, das ist für jeden und jede nachvollziehbar. Und das ist auch kein »niedermachen«, das ist eine schlichte Beschreibung der Realität.

Die meisten von uns verbraten hier ihre Freizeit, und dann ist es schon arg ernüchternd, bei der Suche nach dem Problem festzustellen, daß es, teils jahrelang, bekannt ist und augenscheinlich ignoriert wurde. Wenn seitens OpenWrt kein Meshing auf DFS-Kanälen mehr unterstützt werden soll, kann man das ja wenigstens verlautbaren, anstatt die Nutzer einfach so im Regen stehen – und zeitfressend im Nebel stochern – zu lassen. Und Gluon-Developer, die auch bei OpenWrt aktiv sind, könnten und sollten solche Themen dann für die Gluon-Nutzer klären und kommunizieren, wenn sie dies nicht für Gluon wieder funktionsfähig patchen wollen oder können.

»Nimm das, Bug!« — tried, didn’t really work out. Genausowenig wie Entwickler, lassen sich Bugs von meinem Zetern erweichen, sich in ein Logikwölkchen aufzulösen. Ja, ich versteh’s auch nicht.

Ich bin ein schlichtes Gemüt. Ich kann mit diff & patch umgehen, C und einigen anderen Kram lesen und nötigenfalls auch ändern. Git … ist nicht meins. Ich verstehe Sourcecode im Dateisystem, aber diese Wirrtualisierung mit branches und whatnot — definitiv nicht KISS.

$Früher habe ich Gluon geforkt, den Tag ausgecheckt, .git entsorgt und die Dateien als my-gluon-v20xx-Repo in github deponiert, meine Änderungen gemacht und daraus Images produziert. Vielleicht nicht schön, aber funktioniert 1A — hinterläßt nur recht viel redundanten Datenmüll, aber irgendwas ist ja immer.

Heute bin ich dabei, Patches gegen Gluon zu bauen, die ggf. in Gluons OpenWrt-Kopie vor dem Bau Patches z. B. gegen den Kernel unterbringen (oder gegen Teile eines anderen Kernels, was ich cool und scary zugleich finde) — die dann wiederum OpenWrts-Build-System korrekt anwendet. Ehrlich gesagt: ›OpenWrt und Gluon-Entwicklung‹ ist Hexenwerk aus meiner Warte; ich ziehe durchaus den Hut vor denen, die durchblicken, wie die Zahnräder ineinandergreifen. Respekt, ernstgemeint.

»Technik: Gluon« im Freifunk-Forum ist nicht ziellos, sondern erreicht hoffentlich (⇒ Ziel) andere ›Techniker‹, die hoffentlich Aussagen zum Erlebten machen können. Zudem gibt es den Gluon-Entwicklern die Chance für Feedback, mit welchen Problemen ihre Nutzer sich konfrontiert sehen.

1 „Gefällt mir“
4

@Aiyion.Prime wird sich ausschließlich hierauf bezogen haben:

(Gäbe es doch nur einen Gluon- unter den OpenWrt-Entwicklern. Oh, wait …)

Der Satz implizierst, dass diejenigen im Gluon-Projekt untätig geblieben wären.
Spar dir das bitte in Zukunft :slight_smile:

Ich geb dir recht, dass sich das durchaus als Known-Issue für einen Release eignen würde. Mir war es bis zu deinem Thread jedenfalls nicht als Issue bekannt. Dank dir hab ich das jetzt auf dem Schirm.

Schade, dass du dich git verweigerst. Es ist wesentlich angenehmer als SVN und funktioniert super. Man muss sich nur mal die Zeit nehmen und es wollen.
Rebase, Cherry-pick, Branches sind genial.
Wenn viele an einem Projekt arbeiten geht es kaum noch ohne soetwas.
Dass es für ein Projekt für 1-2 Personen auch ohne gehen kann, ist klar.

Heute bin ich dabei, Patches gegen Gluon zu bauen, die ggf. in Gluons OpenWrt-Kopie vor dem Bau Patches z. B. gegen den Kernel unterbringen

Dass du das nicht schön findest, kann ich verstehen. Hadere selber durchaus damit. Liegt aber nicht an git.

5

Der Satz wirft die Frage auf, warum Gluon-Entwickler, die OpenWrt-Kommunikationskanäle typischerweise verfolgen, das Thema augenscheinlich ignoriert haben, ja. So ist Gluon – durch OpenWrt – limitiert auf einen jämmerlichen 80-MHz-Kanal/2 40-MHz-Kanäle für’s Meshing, und zwar in der schon oft recht überfüllten unteren Hälfte von UNII-1. Das ist schade.

Aber es gibt doch sogar Github-Issues dazu? Ja, FLOSS == »you have the code to fix it«, schon richtig. Aber ich ging bislang davon aus, daß Github-Issues auch hinreichend zeitnah durch OpenWrt-Entwickler gesichtet und gewichtet werden (inkl. Statement im Issue)?

Ich habe dafür keine Verwendung, ich bin Serverschabe, kein Entwickler. Ich mag es einfach und übersichtlich, git hat in etwa die gleiche Relevanz für mich wie zip: ich muß damit – anders als z. B. mit tar – ab und an umgehen, also muß ich nur wissen, welche Frage ich der allwissenden Müllhalde stellen muß.

Nö, DAS kann man auch mit wget -O - $URL | tar -zxf - bauen — aber es geht hier auch eigentlich um »kein Mesh auf DFS-Kanälen«, nicht um git …

1 „Gefällt mir“
6

Tja. Ich hab’ nun ath9k-Commits durchsucht, Knoten down-- und upgegraded, die allwissende Müllhalde rauf und runter befragt — aber wodurch 802.11s auf DFS-Kanälen schon in 19.07-SNAPSHOT, r11430 unnötigerweise kaputt gemacht wurde, habe ich nicht gefunden. Naja, ist ja auch egal.

Es bedeutet allerdings, daß 802.11s in OpenWrt/Gluon mit 5 GHz nicht mehr sinnvoll nutzbar ist — es sind nur noch ein popeliger 80- bzw. zwei 40-MHz-Kanäle für’s Mesh nutzbar im gesamten 5-GHz-Band. Und dies im UNII-1-Bereich, welcher mittlerweile ähnlich überlaufen ist wie das 2,4-GHz-Band.

Da der AP-Modus weiterhin auch auf DFS-Kanälen funktioniert, ist der logische Schritt, auf diesen auszuweichen – entweder mit WPS oder OpenWrts 4-Adressen-Modus –, um über 5 GHz einen breitbandigen, leistungsfähigen Backbone zu realisieren. Hat daran noch jemand Interesse? Damit wären dann auch Tri-Band-Geräte praktisch einsetzbar, mit OpenWrt-802.11s ja leider nicht.

7

warum Gluon-Entwickler, die OpenWrt-Kommunikationskanäle typischerweise verfolgen

Hast du eine Idee, wieviele Issues und Foren Threads da ständig geöffnet werden? Ich kann mir gut vorstellen, dass die Gluon-Entwickler aus diesem Grund diese Kanäle gar nicht so aktiv verfolgen (in anderen Worten: meiden) und eher indirekt oder über IRC von manchem erfahren, oder wenn sich Nutzer im Gluon Github issue tracker melden.
Sonst würde ihnen neben Ihrer Arbeit völlig die Zeit fehlen, an Gluon weiterzuentwickeln. Davon ab ist es nicht jedermanns Sache, weil es ziemlich Nerven rauben kann, die Kanäle aktiv zu verfolgen und diverse Nutzer da mit selbstgemachten Problemen auftauchen.

Davon ab gibt es zu viele Kanäle:
Gluon Issue tracker, irc Kanäle, Foren, mindestens 4 Github issue tracker für openwrt, packages und die wlan Treiber, und die Mailinglisten

Aber ich ging bislang davon aus, daß Github-Issues auch hinreichend zeitnah durch OpenWrt-Entwickler gesichtet und gewichtet werden (inkl. Statement im Issue)?

Du lebst in einer Idealwelt. Es gibt genügend Github issues, auf die in Wochen von keinem der Maintainer geantwortet wird (es gibt ein paar Freiwillige und Entwickler aus der Community, die ab und zu issues sichten/bei Problemen helfen). Und es gibt einen backlog an issues, die behoben sind, aber lange Zeit niemand schließt.
Den Leuten fehlt die Zeit für Moderation und gute Dokumentation.
Das zeigen auch die fast 2000 offenen issues auf github sehr gut. (das sind nur die für openwrt selber, nicht die ganzen weiteren repos)
Wenn für open source Vollzeitentwickler und Maintainer eingestellt werden könnten (dank Spenden oder einer Stiftung), sähe das eventuell anders aus, aber es ist alles ein Hobby.

back to topic
Falls den Bug mit meshing in höheren Kanälen doch jemand mitbekommen haben sollte, wäre es aber imo auch nicht so schlimm, da die genannten Kanäle für Meshing und Gluon mehr oder weniger uninteressant sind.
In den dfs Kanälen kann man sich den Kanal nicht wirklich aussuchen und muss (aus)weichen, wenn ein Wetterradar oder so sendet. Gluon braucht einen festen Kanal fürs Meshnetz, dieser wird aktuell von der Community festgelegt.
Soll es da eine offizielle Möglichkeit geben Ersatzkanäle zu definieren (Feature Request): müsste man klären: Wie einigen sich die Geräte auf einen Wechsel zurück zur DFS Frequenz, damit Nodes nicht lange offline sind? (zero wait dfs ist zu neu und beherrschen zu wenige Router, als dass es gerade eine Option wäre)

Es gab früher diverse Clients (TVs, Handys), die die DFS Kanäle nicht beherrschten. (historisch)

40mhz breite Kanäle könnte ich noch verstehen, da jedes Gerät diese beherrscht. Das ist bei 80MHz und 160MHz nicht mehr der Fall. Wir in Aachen verwenden 20MHz, um möglichst hohe Reichweite beim Senden aber auch beim Empfangen (Clientseite) zu erreichen. Außerdem belasten wir damit weniger Airtime, gerade weil wir auf die Kanäle unter 52 angewiesen sind für ein stabiles Mesh-Netz.

Wer aufs 5GHz Mesh verzichtet, kann für Freifunk gerne auf 5GHz ein Clientnetz auf anderen Kanälen (ggf. mit anderer Bandbreite) ausstrahlen, so wie Gluon es auch im Outdoormode tut.
5GHz mit 20 MHz (ggf. 40MHz) reicht für die typische Bandbreite der meisten Anschlüsse bereits aus.
Es lohnt sich imo eher in Mesh-Hardware zu investieren mit 4x4 MIMO für höhere Bandbreite.

19.07-SNAPSHOT, r11430

Immerhin haben wir so einen Ansatz :slight_smile:
Da kann man dann mittels git weiter bisecten und Images aus alten Commits bauen, um den Commit zu finden, der die Regression verursacht hat. Eventuell steckt der Bug auch im Linuxkernel.

WPS oder OpenWrts 4-Adressen-Modus

Was meinst du hier? WPS ist für verschlüsselte WLANs.
Ein 4-Adressen-Modus sagt mir leider auch nichts.

Ich gehe davon aus, dass auch bei Tri-Band Geräten der Gluon-Default UNII-1-Kanäle sein werden. Das Clientnetz wird dann woanders ausgestrahlt durchs zweite 5GHz Radio.

Bitte immer im Hinterkopf behalten, dass ich nicht für die Gluon-Maintainer spreche. Das hier ist nur meine persönliche Aussage.

8

Deine Meinung. Aus meiner Sicht reduziert dies die Nutzbarkeit von OpenWrt als WLAN-Plattform auf praktisch Null, da nur noch 1x80/2x40/4x20-MHz-Kanäle im gesamten 5-GHz-Band nutzbar sind. Damit wird – grundlos, denn Mesh ist im DFS-Bereich mitnichten untersagt – das 5-GHz-Band zu einem zweiten Breitbandrauschbereich verdammt. Es bleiben also genauso wie im 2,4-GHz-Bereich nur noch 4 nutzbare Kanäle für OpenWrt-basierte Systeme — was für eine Verschwendung.

Nichts ist in Stein gemeißelt; Clients müssen den Kanalwechsel ebenfalls durchführen, genauso kann das in $Software eingebaut werden: »wenn Mesh nicht mehr da, Partner auf anderen Frequenzen suchen«.

Single-Channel-Mesh ist kacke. Klar, sieht geil auf der Karte aus, 10 Knoten hintereinander hängen zu haben — mehr als respondd geht da aber nicht mehr bei Halbierung des bei 20 MHz eh’ schon mauen Durchsatzes mit jedem Single-Channel-Hop. Ist halt eine Frage der Betrachtungsweise und des Ziels; wir möchten ein stabil-performantes Netz bauen, und gerade nicht ein maximal weitreichendes Netz, bei dem man gedrosselt im o2-Netz noch schneller unterwegs ist. Sowas haben wir – jung und unerfahren – 2015-2017 gebaut, und wie viele andere solcher Wackelnetze zum schlechten Leumund von Freifunk beigetragen.

Yepp, 640 KB RAM reichen auch für jeden PC und jede denkbare Anwendung. Darum haben Mobiltelefone heute 6+ GB und Laptops 16+ GB RAM, nicht wahr?

Mit 20 MHz durch ath9k heißt um die 20 MBit/sec (Halb-Duplex!) in iperf3 im gleichen Raum. 1 Mesh-Hop, und jedes ›Dorf-DSL‹ ist schneller.

Too many acronyms error. WDS war gemeint. Wobei man WDS gar nicht bräuchte, wenn man das Interface nach bat0 wirft?

Da Mesh jenseits UNII-1 in OpenWrt broken ist, wird das so sein. Unvorteilhaft bleibt es, und eine grundlose Bevormundung der Nutzer. Zudem kann sich an der Situation (Mesh muß auf anderen Kanal ziehen: wie?) auch nichts ändern, da es kein Mesh jenseits UNII-1 gibt, somit auch nichts diesbezüglich entwickelt werden kann: zementierter Stillstand. Cui bono?

9

Nichts ist in Stein gemeißelt; Clients müssen den Kanalwechsel ebenfalls durchführen, genauso kann das in $Software eingebaut werden: »wenn Mesh nicht mehr da, Partner auf anderen Frequenzen suchen«.

Keine Ahnung, wie sauber das funktioniert.
Eventuell müssen die DFS Events synchronisiert werden.
Beispiel: Router der VPN macht steht im Keller.
Router auf dem Dach wechselt die Frequenz, da DFS Event erkannt, findet aber den Router im Keller auf keiner der anderen Frequenzen, da dieser noch weiter auf der DFS Frequenz sendet, da er kein DFS-Event bemerkt hat, da die Wände so dick waren.
Router im Keller hat keinen Grund, nach anderen Knoten zu suchen, da er bereits mit dem Gateway verbunden ist. Der andere Router hat eventuell nur den Strom verloren.
Müsste er nach dem anderen Router Ausschau halten, der sich plötzlich verabschiedet hat, könnte er parallel kein Freifunk mehr auf dem Kanal senden. (nur auf 2.4GHz)

Ich geb dir Recht, dass es ein Bug ist, und er gefixt werden sollte. Aber aus Gluon-Sicht ist er eben kein Dealbreaker gewesen und eventuell einfach gar nicht aufgefallen.

Single-Channel-Mesh ist kacke. Klar, sieht geil auf der Karte aus, 10 Knoten hintereinander hängen zu haben — mehr als respondd geht da aber nicht mehr bei Halbierung des bei 20 MHz eh’ schon mauen Durchsatzes mit jedem Single-Channel-Hop. Ist halt eine Frage der Betrachtungsweise und des Ziels; wir möchten ein stabil-performantes Netz bauen, und gerade nicht ein maximal weitreichendes Netz, bei dem man gedrosselt im o2-Netz noch schneller unterwegs ist. Sowas haben wir – jung und unerfahren – 2015-2017 gebaut, und wie viele andere solcher Wackelnetze zum schlechten Leumund von Freifunk beigetragen.

Hilfreich, danke für die Sichtweise. Ist was dran

Mit 20 MHz durch ath9k heißt um die 20 MBit/sec (Halb-Duplex!) in iperf3 im gleichen Raum. 1 Mesh-Hop, und jedes ›Dorf-DSL‹ ist schneller.

Ok, ich hab nur wifi6 20MHz getestet, da reichte das :sweat_smile:
Ist aber auch 1024QAM usw.

und eine grundlose Bevormundung der Nutzer

Den Bug hat niemand absichtlich eingebaut haha

10

Nicht alles, was hinkt, ist ein Vergleich :wink: Ich komm’ mit 2,4 GHz kaum vom EG in den Keller, damit halte ich Dein Szenario selbst bei einer Wellblechbaracke aus den späten 40ern für unwahrscheinlich. Anyway, mangels Mesh (Adhoc tut bei ath9k in Gluon v2021.1.x auch nicht, JFTR) auf DFS-Kanälen wird mensch dies nie veri- oder falsifizieren können.

Ja, 802.11ax ist ggf. schöner, und ggf. habe ich mit ath9k im WDR-3600 v1 ja auch einfach nur richtig ins Klo gegriffen: auf 5 GHz sendet das Schätzchen max. mit 15 dBm, also 31 statt 200 mW. Selbst bei imho sehr optimistichen 4 dBm Antennengewinn wären nur 80 statt erlaubten 200 mW in UNII-1 drin (kein TPC notwendig). Somit ist auch die Verbindungsqualität eher … mau. *seufz*

Je länger ich mich mit 5 GHz in OpenWrt/Gluon beschäftige, desto mehr drängt sich der Wunsch auf, lieber »was mit Holz« zu machen …

Ist es denn ein Bug? Du schriebst selbst »wäre es aber imo auch nicht so schlimm, da die genannten Kanäle für Meshing und Gluon mehr oder weniger uninteressant sind« — wenn ich eine Funktion für überflüssig halte, ist deren Fehlen ja aus meiner Sicht heraus kein Bug. Und einen Nicht-Bug muß man auch nicht beheben.

That said, ein paar weitere Suchen brachten u. a. dies:

As mentioned on IRC, I’d rather like to see DFS support for 11s, which is being worked on in upstream hostapd (although I’m not up-to-date on the current status).

Allerdings liest sich [v8,00/16] mesh: enable DFS channels in mesh mode, als ob dieses seit Mai 2019 funktional existieren sollte? Und schon 2016 gab es Patches für hostapd für Mesh auf DFS-Kanälen — wo ist das denn auf dem Weg in OpenWrt/Gluon liegengeblieben? (Bzw. warum ging es vor 19.07.3 und vor 21.02.3, geht also in OpenWrt-Bugfix-Releases nun fast schon gewohnheitsmäßig kaputt, warum testet das niemand?)

11

Von der Patchserie wurden leider nicht alle aufgenommen, sieht man z.B. an dieser Ansicht:

https://patchwork.ozlabs.org/project/hostap/list/?state=*&series=62725

Jemand anderes hat das Thema Mesh+11s dann zwei Jahre später wieder aufgenommen:

https://patchwork.ozlabs.org/project/hostap/list/?state=*&series=186663

Aber auch hier wurden zwei Patches wieder nicht angenommen. Der eine Patch davon, „mesh: use deterministic channel on channel switch“, enthält auch eine Beschreibung, was das algorithmische Problem von 11s und DFS ist: Nämlich dass man sich bei einem DFS Event sehr wahrscheinlich statt eines zusammenhängenden Meshes dann eher viele kleine, voneinander getrennte Mesh-Inseln erzeugt, die sich jeweils auf einen anderen neuen Kanal geeinigt haben. Und der Patch wollte statt eines zufälligen, neuen Kanals dann eine bestimmte Kanalreihenfolge machen, um dieses Risiko zu reduzieren. Was sicherlich auch nicht wasserdicht ist, aber zumindest eine Verbesserung wäre.

Der Ansatz wurde aber trotzdem abgelehnt mit der Begründung, dass der WLAN Standard sagt, man solle einen zufälligen, neuen Kanal dann wählen…

Mir scheint’s einfach (noch?) keinen guten Ansatz zu geben, wie und auf welchen neuen Kanal sich so ein Mesh dann einigen soll. Wenn’s Ideen gibt, sollten wir die vll. mal in einem Pad oder sowas mal sammeln.

Und ich finde das ganze DFS + Mesh Thema auch mega nervig und frustrierend… Inbesondere weil wir Outdoor nun legal garkein 5GHz Mesh machen könnnen… in den USA sind zumindest die unteren 5GHz Kanäle ohne DFS auch outdoor nutzbar. Da wäre es vll. praktisch, mal mit der Bundesnetzagentur zu reden, warum das so ist. Und ob’s da nicht Möglichkeiten zur „Harmonisierung“ von FCC und ETSI gäbe.

3 „Gefällt mir“
12

OpenWrt, okay, screw it — Gluon kann doch OpenWrt nach eigenen Bedürfnissen patchen?

Naja, das wird durch das Hashing ja an sich gelöst — und IMHO ist der Einwand bzgl. „random“ irrelevant, ob ich nun eine „echte“ oder eine „errechnete“ Zufallszahl nehme, ist im Endeffekt egal: Ist der neue Kanal „frei“, ist’s gut, wenn nicht, dann … nicht. Und wieder: Gluon kann OpenWrt-Entscheidungen per Patch »überstimmen« — und sollte dies hinsichtlich des Einsatzzweckes auch dringend tun; daß 802.11s nur auf 4 5 GHZ-Kanälen funktioniert ist schlicht indiskutabel (zumal das ja mal besser war). IMHO, YMMV.

Bei APs klappt das ja auch; da finden die Clients ihren AP auf „zufälligen“ Kanälen wieder, weil sie Clients des einen APs sind. Im Mesh gibt’s nicht den Einen, der gleicher als alle ist — aber vielleicht braucht es das? Niedrigste MAC merken ⇒ Master. Wenn Verbindung verloren: Scan. Wenn Mastr-MAC nicht mehr da, ist der Master die niedrigste empfangene MAC? Über die Zeit müßten sich dann alle auf dem Kanal des neuen Masters einfinden?

Second that; daher sollten »wir« ggü. Frequenzanforderungen der Mobilfunker massiv laut werden. Die sollen erstmal mit ihrem üppigen Spektrum klarkommen, jetzt sind wir es, die als Primärnutzer zum Zug kommen müssen!

Von einer Behörde, die auch 2023 noch Herstellermonopole fördert – IMHO kartellrechtswidrig –, erwarte ich keine wie auch immer geartete Hilfe.

13

ja und nein. Um den Wartungsaufwand in Grenzen zu halten ist das Ziel, sich auf Patches zu beschränken die kurz- bis mittelfristig wieder entfernt werden können, weil sie in OpenWrt aufgenommen werden/wurden.

14

Vollkommen nachvollziehbar. Allerdings halte ich die Reduzierung auf 4 5-GHz-Kanäle für’s Meshing für eine Freifunk-Firmware für hinreichend einschränkend, daß Gluon hier Lösungen anbieten sollte. Oder wenigstens konsequent dafür sorgen, daß die Wahl von DFS-Kanälen in der site-/domain-Konfiguration zum Abbruch des Builds führt.

1 „Gefällt mir“