Modify

Opened 3 years ago

Last modified 21 months ago

#19402 new defect

TX power very low on TP-LINK CPE-510

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Chaos Calmer 15.05
Component: kernel Version: Trunk
Keywords: cpe510 ar71xx ath9k lna txpower Cc:

Description

vendor firmware allows up to 27dBm.
On OpenWrt (even with reghack) TX power is very limited. While with the original firmware, links up to a few kilometers are easy to achieve, with OpenWrt range is limited to about 100m :(

Wiphy phy0

max # scan SSIDs: 4
max scan IEs length: 2261 bytes
Retry short limit: 7
Retry long limit: 4
Coverage class: 3 (up to 1350m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0x3 RX 0x3
Configured Antennas: TX 0x3 RX 0x3
Supported interface modes:

  • IBSS
  • managed
  • AP
  • AP/VLAN
  • WDS
  • monitor
  • mesh point
  • P2P-client
  • P2P-GO

Band 2:

Capabilities: 0x11ef

RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40

Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:

  • 5180 MHz [36] (10.0 dBm)
  • 5200 MHz [40] (10.0 dBm)
  • 5220 MHz [44] (10.0 dBm)
  • 5240 MHz [48] (10.0 dBm)
  • 5260 MHz [52] (17.0 dBm)
  • 5280 MHz [56] (17.0 dBm)
  • 5300 MHz [60] (17.0 dBm)
  • 5320 MHz [64] (17.0 dBm)
  • 5500 MHz [100] (17.0 dBm)
  • 5520 MHz [104] (17.0 dBm)
  • 5540 MHz [108] (17.0 dBm)
  • 5560 MHz [112] (17.0 dBm)
  • 5580 MHz [116] (17.0 dBm)
  • 5600 MHz [120] (17.0 dBm)
  • 5620 MHz [124] (17.0 dBm)
  • 5640 MHz [128] (17.0 dBm)
  • 5660 MHz [132] (17.0 dBm)
  • 5680 MHz [136] (17.0 dBm)
  • 5700 MHz [140] (17.0 dBm)
  • 5745 MHz [149] (23.0 dBm)
  • 5765 MHz [153] (23.0 dBm)
  • 5785 MHz [157] (23.0 dBm)
  • 5805 MHz [161] (23.0 dBm)
  • 5825 MHz [165] (23.0 dBm)

valid interface combinations:

  • #{ managed } <= 2048, #{ AP, mesh point } <= 8, #{ P2P-client, P2P-GO } <= 1, #{ IBSS } <= 1, total <= 2048, #channels <= 1, STA/AP BI must match
  • #{ WDS } <= 2048, total <= 2048, #channels <= 1, STA/AP BI must match
  • #{ IBSS, AP, mesh point } <= 1, total <= 1, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz }

HT Capability overrides:

  • MCS: ff ff ff ff ff ff ff ff ff ff
  • maximum A-MSDU length
  • supported channel width
  • short GI for 40 MHz
  • max A-MPDU length exponent
  • min MPDU start spacing

Attachments (0)

Change History (16)

comment:1 follow-up: Changed 3 years ago by ufo@…

we also tested that in the field, that 27dbm (std firmware) vs. 10 dbm (openwrt) on channel 44.
and yes, we therefore had a difference of around 18/19 db, so the numbers within the firmwares are correctly shown.

comment:2 Changed 3 years ago by me@…

Has this been fixed yet?

comment:3 Changed 3 years ago by ufo@…

seems not..
i just test the cc-trunk:

               HT TX/RX MCS rate indexes supported: 0-15
                Frequencies:
                        * 5180 MHz [36] (10.0 dBm)
                        * 5200 MHz [40] (10.0 dBm)
                        * 5220 MHz [44] (10.0 dBm)
                        * 5240 MHz [48] (10.0 dBm)
                        * 5260 MHz [52] (17.0 dBm) (no IR, radar detection)
                          DFS state: usable (for 115 sec)
                          DFS CAC time: 60000 ms
                        * 5280 MHz [56] (17.0 dBm) (no IR, radar detection)
                          DFS state: usable (for 115 sec)
                          DFS CAC time: 60000 ms
...
          * 5745 MHz [149] (disabled)
                        * 5765 MHz [153] (disabled)
                        * 5785 MHz [157] (disabled)
                        * 5805 MHz [161] (disabled)
                        * 5825 MHz [165] (disabled)

comment:4 Changed 3 years ago by valentt

There are lots of these devices deployed so we would really need a fix for this issue. Which driver needs fixing?

comment:5 Changed 3 years ago by valentt

Are there some logs we can get from CPE-510 device to see why ath9k enables only such low output power? From my understanding ath9k driver reads eeprom data and from that data it is interpreting how to configure power output.

Could it be that tp-link has somehow changed eeprom data so it confuses ath9k driver?

I don't have enough knowledge about how to get to eeprom data but if somebody points me in the right direction I'll dig it out :)

comment:6 in reply to: ↑ 1 Changed 3 years ago by valentt

Replying to ufo@…:

we also tested that in the field, that 27dbm (std firmware) vs. 10 dbm (openwrt) on channel 44.
and yes, we therefore had a difference of around 18/19 db, so the numbers within the firmwares are correctly shown.

can you please post 'iw reg get' from your CPE-510 device? and also grep for 'cfg' and 'ath' in logread logs after device boots. This could be a regulatory domain issue also...

comment:7 Changed 3 years ago by valentt

CPE-510 has a 13 dBi antenna

Regulatory domain limits EIRP output power to 20 db which the allowed maximum for channel 36

ath9k reads eeprom data which probably says that antenna has 10 dBi gain

Stock firmware allows to go over regulatory domain restrictions, but you probably had to click somewhere option that says "ignore regulatory power restrictions" and ath9k obeys restrictions so it doens't allow power to go over 10dBm. 10 + 10 = 20 db (3 db tolerance)

To stay within the EIRP limits, tx power has to be limited to 10 dBm

If you apply reghack patch [1] to increase the power limit, the output power should also increase.

[1] http://luci.subsignal.org/~jow/reghack/

comment:8 Changed 3 years ago by valentt

I found this interesting forum post from one Arch Linux user and how he solved issue with low output power.

comment:9 Changed 3 years ago by valentt

My guess is that this is not OpenWrt bug but that reghack patch is broken...

comment:10 Changed 3 years ago by valentt

Comment from Jow on IRC (author of reghack patch):

<jow_laptop> it (A/N: reghack) doesn't catch all instances anymore (A/N: all instances of regulatory restrictions) because the marker rules changed slightly

A/N - author's note

Last edited 3 years ago by valentt (previous) (diff)

comment:11 Changed 3 years ago by valentt

Also Jow from OpenWrt on IRC gave me these two links from which ath9k's sets it's base limitation rules:
http://lxr.free-electrons.com/source/drivers/net/wireless/ath/regd.c#L36
http://lxr.free-electrons.com/source/net/wireless/reg.c#L233

and finally those are further capped by the rules here:
http://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt#n1153

comment:12 Changed 3 years ago by tillw

To me in looks plausible that die TX power is limited to 10 dBm on channels 36-48. (The CPE510 has 13 dBi antenna gain and the EIRP is 23 dBm in my country.)

However, I wonder how the CPE510 knows that it has a 13 dBi antenna gain? I could not find anything about that in the source code:

antenna_gain is not specified in my /etc/config/wireless/ and thus it should be set to 0 in
mac80211.sh. Also calling iw phy0 set antenna_gain 0 manually doesn't change things.

ath9k cards have information about the antenna gain in their EEPROM (which totally makes sense to me since the device vendor knows what antenna they built-in). However, I can't find the 13dBi there either:

# grep -i gain /sys/kernel/debug/ieee80211/phy0/ath9k/*_eeprom
/sys/kernel/debug/ieee80211/phy0/ath9k/base_eeprom:             Tx Gain :          4
/sys/kernel/debug/ieee80211/phy0/ath9k/base_eeprom:             Rx Gain :          0
/sys/kernel/debug/ieee80211/phy0/ath9k/modal_eeprom:           Ant. Gain :          0
/sys/kernel/debug/ieee80211/phy0/ath9k/modal_eeprom:           Ant. Gain :          0

Does anybody know where the information is stored?

comment:13 Changed 3 years ago by anonymous

I'm not an expert regarding unlocking channels and power levels but I see developers who create their own custom openwrt firmwares edit regdb.txt file to unlock channels [1]. Maybe you can also try this approach? Please report back if you succeed.

[1] https://forum.openwrt.org/viewtopic.php?pid=284439#p284439

comment:14 Changed 3 years ago by tillw

I though that the restriction would come from the regulatory settings, too. However, for testing purposes I patched regdb.txt and recompiled cfg80211.ko in order to raise the TX power for my country to 40dBm (10W). I see the changed values in dmesg, but still ath9k does not allow more than 10dBm on e.g. channel 36:

# dmesg
[…]
[   21.810000] cfg80211: Calling CRDA for country: DE
[   21.840000] cfg80211: Regulatory domain changed to country: DE
[   21.840000] cfg80211:  DFS Master region: ETSI
[   21.850000] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[   21.860000] cfg80211:   (2400000 KHz - 2483000 KHz @ 40000 KHz), (N/A, 4000 mBm), (N/A)
[   21.860000] cfg80211:   (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 4000 mBm), (N/A)
[   21.870000] cfg80211:   (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 4000 mBm), (0 s)
[   21.880000] cfg80211:   (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 4000 mBm), (0 s)
[   21.890000] cfg80211:   (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[…]
# iw phy0 info | grep dBm
			* 5180 MHz [36] (10.0 dBm)
			* 5200 MHz [40] (10.0 dBm)
			* 5220 MHz [44] (10.0 dBm)
			* 5240 MHz [48] (10.0 dBm)
			* 5260 MHz [52] (17.0 dBm) (radar detection)
			* 5280 MHz [56] (17.0 dBm) (radar detection)
			* 5300 MHz [60] (17.0 dBm) (radar detection)
			* 5320 MHz [64] (17.0 dBm) (radar detection)
			* 5500 MHz [100] (17.0 dBm) (radar detection)
[…]

comment:15 Changed 2 years ago by daniel@…

Could it be that the TX is not actually the problem but rather missing support for filters in the RX path, similar to the http://wiki.openwrt.org/toh/ubiquiti/unifi_outdoorplus ?

A driver for that is being worked on
https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033522.html

It should be easy to proof by testing stock firmware vs. openwrt with some other similar device on the other end, measuring signal strength of received beacons on both sides.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.