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

Technik Gluon
1

Hallo zusammen.
Ich jage mal wieder einen „Geist“ im aktuellen 2012.2 Gluon master.

Die Konstellation:

  • Mehrere 841v10 mit 2012.2 im WIFI Mesh
  • getestet mit selbst gebauter Firmware und experimental builds anderer Site (also nicht von mir)
  • getestet zusätzlich mit 1043v2
  • KEIN 802.11s!!
  • Immer nur einen Knoten mit VPN

Das Problem:

Sobald ich 2 Router mit 2012.2 im Mesh habe bricht mir das WIFI mesh soweit ein das kaum noch Pakete durchgehen.

Folgende Test wurden gemacht um das Problem einzugrenzen:

Eigene Firmware:
-2er Mesh mit 2012.1 auf 1043 und 2012.2 auf 841v10 → OK
-2er Mesh mit 2012.2 auf 841v10 → Problem tritt auf
-2er Mesh mit 2012.2 auf 1043er und 2012.2 auf 841v10 → Problem tritt auf
-2er Mesh mit 2012.2 auf 1043er → Problem tritt auf
-3er Mesh mit 2012.1 auf 1043 und 2012.2 auf ZWEI 841v10 → Problem tritt auf

Andere Firmware:
-2er Mesh mit 2012.1 auf 1043 und 2012.2 auf 841v10 → OK
-2er Mesh mit 2012.2 auf 841v10 → Problem tritt auf
-2er Mesh mit 2012.2 auf 1043er und 2012.2 auf 841v10 → Problem tritt auf
-2er Mesh mit 2012.2 auf 1043er → Problem tritt auf
-3er Mesh mit 2012.1 auf 1043 und 2012.2 auf ZWEI 841v10 → Problem tritt auf

Fazit: Identische Ergebnisse der Testfälle unabhängig der Hardware! Somit kann ich also den 841v10 als Fehlerquelle sowie auch meine gebackene Firmware ausschließen.
Ich habe sogar Testweise mal die WIFI Kanäle gewechselt was aber auch nichts gebracht hat

Geflasht wurde sicherheitshablber IMMER ein Factory Image mit TFTP Recovery um sicherzugehen das die Kisten komplett neu sind.

Bevor ich jetzt ein Issue im GIT aufmache möchte ich mal hören ob jemand ähnliche Probleme hat

3

Niemand??

Wo ist denn der Unterschied im Mesh bei BarrierBreaker und ChaosCalmer?
Die Batman Version ist doch die selbe…?

4

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.

5

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“.

6

Ich habe das selbe Problem bei 841v9 und 2015.2 festgestellt. Dachte zuerst es lag am Wechsel zu 802.11s , aber txpowerset war auf 16 gesunken.
Wie steht bei dir txpowerset ? Bei mir war es bri BB noch 19 oder 20, unter cc 16. da scheint noch was im Argen zu sein. Bei mir hat ein anheben auf 20 die Probleme gelöst.

7

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.)

8

Knoten die gemasht haben, haben es nach dem Upgrade nicht mehr. Es scheint also wirklich die sendeleistung geändert worden zu sein.

9

Meshen denn ach mehr als 2 in dieser konstellation bei euch?
Ich sagte ja: bei einem 2015.1 mit einem 2015.2 geht es ja noch. Ab 3 geht kaum noch was

10

Ja. Da ist definitiv was passiert. Meine cpe210 hat deutlich weniger reichweite. Die 1043 ebenfalls.

Du sagst country=00 und txpower auf 20 manuell setzen löst das problem bei dir?

11

a) Ich vermute, sie haben gemeshed, nicht gemashed.
b) dieser Schlussfolgerung stimme ich nur zu, wenn gleichzeitig zum Wechsel des HT-Modes auch die MCastRate auf 6000(?) reduziert worden wäre. Ich vermute jedoch, dass das vergessen wurde.

12

@Delta Mein Problem bezieht sich nicht auf eine geringe TQ… Die TQ der Mesh-Nodes ist über 200 - die stehen also direkt nebeneinander. Tx-Power: 16 dBm auf 841v10

@Adorfer

Woher nimmst du diese Info? ich habe ja im Mumble verzweifelt versucht infos über die mcast Rate zu bekommen und auch schon in diese Richtung überlegt… Sollte es wirklich daran liegen haben aber ALLE experimental Builds die ich getestet habe dieses Problem. - Ich werde mal eben neu bauen und den autoupdater laufen lassen… in einer Stunde weiss ich dann mehr… Wenn es klappt schick ich dir eine Kiste Bier :smiley:

13

Meine, die Stuttgarter haben auch schon was in die Richtung beobachtet. Ich harke mal da nach…

14

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:

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:

→ 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?

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

3 „Gefällt mir“
15

Danke für die aufreibende Analyse!

Ich denke, da hat ChaosCalmer ein echtes Problem.

16

Ich kann kein Problem feststellen. Ist zwar kein 841v10 beteiligt, aber Ubiquiti und TP-Links im Mix.

http://map.freifunk-uelzen.de/#!v:m;n:24a43cf85f1c

Alles so gut oder schlecht wie immer.

traceroute to 24:a4:3c:f8:5f:1c (26:a7:3d:f8:5f:1c), 50 hops max, 20 byte packets
1: de:ad:c0:1a:32:04 23.920 ms 29.289 ms 26.942 ms
2: de:ad:c0:1a:32:02 26.181 ms 24.720 ms 25.040 ms
3: 66:67:b3:e8:3a:1f 60.371 ms 76.453 ms 54.483 ms
4: 26:a7:3d:f8:5f:1c 66.602 ms 92.013 ms 64.805 ms
root@MA-WDR4300:~#

PING fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c(fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c) 56 data bytes
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=1 ttl=64 time=66.2 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=2 ttl=64 time=57.7 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=3 ttl=64 time=68.5 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=4 ttl=64 time=79.3 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=5 ttl=64 time=56.5 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=6 ttl=64 time=132 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=7 ttl=64 time=104 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=8 ttl=64 time=60.4 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=9 ttl=64 time=98.6 ms
64 bytes from fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c: icmp_seq=10 ttl=64 time=97.2 ms

— fd83:e002:c8a1:0:26a4:3cff:fef8:5f1c ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 56.523/82.229/132.856/23.982 ms

17

Danke für den Test!
kannst du mir deine firmware als sysupgrade zum Gegentest zur Verfügung stellen?

soweit ich weiss kann ich die unter /lib/gluon liegende site.conf dann bezüglich meiner vpns updaten

wär echt peinlich wenn es „nur“ ein Fehler von mir wäre bei dem ganzen debugge

18

Na logo.

http://firmware.freifunk-uelzen.de/experimental/

Und hier unsere Site: GitHub - FreifunkUE/site: Site Config Files von Freifunk Uelzen

19

Hmm… also die von euch läuft Problemlos - im 802.11s, im ibss und im dualbetrieb.
Ich werde nun nochmal komplett neu bauen (auf basis eurer site.conf). wenn es dann immernoch nicht läuft bleibt wohl nurnoch mal über ein anderes repo die pakete zu holen…evtl ist das repo verbacken welches wir alle benutzen…
… ich werde berichten…

1 „Gefällt mir“
20

Wir checken immer frisch den aktuellen Master aus. Bis auf den FFPB Filter haben wir nix zusätzliches in den Packages drinne.

21

Wie ist denn der Status bei dir? Wenn unsere Firmware problemlos läuft, würde ich dich bitten dein Issue zu schließen.
https://github.com/freifunk-gluon/gluon/issues/605

Denn so was hält eventuell die Entwickler nur auf, wenn sie „Geistern“ nach jagen.