R6260 - Very low Tx power

Hi

I have the netgear R6260 router at home and found this device is supported by openwrt.
I installed the latest image from trunk yesterday. The wifi router is up and all functionalities are working properly except the wifi transmission power.

I have set the country code properly to SG and the max limit is 20dbm as per regulations. But I am only getting 6dbM TX power which is not enough to cover the entire home.

Please help me fix this issue.

Some relevant logs:

root@OpenWrt:~# iw reg get
global
country SG: DFS-FCC
	(2400 - 2483 @ 40), (N/A, 23), (N/A)
	(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
	(5250 - 5350 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
	(5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
	(5725 - 5850 @ 80), (N/A, 30), (N/A)
	(57000 - 66000 @ 2160), (N/A, 40), (N/A)

root@OpenWrt:~# iw phy phy1 info
Wiphy phy1
	wiphy index: 1
	max # scan SSIDs: 4
	max scan IEs length: 2304 bytes
	max # sched scan SSIDs: 0
	max # match sets: 0
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports AP-side u-APSD.
	Device supports T-DLS.
	Available Antennas: TX 0xf RX 0xf
	Configured Antennas: TX 0xf RX 0xf
	Supported interface modes:
		* IBSS
		* managed
		* AP
		* AP/VLAN
		* monitor
		* mesh point
		* P2P-client
		* P2P-GO
	Band 2:
		Capabilities: 0x1ff
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: No restriction (0x00)
		HT TX/RX MCS rate indexes supported: 0-31
		VHT Capabilities (0x338001f8):
			Max MPDU length: 3895
			Supported Channel Width: 160 MHz, 80+80 MHz
			RX LDPC
			short GI (80 MHz)
			short GI (160/80+80 MHz)
			TX STBC
			RX antenna pattern consistency
			TX antenna pattern consistency
		VHT RX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: MCS 0-9
			4 streams: MCS 0-9
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 0 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: MCS 0-9
			4 streams: MCS 0-9
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 0 Mbps
		Frequencies:
			* 5180 MHz [36] (6.0 dBm)
			* 5200 MHz [40] (6.0 dBm)
			* 5220 MHz [44] (6.0 dBm)
			* 5240 MHz [48] (6.0 dBm)
			* 5260 MHz [52] (6.0 dBm) (radar detection)
			* 5280 MHz [56] (6.0 dBm) (radar detection)
			* 5300 MHz [60] (6.0 dBm) (radar detection)
			* 5320 MHz [64] (6.0 dBm) (radar detection)
			* 5500 MHz [100] (6.0 dBm) (radar detection)
			* 5520 MHz [104] (6.0 dBm) (radar detection)
			* 5540 MHz [108] (6.0 dBm) (radar detection)
			* 5560 MHz [112] (6.0 dBm) (radar detection)
			* 5580 MHz [116] (6.0 dBm) (radar detection)
			* 5600 MHz [120] (6.0 dBm) (radar detection)
			* 5620 MHz [124] (6.0 dBm) (radar detection)
			* 5640 MHz [128] (6.0 dBm) (radar detection)
			* 5660 MHz [132] (6.0 dBm) (radar detection)
			* 5680 MHz [136] (6.0 dBm) (radar detection)
			* 5700 MHz [140] (6.0 dBm) (radar detection)
			* 5720 MHz [144] (6.0 dBm) (radar detection)
			* 5745 MHz [149] (6.0 dBm)
			* 5765 MHz [153] (6.0 dBm)
			* 5785 MHz [157] (6.0 dBm)
			* 5805 MHz [161] (6.0 dBm)
			* 5825 MHz [165] (6.0 dBm)
			* 5845 MHz [169] (disabled)
			* 5865 MHz [173] (disabled)
	valid interface combinations:
		* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 16,
		  total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 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
	max # scan plans: 1
	max scan plan interval: 0
	max scan plan iterations: 0
	Supported extended features:
		* [ VHT_IBSS ]: VHT-IBSS
		* [ RRM ]: RRM
		* [ SET_SCAN_DWELL ]: scan dwell setting
		* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
		* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
		* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
		* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
		* [ AQL ]: Airtime Queue Limits (AQL)
		* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
		* [ DEL_IBSS_STA ]: deletion of IBSS station support
		* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
		* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option htmode 'HT20'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid '**********'
	option encryption 'psk2'
	option key '**********'
	option wpa_disable_eapol_key_retries '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option htmode 'VHT80'
	option cell_density '0'
	option channel '44'
	option country 'SG'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid '**********'
	option encryption 'psk2+ccmp'
	option key '**********'
	option wpa_disable_eapol_key_retries '1'

There was a similar topic a week ago. Your device has the same WLAN hardware and it is mentioned in the discussion.

Yeah sounds like an EEPROM issue as well. You could try to rebuild with this patch:

Alternative is to recompile with the patch set linked to a bit later, the one that adds a Sercomm parser.

Oh I have never compiled openwrt :sweat:
Let me check some docs and try to figure out

@Borromini There seems to be two different set of patches

  1. Sercomm patches:
    https://patchwork.ozlabs.org/project/openwrt/patch/20210225201800.2478284-2-jan@3e8.eu/
    https://patchwork.ozlabs.org/project/openwrt/patch/20210225201800.2478284-3-jan@3e8.eu/

  2. EEPROM offset fix
    https://github.com/openwrt/openwrt/commit/4716c843d6

Which one should I use it

The second one you linked to is already in the OpenWrt tree. And it has subsequently been reverted. The first set will work. I linked to the wrong post in the R6850 topic, I fixed that link. That's the easier patch, compared to the Sercomm patch set.

It seems to boil down to bad blocks in the NAND, the Sercomm patch set takes care of that in a cleaner way, my patch is more of a hack. It cannot be upstreamed. The Sercomm patches can, but not in their current form (the author got asked to rewrite them but there has been no response).

I can whip you up an image if you'd like, but that's just a one-time offer. If you need newer images you'd need to build yourself.

Thanks for offering the image buliding. I started compilation with the second patch and it is going on for long time, will update once if finishes.

From your explanation, I think it is better for me to integrate the sercomm patches and test again also

Good news. Compilation with the sercomm patches worked. Thanks @Borromini @pavelgl for your help

3 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.