# WIFI Mesh Probleme im 2015.2 Gluon ? // bzw. 2016.1 **URL:** \ **Category:** Gluon\ **Created:** [20. Dezember 2015 um 17:05 UTC](https://forum.freifunk.net/t/wifi-mesh-probleme-im-2015-2-gluon-bzw-2016-1/9813 "2015-12-20T17:05:16Z")\ **Posts on this page:** 1\ **Showing post:** 14
**Author:** ![aka47](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@aka47](https://forum.freifunk.net/u/aka47)\ **Post date:** [22. Dezember 2015 um 14:15 UTC](https://forum.freifunk.net/t/wifi-mesh-probleme-im-2015-2-gluon-bzw-2016-1/9813/14 "2015-12-22T14:15:26Z")
Ich habe mich nochmal intensiv damit beschäftigt und einmal eine neue Firmware mit multicast rate 6000 verteilt. Halten wir fest: - Die mcast\_rate definiert ab wann (Mbits) ein Gerät an dem Mesh teilnehmen kann. **Dementsprechend niedrigere mcast\_rate sorgt also dafür das die Geräte auf weitere Entfernung meshen** was natürlich auf den Durchsatz geht. - Eine Firmware mit mcast\_rate = 6000 macht die selben Probleme - **Die TXpower ist auf 16dbm begrenzt** kann aber manuell aufgedreht werden nachdem der CountryCode geändert wurde - scheint also im Treiber zu liegen. uci set wireless.radio0.country=00 uci set wireless.radio0.txpower=20 uci commit wifi -\_\> iwinfo , Das bringt nur überhaupt nichts was das Problem betrifft - die TXQ ist GUT @Adorfer schrieb dazu ja schon: > [@adorfer](#): > > Für mich ist völlig unklar, ob es sich nur um einen Wechsel der Anzeige („Einpreisung von Gewinnen/Dämpfungen in den angezeigten Wert“) handelt. Oder ob wirklich weniger Energie aus der Antenne abgestrahlt wird. > > Die Frage wird man ehrlich nur mit passendem Meßequipment beantworten können. (Selbst den Umweg der Messung über die Leistungsaufnahme der Radios halte ich hier für nicht angesagt, da eben die Lowlevel-Treiber getauscht wurden und somit keine Vergleichbarkeit mehr besteht.) Vorher: 64 bytes from IPV6ADRESSE: seq=16 ttl=64 time=396.786 ms 64 bytes from IPV6ADRESSE: seq=18 ttl=64 time=64.148 ms 64 bytes from IPV6ADRESSE: seq=19 ttl=64 time=482.935 ms 64 bytes from IPV6ADRESSE: seq=23 ttl=64 time=361.135 ms 64 bytes from IPV6ADRESSE: seq=27 ttl=64 time=675.319 ms 64 bytes from IPV6ADRESSE: seq=28 ttl=64 time=571.968 ms 64 bytes from IPV6ADRESSE: seq=30 ttl=64 time=263.080 ms 64 bytes from IPV6ADRESSE: seq=31 ttl=64 time=703.538 ms 64 bytes from IPV6ADRESSE: seq=32 ttl=64 time=874.317 ms 64 bytes from IPV6ADRESSE: seq=36 ttl=64 time=881.661 ms 64 bytes from IPV6ADRESSE: seq=38 ttl=64 time=278.423 ms 64 bytes from IPV6ADRESSE: seq=41 ttl=64 time=1590.934 ms 64 bytes from IPV6ADRESSE: seq=46 ttl=64 time=1723.769 ms Nacher: 64 bytes from IPV6ADRESSE: seq=11 ttl=64 time=1459.227 ms 64 bytes from IPV6ADRESSE: seq=14 ttl=64 time=1022.920 ms 64 bytes from IPV6ADRESSE: seq=19 ttl=64 time=966.415 ms 64 bytes from IPV6ADRESSE: seq=20 ttl=64 time=1326.432 ms 64 bytes from IPV6ADRESSE: seq=23 ttl=64 time=1125.644 ms 64 bytes from IPV6ADRESSE: seq=24 ttl=64 time=1415.665 ms 64 bytes from IPV6ADRESSE: seq=26 ttl=64 time=1181.576 ms 64 bytes from IPV6ADRESSE: seq=27 ttl=64 time=678.684 ms 64 bytes from IPV6ADRESSE: seq=30 ttl=64 time=621.329 ms 64 bytes from IPV6ADRESSE: seq=34 ttl=64 time=190.493 ms 64 bytes from IPV6ADRESSE: seq=35 ttl=64 time=158.791 ms Ich bin also wieder am Anfang: > [@adorfer](#): > > Ich gehe davon aus, dass es sich nicht um ein „841v10“-Problem handelt, sondern um irgend etwas mit dem Wifistack von OpenWRT „Barrier-Breaker“ -\> „Chaos Calmer“. → So sieht es aus. Leider haben wir noch keine Vergleiche außer dernen die ich selbst gemacht habe. Kann jemand evtl ein paar Infos dazu liefern? > [@Freifunker](#): > > Ich habe leider noch keinen v10 in die Hände bekommen. Aber in unserem Netz meshen v10er mit 2015.2 Master mit Knoten die unsere aktuelle 2015.1.2 Stable laufen haben. Knoten haben auch Clients und wenn Traffic mäßig da nix durchgehen würde, hätte ich mit als erster davon erfahren. Wie gesagt. Traffic geht ja durch - allerdings kein Vergleich zu vorher - wie man auch an den Pings sieht… Ein Ping6 auf die NextNode läuft übrigens super - es MUSS am WIFI-Stack in Verbindung mit dem Mesh liegen. Ich würde jetzt in den nächsten Tagen nochmal den Test mit 802.11s machen wollen - auf welchem ja auch der Batman obendrauf sitzt um sicherzustellen das es nicht evtl am Batman selbst liegt - die syslogs sind aber so sauber…sauberer gehts nicht… #UPDATE: ich habe das ISSUE : WifiStack Problem in 2015.2? #605 eröffnet… → [Unstable ath9k WLAN · Issue #605 · freifunk-gluon/gluon · GitHub](https://github.com/freifunk-gluon/gluon/issues/605) --- _[View the full topic](https://forum.freifunk.net/t/wifi-mesh-probleme-im-2015-2-gluon-bzw-2016-1/9813)._