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

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

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?

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.

@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:

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

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 Likes

Danke für die aufreibende Analyse!

Ich denke, da hat ChaosCalmer ein echtes Problem.

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

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

Na logo.

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

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

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 Like

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

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.

Status ist: Reproduzierbar im ibss mesh - 802.11s scheint zu laufen.

ich habe einen kompletten rebuild der firmware durchgeführt und es ist weiterhin in der Konstellation nachvollziehbar.

Hat niemand mehr als 2 Mesh Partner auf 841v10?

Bitte bei Gelegenheit den Tippfehler im Betreff korrigieren :wink:

hab ich doch mal schnell erledigt :smiley:

1 Like

Die Probleme liegen scheinbar an der Site. Genauer gesagt am FastD vpn der sporadisch einfach mal sehr viele pakete wegwirft. Nachdem ich die Wege der Pakete verfolgt habe schein es sich zu verfestigen das diese (warum auch immer) über vpn geroutet wurden.
Wieso das Fehlerbild auch mit Firmware anderer Communitys ähnlich war kann ich nichtmehr nachvollziehen - evtl war einfach nicht genug Airtime vorhanden oder andere Störer zu der Zeit welche das Bild beeinträchtigt haben?! Ich muss also meine Aussage bezüglich identischem Fehlerbild unabhängig von der Community zurücknehmen,
Das Fehlerbild schein also ein Zufall zu sein und ist wohl nicht aussagekräftig.
Der Fehler von mir in der Analyse ist definitiv das beider Router jeweils AUCH VPN uplink hatten…

Ich werde nun erstmal abwarten bis die Arbeiten an den Supernodes abgeschlossen sind um die Probleme dahingehend zu lösen und analysiere dann weiter

p.S. es gibt einen quick and dirty txpowerfix in meinem git der das problem welches @Delta ja auch festfestellt hat behebt - der ist nicht schön aber funktioniert als gluon modul bis das Problem gelöst wurde sehr gut

Problem ist gelöst. Siehe git.
Backport der 802.11 löst die Probleme in dieser speziellen Konstellation.
Lag wohl wirklich an den verschiedenen ath9k chipsätzen in der Mischung des Mesh

2 Likes

Hier sei noch kurz darauf hingewiesen das die TXpower nicht über 17 gesetzt werden DARF weil sonst das wlan nichtmehr hoch kommt nach einem Reboot

Und die Ländereinstellung 00 kann auch keinen Kanal 13.