[PATCH] Revert openwrt patch which caused too high tx powers

Di Okt 9 12:24:49 CEST 2018

hi

On 10/9/18 12:13 PM, Florian Wiessner wrote:
> Hallo Adrian,
> 
> 
> ich habe jetzt mal die Firmware ohne besagten Patch gebaut und komme nun
> wieder auf normale Werte. Ich habe gesehen dass für die Ubiquity Geräte
> separat ein File existiert, wo Antenna Gain gesetzt wird. Unter anderem
> ist dies auch für den WR1043ND v1 so. Mit der aktuellen Firmware
> funktioniert das jedenfalls nicht so wie es gedacht ist:
> 
> https://monitoring.freifunk-franken.de/routers/3000
> 
> Hier bleibt TX-Power nach wie vor auf 20dbm. Das ist die aktuelle
> Firmware und das abziehen der 3dbi Antenna Gain scheint nicht zu
> funktionieren, obwohl es sollte:
> cat ./src/packages/fff/fff-wireless/files/etc/wifi.tl-wr1043nd-v1
> uci -q set wireless.radio0.antenna_gain=3
> uci -q commit wireless
> 
> Das besagte File finde ich mit 20180802 nicht auf dem Gerät.
> 
> Bei den wr1043nd v2 - v5 habe ich noch mal nachgeforscht, hier ist mit
> der aktuellen Firmware die TX-Power mit 14dbm etwas zu niedrig. Lt.
> https://wiki.freifunk.net/TP-Link_WR1043ND haben die Antennen 3dbi, d.h.
> hier sollte die TX-Power auf 17dbm stehen und nicht auf 14dbm. Da bei
> den v2 - v4 Geräten die Antennen getauscht werden können, würde es
> meiner Meinung nach schon Sinn machen, das evtl. über das Webinterface
> des Routers konfigurierbar zu machen. Bzgl den CPE210 hat die
> Stock-Firmware ebenfalls 11dbm, allerdings ist Deine Behauptung, die
> würden mit der alten Firmware mit 800mW EIRP raushauen nicht richtig.
> Hardwareseitig schaffen die CPE210 max 27dbm (inkl. Antennen) ~ 500mW
> und lt. Datastheet schafft sie auch nicht mehr als 500mW. Interessant
> ist, dass mit der Stockfirmware im Test-Mode hier sich max. 27dbm
> Einstellen lassen - diese Einstellung inkludiert jedoch die 9dbi Gain.
> Es ist hier also nicht so, dass man 36dbm erhält wenn man 27dbm
> einstellt, d.h. die Stockfirmware berücksichtigt das gleich.
> Interessanterweise sind die CPE210 seit dem Update auf 20180802 trotzdem
> irgendwie leiser als die Stockfirmware, ich kann es leider mangels
> Equipment nicht genau nachmessen.
> 
> Ein paar weitere Fragen haben sich nach Sichtung der Firmware etc ergeben:
> 
> - warum wird nur 11g gesetzt, nicht 11n - soweit ich das verstehe ist es
> ein Setting aus dem Hoodfile, spricht etwas dagegen auf 11n zu gehen?

diese Frage kann ich dir beantworten:
.
die 11n Datenraten bilden sich (irgendwie Magie[TM]) aus 11g Datenraten ab.

hwmode:
Selects the wireless protocol to use, possible values are 11b, 11g, and
11a (note that 11ng and 11na are not available options, see ticket 17541
-> https://dev.openwrt.org/ticket/17541 )

Quelle: https://wiki.openwrt.org/doc/uci/wireless

Bzw. aus dem Ticket:
Expected, config changed. 11g / 11a selects the band, htmode NOHT
disables 11n, htmode HT20 / htmode HT40 enables 11n.

Wichtig ist das ein htmode gesetzt ist, was bei uns auch der Fall ist.
Es ist also 11n bereits aktiv und hier muss nichts mehr getan werden.

mfg

Christain

> - warum flappt batman-adv von client-mode zu off:
> [64826.379519] batman_adv: bat0: Changing gw mode from: off to: client
> [64885.313160] batman_adv: bat0: Changing gw mode from: client to: off
> [64886.336979] batman_adv: bat0: Changing gw mode from: off to: client
> [64945.314169] batman_adv: bat0: Changing gw mode from: client to: off
> [64946.334612] batman_adv: bat0: Changing gw mode from: off to: client
> [65005.314302] batman_adv: bat0: Changing gw mode from: client to: off
> 
> - iw reg get liefert für global zwar DE, für phy0 aber nach wie vor US?
> iw reg get
> global
> country DE: DFS-ETSI
>         (2400 - 2483 @ 40), (N/A, 20), (N/A)
>         (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
>         (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
>         (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
>         (5725 - 5875 @ 80), (N/A, 14), (N/A)
>         (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> 
> phy#0
> country US: DFS-FCC
>         (2402 - 2472 @ 40), (N/A, 30), (N/A)
>         (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
>         (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
>         (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
>         (5735 - 5835 @ 80), (N/A, 30), (N/A)
>         (57240 - 63720 @ 2160), (N/A, 40), (N/A)
> 
> - wieso ist die batman-adv loop protection abgeschaltet?
> 
> 
> 
> 
> Am 23.09.2018 um 16:40 schrieb Adrian Schmutzler:
>>
>> Hallo,
>>
>>  
>>
>> den inhalt der verlinkten Mail verstehe ich leider nicht. Vielleicht
>> ist jemand anderes schlauer als ich …
>>
>>  
>>
>> Grüße
>>
>>  
>>
>> Adrian
>>
>>  
>>
>> *From:*franken-dev [mailto:franken-dev-bounces at freifunk.net] *On
>> Behal**f Of *Florian Wiessner
>> *Sent:* Sonntag, 23. September 2018 01:01
>> *To:* Fabian Bläse <fabian at blaese.de>; franken-dev at freifunk.net; Tim
>> Niemeyer <tim at tn-x.org>
>> *Subject:* Re: [PATCH] Revert openwrt patch which caused too high tx
>> powers
>>
>>  
>>
>> Hallo,
>>
>>
>> gerade bin ich noch hierüber gestolpert:
>>
>> https://lists.openwrt.org/pipermail/openwrt-devel/2017-August/008512.html
>>
>> Am 23.09.2018 um 00:54 schrieb Florian Wiessner:
>>
>>     Hallo,
>>
>>
>>     ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit
>>     Update auf 20180802 habe ich tote meshrouter.
>>
>>     Ich habe enorme Reichweiteneinbußen, und Links die vorher
>>     reibungslos funktionierten, gehen nun gar nicht mehr.
>>
>>     Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.
>>
>>     https://monitoring.freifunk-franken.de/routers/5704
>>
>>     Ganz schlimm:
>>
>>     https://monitoring.freifunk-franken.de/routers/5842
>>
>>     https://monitoring.freifunk-franken.de/routers/4873
>>
>>     Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm
>>
>>
>>     Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?
>>
>>
>>
>>     Am 20.01.2018 um 16:09 schrieb Fabian Bläse:
>>
>>         Hallo Tim,
>>
>>          
>>
>>                 Since the reverted patch, device specific antenna gain is not set for
>>
>>                 some reason.
>>
>>                 Reverting the patch in question fixes this issue.
>>
>>             Warum? Woher kommt die Erkenntnis?
>>
>>         Viel testen, googlen, ..
>>
>>         Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.
>>
>>          
>>
>>         Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.
>>
>>          
>>
>>                 THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
>>
>>                 FIXED PROPERLY!
>>
>>             -v bitte..
>>
>>         Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.
>>
>>          
>>
>>             Wer wird es mal "richtig" fixen?
>>
>>         Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
>>
>>         Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
>>
>>          
>>
>>         Fabian
>>
> 
> -- 
> Mit freundlichen Grüßen
> 
> Florian Wiessner
> 
> 
> <http://www.smart-kvm.com/>
> 
> 
> smart-kvm.com
> c/o Smart Weblications GmbH
> Martinsberger Str. 1
> D-95119 Naila
> fon.: +49 9282 9638 200
> fax.: +49 9282 9638 205
> 24/7: +49 900 144 000 00 - 0,99 EUR/Min*
> http://www.smart-kvm.com
> 
> --
> Sitz der Gesellschaft: Naila
> Geschäftsführer: Florian Wiessner
> HRB-Nr.: HRB 3840 Amtsgericht Hof
> *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20181009/257cf5ca/attachment.sig>