Mich würden technische Erfahrungen in anderen Communities interessieren.
1 „Gefällt mir“
Tja… ein Router mit zwei Radios wäre dazu ideal, gern auch zwei 2.4GHz-Radios.
Nur das sind meist total verrammelte Provider-Zwangsrouter, die darüber (das zweite Radio) den Masterplan verfolgen, ein „Public Wifi gegen $$$“ anzubieten und dafür gern freie Airtime hätten.
USB-Sticks sind abgesehen von der Problematik „kein AT9k“ und „keine ordentlichen Antennen“ schlicht unwirtschaftlich, weil man dann router nehmen muss, die das auch leisten. Effekt also 20€ mehr für den Router und nochmal 5-15€ für den Stick…
Also besser: 841N im Doppelpack „back to back“ herausstellen… evtl. sogar einen eigenen releasezweig dafür als FW backen, „stable-AP“ und „stable-MESH“ für diese Combo.
Du hast mich nicht verstanden. Dass es mit zwei Radios geht, ist klar. Ich meinte, ob man die HT40-Funktionalität nicht entsprechend nutzen kann um es auf zwei Kanäle zu ziehen.
Aber das soll hier nicht das Thema sein, es geht um HT20/HT40.
Grüße
Matthias
Tja, ein Radio ist leider ein Radio, unabhänig was der Treiber dann da veranstaltet mit den SSIDs…
geht zumindest mit AT9k nicht, unabhänige HT-Modes zu fahren für AP und Adhoc.
Ideal wäre es, wenn wir irgendeine Fuzzy-Logik entwickeln könnten in der der AP selbst ermittelt, ob HT40 in dem Szenario angebracht ist oder nicht und ggf. auch dynamisch wechselt.
(Ja, im AP-Modes klappt das heute schon, aber eben leider nicht für AdHoc.)
Meine Argumentation war ja, dass HT40 immer angebracht ist.
Das Clientnetz geht auf HT20, sobald auch nur ein weiterer Router in Reichweite ist. Das Mesh bleibt auf HT40 und somit fließen 50 % des Meshverkehrs über den freien, zweiten Kanal. Das war die Idee.
Zwei Netze, zwei Kanäle ist vom Ressourcenverbrauch in Ordnung, finde ich.
1 „Gefällt mir“
Die Erfahrung kann in der Praxis (noch) nicht nachvollziehen. Nach dem Wechsel auf Kanal 1 bei HT20 wurde alles besser - das kann allerdings genau so gut am Auszug aus der überfüllten Ruhrgebietsdomäne liegen.
Die Theorie kann ich nachvollziehen, ob das so in der Praxis funzt, kann ich mir noch nicht vorstellen.
Mein Auto hat über 200PS, ich finde ich sollte in der Stadt 100 fahren dürfen.
1 „Gefällt mir“
Ich halte es für regulatorisch sehr problematisch, da eine ähnlich Ignoranz (und Nutzung eines „Durchsetzungsdefizits“ seitens DDWRT) zu den jetzt bald greifenden FCC- und ITU/RED-Neuregulierungen hinsichtlich „signed firmware only“ geführt hat.
Ja, hat nichts mit HT20/40 zu tun. Nur damit, dass „Performance“ nicht die einzige Optimierungsrichtung sein darf. Das ist wie mit „5GHz outdoor nur mit DFS“. Man könnte es ignoreren. Da wir Freifunkenden aber durchaus von anderen Gruppen kritisch „betrachtet“ werden, könnte so etwas schnell zum Bummerang werden.
1 „Gefällt mir“
Ich finde, das sind zwei paar Schuhe, weil man da wirklich wichtige Dinge stört.
Ne, du sollst mit zwei Autos zweimal 50 fahren. So ist die Idee 
Ich glaube, dann seid ihr kein guter Vergleichskandidat. Dass größere Domänen eine schlechtere Meshqualität haben, ist klar.
Wenn ich das aufnehme dann schlägst du vor einmal 50 und einmal 100 zu fahren.
Apropros überfüllte Domäne: Da sind wir glaube ich im Club.
Im Kreis Gütersloh haben wir auch, mit dem Update auf Gluon 2015.1.2 (FW 0.7 in unserer Zählung), von 9+ auf 9 gewechselt, nachdem klar wurde, daß Ad-Hoc sich scheinbar nicht an die Belegungsregeln hält (AP sehr wohl). Und auch hier stellen sich negative Rückmeldungen ein („hakeliger“ Durchsatz grade in Verbindung mit Mesh-Knoten).
Da wir die WiFi-Treiber nicht angefaßt haben, werden wir wahrscheinlich in Kürze zu 9+ zurückkehren; es ist Aufgabe der Low-Level-Treiber, die Konformität zu gewährleisten, nicht unsere, per vorauseilendem Gehorsam uns selbst zu beschränken. (Unsere FW wird auch in WLAN-armen Regionen eingesetzt, wo vormals auch der AP-Modus auf HT40+ schaltete.)
1 „Gefällt mir“
In der Regio Aachen lief bis vor kurzem alles auf Kanal 9 HT40- .Ich bin sehr froh darüber, dass dies auf Kanal 9 HT20 geändert wurde, da ich massive negative Beeinflussungen der WLANs in meiner Nachbarschaft hatte. Denn gesamten Lösungsverlauf kann man hier nachlesen:
Und dem daraus entstandenen Thread:
Da wegen einem Bug im ad hoc Modus mit HT40 immer beide Kanäle benutzt werden, muss man sich klar sein, dass durch Freifunk auf mindestens zwei der vier überlappungsfreien Kanäle im 2,4Ghz Bereich permanent Daten gesenden werden. Ein störungsfreier Betrieb für ALLE anderen WLAN-Netze ist dann nur auf den verbleibenden beiden Kanälen möglich.
Gerade weil der Bug bekannt ist, dass HT40 immer verwendet wird, halte ich es für eine schlechte Idee, diese Funktion zu benutzen, solange das nicht gefixt ist.
Wir sind im WLAN nicht alleine und sollten mit Freifunk andere so wenig wie nötig stören. Wenn ich die Wahl habe ob Freifunk gut funktioniert oder die Nachbarschaftsbeeinflussung minimiert wird, wären mir meine Nachbarn wichtiger. Es kann ja nicht in unserem Interesse sein uns unbeliebt zu machen.
Also HT40 gerne wenn:
- nicht permanent Daten gesendet werden ( was wegen der Statusinformationen und dem Broadcasts nicht so ist)
- der Bug für die Kanalausbreitung gefixt ist und diese nur erfolgt, falls das tatsächlich benötigt wird.
Fälltest unbedingt jemand jetzt schon HT40 benutzen möchte, würde ich Kanal 9 mit HT40+ nehmen. Kanal 13 ist ja sowieso nicht so beliebt, weil er International nicht überall verwendet wird.
1 „Gefällt mir“
Sehr gute Argumente und schön ausführlich dargelegt, danke an @wusel und @Harald.
Was halt sehr frustrierend ist, ist, dass diese Meshfunktionalität, das was Freifunk eigentlich sein will, nicht mehr funktioniert, wenn es praktisch genutzt wird, nämlich durch mehr als vereinzelte Clients.
Was ich mich frage, wie hart ist denn die Nutzungsregel? Also im 5 GHz-Bereich hat es praktische Gründe, dass man das Wetterradar erkennen muss, und wenn man das nicht tut, passieren auch drastische Konsequenzen - richtig so.
Die Frage ist halt, wenn auch viele Routerhersteller, das nicht sauber implementieren, scheint es niemanden wirklich zu interessieren und es ist eher eine sei-nett-Regel.
Man könnte z.B. alternativ auch überlegen, ob man Gluon so strukturiert, dass das Mesh immer mindestens 50% der Sendezeit oder so bekommt. Das könnte auch einiges helfen. Insbesondere, wenn es einen Mechanismus gibt, der die Clients dann dazu bringt in der Zeit die Klappe zu halten.
Wenn ich das richtig im Kopf habe, können HT20-Router mit HT40-Routern meshen. Wäre es ein Ansatz, die Kanalbreite in den Erweiterten Optionen als editierbar zu hinterlegen? Wer Probleme hat, wie @Harald, kann so ohne Hackerei HT20 nutzen und wer weniger Störungen mit dem breiten Kanal hat, stellt sich HT40 ein.
1 „Gefällt mir“
Das wäre sehr interessant, wo kann man das eigentlich ändern, sodass es nach dem nächsten reboot übernommen wird?
HT20 und HT40 können miteinander meshen. Das hatten wir in Aachen ausprobiert, bevor der Wechsel auf HT20 erfolgte.
Über uci ist das wireless.radio0.htmode.
1 „Gefällt mir“
Hallo.
Vielleicht würde sich ja jemand auf ein kleines Experiment einlassen:
Wenn jemand mehrere benachbarte Knoten betreibt, die sich nun mit HT20 gegenseitig ständig auf die Füße treten, könnte man bei diesen mal temporär den RTS/CTS-Mechanismus aktivieren.
Per uci geht das mit
uci set wireless.radio0.rts=1
wifi
Ohne commit sind die Einstellungen beim nächsten Reboot wieder weg.
Der Wert 1 aktiviert RTS/CTS für jede Sendung, größere Werte nur für entsprechend größere Pakete.
Mich würde brennend interessieren, ob der Mechanismus in vollen Netzen wirklich etwas bringt, oder das Handshaking die Luft einfach weiter zustopft. Leider habe ich hier lokal (noch) kein Testfeld dafür, würde aber bei der geplanten FF-Ausstattung einer recht großen Erstaufnahmeunterkunft (>600 Leute) sehr hilfreich sein.
Gruß Christian
1 „Gefällt mir“
RTS ist aus?
Oder auf irgendeinem Default?
Dann sollten wir das echt mal ausprobieren, rtscts soll ja gerade bei Congestion hilfreich sein…