WIFI Mesh Probleme im 2015.2 Gluon ? // bzw. 2016.1

[aka47]

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