TX powerloss [Gluon 2018.2 / 2018.2.1 (OpenWrt 18.06.x based)]

Bin wieder z.T. auf 2018.1.x zurück - hier lässt sich txpower (regdom DE!) wieder anheben.

2 „Gefällt mir“

Scheint/ist kein grundsätzliches Gluon sondern ein OpenWrt Problem.

Ein mit „plain“ OpenWrt 18.06.x betriebenes Gerät verhält sich identisch…
… plain OpenWrt 17.01.x dagegen hat den „powerloss“ nicht.

3 „Gefällt mir“

Kanal 13 ist in den USA nicht erlaubt. Wenn du einen anderen Kanal einstellst, der in USA erlaubt ist, sollte das funktionieren.

Funktioniert auch mit „00“, „BO“, … nicht

Dann ist wahrscheinlich Kanal 13 da auch nicht erlaubt.
Geht es mit DE?

Edit: Geht es mit Kanal 6 und US?

gibt es dazu im openwrt schon nen ticket?

Nein - bin noch nicht dazu gekommen da noch einigte Test ausstehen
Siehe auch => TX-Powerloss since 2018.2 - 2018.1.x was higher · Issue #1691 · freifunk-gluon/gluon · GitHub

man könnte auch das openwrt forum durchforsten, wenn es wirklich ein Problem gibt dieser Art, das nicht nur eine andere Anzeige von Werten ist, sondern in tatsächlich weniger dBm als erlaubt resultiert, dann dürfte das auch im Forum zu finden sein.
Ich tendiere eben aktuell entweder zu einer Änderung der angezeigten Werte, nicht der tatsächlichen - oder einer Änderung die zu besserer Einhaltung der erlaubten Werte führt - anstatt anzunehmen, dass es ein Bug ist. Das ist aber eine Vermutung und sollte bei OpenWrt upstream geklärt werden durch öffnen eines Bugreports und evtl. einen Forenthread dort.

(persönliches) Fazit

  • Mit der Umstellung von 2018.1.x (LEDE) auf 2018.2.x (OpenWRT) ist die WLAN Mesh TQ "schwächer" [in Einzelfällen ist es vorgekommen das Nodes "abgehängt, bzw. isoliert wurden]

  • das Phänomen ist auch bei purem, aktuellem OpenWRT nachstellbar

  • Es sind nicht alle Router Modelle betroffen (die zugegeben unvollständigen Listen der WiFI Chipsets)

    • betroffen: Qualcomm Atheros QCA9558, QCA9533, QCA9561)
    • NICHT betroffen: Atheros AR9280, Mediatek MT7628NN
  • soweit es meine Zeit zulässt werde ich mit (verminderter Priorität) weiter „forschen“ wobei es ja mit „back-2-2018.1x“ zunächst einen brauchbaren „Workaround“ gibt…

1 „Gefällt mir“

ebenfalls betroffen:
AR9381-AL1A
AR9580-AR1A
auf dem mpc85xx target

Wir können da wenig/nichts tun, wenn etwas voran gehen soll müsst ihr das auf englisch bei OpenWrt melden, es gibt dort folgende Kanäle:

  • Bugtracker
  • Mailingliste
  • IRC
  • Forum

und die ersten beiden werden von den Entwicklern am ehesten gelesen, im Forum erreicht man dort eher weniger Entwickler als User, vor allem aufgrund der großen Anzahl an Beiträgen jeden Tag die kaum einer alle lesen kann.

1 „Gefällt mir“

Sind denn 841er, Fritz 4020 oder 1043er betroffen?

ja

  • 841 (zumindest die V9)
  • 1043 (zumindest die V2)
  • zur FB 4020 kann ich nichts sagen

1043 v5 : betroffen.
4040 : nicht betroffen
ac-mesh: nicht betroffen

So weit ich das hier erkennen kann wurden alle Tests bisher auf den generell Problematischen Randkanälen durchgeführt. Diese sollten nicht verwendet werden, da auf diesen häufig die Sendeleistung reduziert wird, um unerwünschte Aussendungen außerhalb des zulässigen WLAN Frequenzbereichs zu unterdrücken. Dies ist häufig nicht an die Regdomain gekoppelt, sondern global im Treiber oder im Chipset verankert. Bitte wiederholt eure Tests auf einem Kanal (z.B. Kanal 6), der nicht von besonderen Einschränkungen für Randkanäle betroffen ist.

Darüber hinaus ist zu beachten, dass Änderungen an der Regdomain bei Atheros Chipsets eventuell nicht immer den gewünschten (oder überhaupt irgendeinen Effekt) haben, da diese Chipsets über hart einprogrammierte Regdomains verfügen. Siehe en:users:drivers:ath [Linux Wireless]

Btw: BO ist schon länger keine gute Regdomain für Tests mehr, da in dieser mittlerweile recht EU- und US-ähnliche Beschränkungen gelten:

country BO: DFS-JP
   (2402 - 2482 @ 40), (20)
   (5250 - 5330 @ 80), (30), DFS
   (5735 - 5835 @ 80), (30)
1 „Gefällt mir“

Was würdest du denn dann empfehlen?

Unter kontrollierten Bedingungen, in denen eine tatsächliche Abstrahlung von mehr als 100 mW EIRP nicht überschritten werden kann würde ich die Regdomain AS oder BM empfehlen.

2 „Gefällt mir“

ich hab auch kanal 5 getestet, aber auf kanal 6 identisches ergebnis auf nem 1043v5.

Da gab es schon mal einen langen Fred im gluon zu, passt vieleicht nicht ganz aber die Basics bleiben ja :
TP-Link 841n V10 + 940nV3 + 941ndV6 have less transmitting power (dbm) than specification? · Issue #555 · freifunk-gluon/gluon · GitHub

Ja, anscheinend hatten die Router zwischenzeitlich mal etwas zu viel EIRP wegen nbd’s patch gemacht. Falls irgendwer ein teures Messgerät hat, mit dem man die Sendeleistung genau ermitteln kann, dann können wir gerne das Problem noch genauer untersuchen. Bisher sieht es so aus, als wäre der TX-Gain der ART-Partition ignoriert worden. Das heißt auf dem WR841N z.B. 6 dBm zu viel EIRP.

1 „Gefällt mir“