TX-Powerfix Script

Da das zwischendrin verlinkte Paket für den TX Powerfix bei uns nicht lauffähig war habe ich mit @chrisno auf die Schnelle das Ding mal gefixt, ein wenig aufgeräumt und auf Lauffähigkeit im gluon 2016.1++ getestet:

Da wir uns jedoch dafür entschieden haben, fortlaufend die gesetzlichen Grenzwerte zu setzen, muss das Script an der Stelle noch einmal geändert werden, wenn dies nicht gewünscht ist.

Wenn jemand spezielle Wünsche hat kurz Bescheid sagen, dann basteln wir die gerne individuell rein.

1 Like

Mein Vorschlag liegt unter

(und läuft bislang zuverlässig auf einer dreistelligen Anzahl von Routern. TXpower auf „20“ funktioniert nicht bei allen 2,4GHz-Geräten, zumal nicht auf allen Kanälen.)

Das kann nicht lauffähig sein, da es den falschen hwmode abfragt…bei uns ist der je nach Band in den betroffenen Geräten entweder 11ng oder 11na…identischer Fehler war auch im originalen Script zu finden…

Gerade noch einmal auf nem 841 Kanal 1 und 11 getestet. Die 20dbm werden auf den Kanälen auf denen das Gerät Hardwarebedingt weniger Leistung hat einfach mit der maximal möglichen Leistung quittiert - im Fall des 841 ist er dann auf Kanal 1 und 11, trotz 20dbm Eintrag im uci auf 19dbm im iwinfo, funzt also…

Beim 3600 identisch, trotz 23dbm Eintrag im uci fürs 5 GHz geht er nur auf 21dbm / 15dbm (je nach Kanal) im iwinfo, weil er mehr nicht kann.

Das kommt halt auf die site.conf an.
Zumindest bei uns:

root@camp-meinecke-6roof-9540:~# uci show|grep hwmode
wireless.radio0.hwmode='11g'

Aber wenn Du pullrequest machen möchtest: Nur zu.

Ich beschäftige mich weniger mit dem Firmware backen, habe jedoch bei uns in den diversen site.conf noch keinen hwmode Parameter gesehen. Irgendwo wird der Unterschied schon herkommen.

Man könnte natürlich alle Fälle abfangen, das ist, wenn man denn elseif nutzt, kein größerer Aufwand die Fälle noch einzubauen.

Wer also hwmode 11ng/11na hat und alle 3 Gerätetypen (2,4 only, 5 only, dual band) immer auf das regulatorische Maximum respektive der Möglichkeit des Geräts (ja nachdem was höher ist) fixen können will, der kann es benutzen, ändern oder auch lassen, wenn es für den entsprechenden Fall nicht passend ist.

Ich meine mich zu erinnern, dass man da nur etwas anderes als „11g“ für die 2,4er-Radios zu stehen hat, wenn der Knoten vor BB das erste mal mit OpenWRT geflashed wurde.
Also mit 2014er/2013er-Gluons.

Wenn mir jemand Beispiele pasted, dann erweitere ich das.

Spontan aus der schnellen Feder sollte das alle Fälle abfangen können:

if uci:get('wireless', 'radio0', 'hwmode') then
	hwmode = uci:get('wireless', 'radio0', 'hwmode')
	if hwmode == '11ng' then
		interface24 = 'radio0'
		hwmodeR1 = uci:get('wireless', 'radio1', 'hwmode')
		if hwmodeR1 == '11na' then
			interface50 = 'radio1'
		elseif hwmodeR1 == '11a' then
			interface50 = 'radio1'
		end
	elseif hwmode == '11g' then
		interface24 = 'radio0'
		hwmodeR1 = uci:get('wireless', 'radio1', 'hwmode')
		if hwmodeR1 == '11na' then
			interface50 = 'radio1'
		elseif hwmodeR1 == '11a' then
			interface50 = 'radio1'
		end
	elseif hwmode == '11na' then
		interface50 = 'radio0'
		hwmodeR1 = uci:get('wireless', 'radio1', 'hwmode')
		if hwmodeR1 == '11ng' then
			interface24 = 'radio1'
		elseif hwmodeR1 == '11g' then
			interface24 = 'radio1'
		end
	elseif hwmode == '11a' then
		interface50 = 'radio0'
		hwmodeR1 = uci:get('wireless', 'radio1', 'hwmode')
		if hwmodeR1 == '11ng' then
			interface24 = 'radio1'
		elseif hwmodeR1 == '11g' then
			interface24 = 'radio1'
		end
	else
		os.exit(0) -- something went wrong
	end
end

abgesehen davon das das u.U. das Gerät brät : hier noch ein Hinweis zu TX-Power und ART.bin auf mtd der Router - dort sind die spezifika des Chips hinterlegt. Darauf aufbauend kommen dann die regulatory Daten - die man auch anpassen kann. Grundsätzlich gilt, man kann nach „unten“ hin immer Einschränken, aber von unten nicht aufbohren.
(sprich wenn der Treiber in d den ART specs sagt 12 dB dann is da schluss, egal was regd DE sagen)
Dachte die alten Tests interessieren wen, bei dem Topic musst ich einfach an die maue Leistung vom 710’er denken.

ich hatte den TP 841 v9 auch auf 30 dB, den TP 710 auf 22 dB gebracht, dazu brauchts aber ein wenig mehr … hier unkorrigiert meine Notizen - auch wenn das hier nicht gemeint ist.
Und Hinweis: die Geräte hören durch mehr dB nicht besser! Deshalb will man in der Regel gute Lage + Antennen.
und
Gesetze und Regularien werden zum einhalten gemacht

# iw reg set DE 00 BO
# is still limited to crda or regd
# iw phy0 set txpower fixed 2000
# iw client0 set txpower fixed 2000
# iwinfo phy0 txpowerlist
# iwinfo client0 txpowerinfo

# test alpha - try to use in-kernel regulatory and circumvent crda and regulatory.bin
# add a modified regd.txt to 
# gluon/openwrt/build_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/linux-3.18.23/net/wireless/
# you can get a valid one from 
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
# changed output in DE -> 400 mW and 00 -> 40 (which means 40 dB) 
# enable Kernel module CONFIG_CFG80211_INTERNAL_REGDB in
# gluon/openwrt/build_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/linux-3.18.23/net/wireless/Kconfig

# test beta - make ART writeable and add hacked art.bin
# find gluon/openwrt/target/linux/ar71xx/files/drivers/mtd/tplinkpart.c
# or gluon/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/linux-ar71xx_generic/linux-3.18.23/drivers/mtd/tplinkpart.c
# remove         parts[3].mask_flags = MTD_WRITEABLE;
# maybe needed : make clean
# http://luci.subsignal.org/~jow/reghack/ reghack.c
# now mtd art is writeable
# /tmp# mtd -r write artHACKED.bin art
# after reboot : iw reg set VI
# https://wiki.openwrt.org/toh/tp-link/tl-wr841nd
# https://goo.gl/InZONA
# prooved to work up to 30 dB !!!

# test gamma
# try to hack art files 
# similar to artHACKED.bin
# get your art file (and keep a safe copy !)
# https://github.com/pepe2k/ar9300_eeprom/
# run something like (for 2.4ghz) 
# ./ar9300_eeprom -y0 art/art.test.710 -u test
0x000010C0  00 00 00 70 AC 70 89 AC 70 89 AC 70 89 AC FF FF |...p.p..p..p....| / 00 00 00 70 AC 70 89 AC 70 89 AC 70 89 AC FF FF |...p.p..p..p....|
0x000010D0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................| \ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
0x000010E0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................| / FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
0x000010F0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................| \ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
0x00001100  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................| / FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
0x00001110  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................| \ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
0x00001120  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................| / FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
0x00001130  FF FF FF FF FF FF 11 12 15 17 41 42 45 47 31 32 |..........ABEG12| \ FF FF FF FF FF FF 11 12 15 17 41 42 45 47 31 32 |..........ABEG12|
# (before FF'ing needed? not testet ... ) 
# following raise txpower on tp710 up to 20db in reg DE
# normaly this is limited to 12 dB
# (these are changes made by eeprom9300)
0x00001170  AC B8 3C 7C 7C 3C 3C 7C 7C 3C 3C 7C 7C 3C 3C 7C |..<||<<||<<||<<|| \ AC B8 18 58 58 18 16 64 64 14 14 64 64 12 12 60 |...XX..dd..dd..`|
0x00001180  7C 3C 3C 7C 3C 7C 3C 7C 3C 7C 3C 7C 3C 7C 3C 7C ||<<|<|<|<|<|<|<|| / 60 10 3C 7C 3C 7C 3C 7C 3C 7C 3C 7C 3C 7C 3C 7C |`.<|<|<|<|<|<|<||
# prooved to work up to 30dB in VI, 20dB in DE
# but above 25 dB no effect on controll router, so better not raise above (which is still double of 12dB or 10 times more power)

3 Likes

Also ich habe das Script selbst auch getestet und es funktioniert in den meisten Fällen nicht richtig.
Mein Test 741nd V4 nimmt nichts größer als 16dbm in den Settings an. Auch nach mehreren Tests und Bastelei nicht.

Bei meinem 841nd V5 habe ich die TXPower erhöhren können, allerdings ist dies nur kosmetischer Natur denn die Outputpower hat sich nicht geändert. Dies habe ich mit Kismet und zwei verschiedenen Android Geräten und Wifi-Analyzer getestet.

Wir haben uns für DDorf daher entschieden den Fix nicht mit einzubauen, bis jetzt haben wir dadurch auch keine Nachteile sehen können.

So alte Klamotten habe ich nicht hier zum Testen.

Wenn sich die TXPower nur kosmetisch ändert, ohne tatsächliche Auswirkung, dann müsste man mal ergründen warum das so ist.

Aus meiner Sicht gibt es (zumindest in den Grenzen der Country Table und ART File) keinen ersichtlichen oder nachvollziehbaren Grund, warum bspw. ein 841v9 die angezeigte Sendeleistung von 20dbm nicht auch können sollte (ausser auf Kanal 1 und 11 die wiederum in der Hardware limitiert sind, wenn man sie nicht wie oben beschrieben umschreibt).

Naja das Problem ist das wenn so ein Script eingebaut wird es auch für alle Modelle funktionieren muss.
Wenn es nur bei einer Hand voll Geräten funktioniert dann sollte man es nicht einbauen.

Es gibt ein Issue dazu im Gluon Github Repo:

Dort wird unter anderem dies hier geschrieben:

I tolked with tp-link, and they confirmed, that the EIRP CE: <20dBm(2.4GHz) *inclusive standard antennas.
Means, you have to add nothing. It is a common misundertanding, that the specification are w/o antenna if the antenna gain is told in additon.

I also refer also to WLAN-Strahlung und zulässige Grenzwerte - com! professional (in German) „…Diese Angaben beziehen sich auf die Strahlungsleistung des gesamten Geräts inklusive Antennen. Die Strahlungsleistung als EIRP (Equivalent Isotropically Radiated Power) berechnet sich wie folgt: elektrische Sendeleistung des Access-Points (in dBm) plus Antennengewinn (in dBi) minus Dämpfung durch Antennenkabel, Stecker und so weiter (in dB)…“

Das was in der ART Partition gespeichert ist, ist für dieses Gerät mit Originalantennen ausgelegt und wenn man anderen Antennen anschließt muss man selbst dafür sorgen die TXPower zu senken damit man innerhalb Richtlinien bleibt.

Auch entsprechen die Werte in OpenWRT nicht der Wahrheit da es kein Framework gibt dies ordentlich zu berechnen (Z.b. ein Standard der Antennengewinn + TX Power einzeln speichert so das iwinfo diese Werte korrekt anzeigen kann)

Ich habe mir erlaubt, das zu übernehmen:

3 Likes

Hi adorfer,

ich hab da mal zwei Fragen: Das ursprüngliche Script kommt ja von ffho, zumindest hat das mit unserer Version deutliche Übereinstimmungen :wink:

Zeile 59: „if maximumTxPowerDb < 30 then“ Das bedeutet doch soviel wie: Wann immer die maximal mögliche Leistung kleiner als 30dBm ist, nimm diese. Das wären 1 Watt plus Antennengewinn, also zu viel für Deutschland eigentich.

Wenn ich das richtig sehe fragt ihr nicht ab, ob schon eine tx-power gesetzt ist. Ihr überschreibt damit vom Benutzer gesetzte Werte, beispielsweise bei einer Bullet HP (27dBm) mit einer 15 dB Rundstrahlantenne kommt ihr mit dem Script mal eben auf 42 dBm (das sind mehr als 10 Watt EIRP). Und das ohne dass der Benutzer dagegen etwas tun kann.

Oder übersehe ich da gerade einfach nur was?

Das funzt eh alles nicht mehr richtig, da es von wem auch immer zerbastelt wird.

Die Rocket hat ein Hardware Limit von 18dbm gesetzt, der 4900 17dbm…und da reden wir über Chips die 28-30dbm Hardware Limit hätten.

Ich verstehe irgendwie nicht mehr wer und vor allem warum das alles kaputt repariert wird!?

1 Like

Tja, die Milchjungpersonenrechnung lautet etwa:

20dBm sind zulässig (auf Randkanälen 1-2dB weniger), Antennengewinn müssen wir abziehen, und wenn der Hersteller die Antennen mit 6dB angibt, dann wird der Wert von den 20 abgezogen.

Voila, fertig ist das TXpowerlimit von 13…

Können wir nicht mal ne Liste machen bei welchem Router welcher maximale TX Wert gesetzt werden darf?

Das geht ja in die gleiche Richtung wie eine Frage zur 9dbm Einstellung bei einer CPE210 vor ein paar Tagen.

1 Like

Ich bin leider nicht mehr auf dem Laufenden, deshalb frage ich kurz nach:

  • Ist das ein Gluon oder OpenWrt Problem?
  • Tritt das Problem erst seit Chaos Calmer auf?
  • TP-Link speichert in der Art-Partition falschen Antennengewinn ab?

Würde es helfen eine ältere Version der Regulatory-Steuerung in die Firmware zu packen? Ich kann dies nächstes Wochenende mal ausprobieren …

  • wie könnt Ihr Euch sicher sein, dass die früheren Einstellungen nicht falsch waren und diese jetzt, hier nun richtig sind?
  • Vergleich mit kalibrierter Hardware
  • Messung der abgestrahlten Leitung?
  • ist der Atheros-Treiber auch geändert worden?

Vorab vielen Dank für die Antworten

Nicht anzunehmen.

TP-Link gibt für den 4900 zwei Leistungsangaben an, nämlich:

CE: 2,4GHz 20dbm / 5GHz 23dbm
FCC: 2,4/5GHz 30dbm

Gluon / OpenWRT setzen das dann offensichtlich auf bspw. 17dbm im 5 GHz Band. Ein Einspielen des Reghack verändert den Hardware Grenzwert dann zumindest wieder hoch auf CE Wert, also 23dbm.

Das Funkmodul selber ist mit 30dbm auch bei Mikrotik im Einsatz, scheint also auch nicht ganz aus der Luft gegriffen die TP-Link Angabe.

Ein Verändern des Country Code etc. nutzt im Übrigen nichts mehr, da es sich tatsächlich um den gesetzten Hardware Grenzwert handelt, nicht um die Country Regulation.

Der Reghack für PPC scheint also zu funzen, der für MIPS jedoch leider nicht. Ein Einspielen in eine Rocket hatte keinerlei sichtbaren Erfolg, außer das sämtliche Country Regulations weggebacken waren, was jedoch nichts nutzt, wenn 40dbm in der Country Regulation stehen während der Hardware Grenzwert auf 18dbm festgetackert wurde.

Dort wurden schon ein paar blödsinns Werte zusammengetragen:

Über eine Lösung wie man den quatsch da rausbacken kann würde ich mich freuen, denn ich würde dann doch gerne von Fall zu Fall selber entscheiden wieviel TX-Power vom jeweiligen Chip ich bei der entsprechenden Kabel / Antenneninstallation benötige.

1 Like

Vielleicht kann man ein FCC Gerät ordern und die ART auslesen und auf die Deutschen Geräte kopieren. Danach müsste sich mit txpower der hier zugelassene Wert einstellen lassen.