I have 5 Sophos AP55C with identical hardware revision and identical OpenWRT version. Offers 23dB maximum transmit power and all others only 13dB. - How can I set/correct this?
Make sure they use a channel which is certified for that transmit power (You now use different channels which might have different max power) furthermore country settings might also play a role, some countries allow higher max power than others so check the country settings
2 Likes
The performance is too low for all but one of them. Could it be the driver? - The performance should be 19-23dB, but only 13dB is offered.
If you have all the setting duplicated "region band and channel'
and after power cycle if it's still different
it's time to start dumping the factory calibration data "ART"
and looking for differences
you can dig thought GitHub and the radio drivers for lookup tables for the art area
1 Like
You selected "auto channel", but they went to different channels 36 and157.
They have different max power(200 mW vs 25 mW in Europe), see e.g. here:
https://en.wikipedia.org/wiki/List_of_WLAN_channels
2 Likes
I don't know how to do. I'm totally new in OpenWRT an I'm more a Windows man. 
According to my research, 20 dB is OK in Germany, but the access points only do 13 dB even though they can do much more.
Is this an Atheros card? I'd similar problem which comes down to the data in the ART EEPROM. Conversation starts here: 5GHz Low performance on TP-Link Archer C6 V2 - #92 by Cthulhu88
There is the antenna gain, which the driver takes into account, but it's very odd that it has different (capped) max power between regions where the rules are the same. I assume it's a bug with the OpenWrt patches that modify power based on antenna gain, which is probably reading incorrect data from the EEPROM.
Yes , it is. - Do you have an Idea to fix it? - one of five goes full power.
I "fixed" mine by setting the region to US, which allowed me to operate at 25 dBm. My country has the same rules for 2.4G as the US, with the exception that channels 12 and 13 are also allowed, which I don't really need.
According to the regulatory database at: https://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git/tree/db.txt for DE (Germany):
country DE: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
# WiFi 6E
(5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
5150 - 5250 -> 200 mW / 23 dBm (converted to integer)
(DFS) 5250 - 5350 -> 100 mW / 20 dBm
(DFS) 5470 - 5725 -> 500 mW / 26 dBm (converted to integer)
5725 - 5875 -> 25 mW / 13 dBm (converted to integer)
As you can see, the only one that limits power to 13 dBm is the 5725 - 5875 range, which is intended for short range devices.
Try picking one of the others, avoid DFS ranges if you can, which leaves you with the first range 5150 - 5250, which can operate at 23 dBm.
If you still cannot operate at a higher dBm because of the EEPROM, switch the region to US, pick a channel allowed in your region and set max power to the one allowed from the info above.
I am not familiar with ETSI, so you might want to check the links provided in the comments:
# Allocation for the 5 GHz band (Vfg. 7 / 2010, Allgemeinzuteilung von
# Frequenzen in den Bereichen 5150 MHz - 5350 MHz und 5470 MHz - 5725 MHz fĂĽr
# Funkanwendungen zur breitbandigen Datenübertragung, WAS/WLAN („Wireless
# Access Systems including Wireless Local Area Networks“).
# https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2010_07_WLAN_5GHz_pdf.pdf
#
# The ETSI EN 300 440-1 standard for short range devices in the 5 GHz band has
# been implemented in Germany:
# https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2014_69_SRD_pdf.pdf
that s right!,maybe different DTS. maybe diffferent devices, just different way to get info for the radio.
as you have not stated, I'll try again
lots of radio won't correctly change regions on the fly
they are one time setting after power on etc
so no software reset is not good enough
please Make sure they are using the same firmware version of OpenWRT
please select a given channel on your chosen band
please select your region
please make sure your radio is enabled on a that channel on that band
then power cycle your device < < < < < <
now compare your results after it's booted
This is not correct. Either those values (or offsets) are stored in the EEPROM or they are dynamically set by software running on OpenWrt, in most cases it's a combination of both as patches applied to the drivers tend to modify the power cap based on EEPROM data ( see, https://github.com/openwrt/openwrt/blob/openwrt-23.05/package/kernel/mac80211/patches/ath9k/365-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch and https://github.com/openwrt/openwrt/blob/openwrt-23.05/package/kernel/mac80211/patches/ath9k/356-Revert-ath9k-interpret-requested-txpower-in-EIRP-dom.patch ).
In either case, it has nothing to do with first boot, anything that OpenWrt generates on the first boot can be modified and will work with the new parameters afterwards, you can in fact, even rewrite the ART partition with custom changes.
Changing your region is intended to work dynamically every time, and if it's not working, it's a bug.
Whether the referenced EEPROM data is correct or not is another story and again, has nothing to do with "first boot".
I have seen this multiple times with OpenWrt
however, it happens and the logs show you
the region only takes hold after a full power cycle
not even a software reset
I have been stung myself with this
As a Windows user my self, I'm not sure what that's got to do with anything
but as getting your ART / radio calibration data
System>Backup/Flash Firmware> Save mtdblock contents
Select the partition you want, so "ART" or "calibration" or "radio data"
it can be different depending on your model
as for what to do with it
well, if you don't know about programming and data handling
it's a bit much to start teaching you on here
What logs? hostapd/wpad works with the regulatory database at /lib/firmware/regulatory.db, with the region you've set. You can confirm that by typing iw reg get.
LuCI displays and limits settings based on the regulatory database + known hardware limits (available via iw list).
Your settings (including the region) are passed to the driver. The driver is then free to honor those settings or change them, often after reading data from the EEPROM.
Mon Aug 12 05:01:17 2024 kern.debug kernel: [ 15.683338] ath: doing EEPROM country->regdmn map search
Mon Aug 12 05:01:17 2024 kern.debug kernel: [ 15.683352] ath: country maps to regdmn code: 0x3a
Mon Aug 12 05:01:17 2024 kern.debug kernel: [ 15.683360] ath: Country alpha2 being used: US
Mon Aug 12 05:01:17 2024 kern.debug kernel: [ 15.683367] ath: Regpair used: 0x3a
As you can see, with my region set to US, it tries to find the data mapped to US in the EEPROM. If the data mapped to a specific country/region is too restrictive/incorrect (from what I understand this is common with Atheros), that is a completely different issue.
Anyway, what you're saying is nonsense. You are also suggesting the hardware magically detects your region when booting for the first time and is then, somehow, overwriting to read only memory.
The bit about not knowing how to code is also nonsense. You can understand the binary format of data without knowing anything about programming. I figured (and manually parsed with Python) the format of the regulatory.db by just looking at its data structure https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git/tree/regdb.h
Even OpenWrt complies with regulations
and if a radio is locked to a specific region
default OpenWRT behaviour is to comply with the regional regulations
and unless you customise your openwrt to bypass this
it will be locked to a specific region
this includes a region if not specificity locked
to be able to only set the region once after a power cycle
so on some radio's with the normal OpenWRT release
you can change the region or only once after power on
if can see this in the open logs as the region changed if refused or changed back
as being in a country that supports ch13 on 2.4G
if the radio was locked to US It could not use CH13 it would not allow
the pll to lock on that frequency no matter how many times openwrt asked it to
until I changed the radios's internal region setting on it's eprom
That's not how it works, and I've already explained how it actually works above. I'll not keep arguing over this though, so believe whatever you want.
A small, final note: if it worked the way you believe it works, routers sold in the market would have to operate under the safe-for-all World region at all times, otherwise the manufacturer would lose money by not selling the product to a wider/international audience.
I'm sorry i'm trying to help @luckymr74
for the help you need I don't have it