OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version openwrt-19.07
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Luca Bensi - 10.05.2020
Last edited by Christian Lamparter - 09.06.2020

FS#3088 - Decreased WiFi range switching from ar71xx to ath79 on WNDR3700

Device: Netgear WNDR3700v1

OpenWrt version: openwrt-19.07.2-ath79-generic-netgear_wndr3700 (stable release, pre-built image)

Description:
Switching from openwrt-19.07.2-ar71xx-generic-wndr3700 to openwrt-19.07.2-ath79-generic-netgear_wndr3700 leads to decreased wireless range.

The signal strength, measured with the same device in the same place, drops by about 20 dBm. Getting full signal strength on a Samsung Galaxy S4 is almost impossible, even half a meter away from the router in direct line of sight.
The connection frequently drops in places where it used to be about 50% strength and stable

The issue is consistent across devices (Windows laptop, Ubuntu laptop, Android phone) and during the whole day and night.

Performances with openwrt-19.07.2-ar71xx-generic-wndr3700 are on par with the old openwrt-15.05-ar71xx-generic-wndr3700, which I was used to.

Steps to reproduce:
- install openwrt-19.07.2-ar71xx-generic-wndr3700 image
- configure wireless
- measure signal strength in one or more locations
- install openwrt-19.07.2-ath79-generic-wndr3700 image via LuCI, without retaining the configuration
- configure wireless with same settings as above
- compare signal strength in same locations as above

Closed by  Christian Lamparter
09.06.2020 20:14
Reason for closing:  Fixed
Additional comments about closing:  

https://git.o penwrt.org/?p=openwrt/openwrt.git;a=comm it;h=61307544d1f1ab81a2eb3a200164456c593 08d81

Luca Bensi commented on 12.05.2020 21:14

My mistake: in line 4 of "steps to reproduce", the image should be openwrt-19.07.2-ath79-generic-netgear_wndr3700

Project Manager
Adrian Schmutzler commented on 13.05.2020 17:34

Edited ath9k→ath79 in the title and
edited ar71xx→ath79 in the steps

Maciej Mazur commented on 26.05.2020 17:38

I can confirm the same issue with openwrt-19.07.3. I have upgraded from openwrt 17.x and experienced major issues with WIFI connection. Signal was poor, client were disconnecting all the time.
I had to change from openwrt-19.07.3-ath79-generic-netgear_wndr3700v2-squashfs-sysupgrade.bin to openwrt-19.07.3-ar71xx-generic-wndr3700v2-squashfs-sysupgrade.bin and so far so good

Project Manager
Adrian Schmutzler commented on 26.05.2020 18:54

Note that lede-17.01 (since mentioned) does not properly set antenna gain on many devices (has never been fixed) and therefore shouldn't be used as reference. This is just FYI, as the original report was solely based on 19.07.

Maciej Mazur commented on 27.05.2020 12:16

Thank you for additional information.

I am referencing 17.01 just FYI. My wireless was working correctly on openwrt-17, then I decided to upgrade to openwrt-19.07.03 and used openwrt-19.07.3-ath79-generic-netgear_wndr3700v2-squashfs-sysupgrade.bin (just as mentioned here https://openwrt.org/toh/netgear/wndr3700#tab__firmware_downloads ) and started experiencing issues with my wireless connections (with multiple client devices).
Then I changed firmware to openwrt-19.07.3-ar71xx-generic-wndr3700v2-squashfs-sysupgrade.bin and the problems disappeared.

So I am just confirming that openwrt-19.07.3-ath79-generic-netgear_wndr3700v2-squashfs-sysupgrade.bin causes problems in my case.

Hannu Nyman commented on 27.05.2020 15:37

WNDR3700 transition of wifi to ath79 did not implement the antenna group adjustments that were on the original ar71xx WNDR3700 implementation. The goal in 2018 was to get the wifi to work at all, so the antenna part was overlooked at that time.

See discussion in :
https://forum.openwrt.org/t/porting-guide-ar71xx-to-ath79/13013/995?u=hnyman

https://forum.openwrt.org/t/porting-guide-ar71xx-to-ath79/13013/1001?u=hnyman

Ar71xx code:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-wndr3700.c;h=b9132fc363d71027c47e1728215cc0bb571ef560;hb=HEAD#l158

 158         /* 2.4 GHz uses the first fixed antenna group (1, 0, 1, 0) */
 159         ap9x_pci_setup_wmac_gpio(0, (0xf << 6), (0xa << 6));
 160 
 161         /* 5 GHz uses the second fixed antenna group (0, 1, 1, 0) */
 162         ap9x_pci_setup_wmac_gpio(1, (0xf << 6), (0x6 << 6));
 163 

Data from live router:

Looks like the values do not get set automatically in ath79, but are set by that old routine in ar71xx. Below are current examples of both.

 OpenWrt SNAPSHOT, r13068-71d5a0d92b   (ath79)
 -----------------------------------------------------
root@router2:~# cat /sys/kernel/debug/ieee80211/phy*/ath9k/gpio_mask
0
0
root@router2:~# cat /sys/kernel/debug/ieee80211/phy*/ath9k/gpio_val
0
0

 OpenWrt SNAPSHOT, r13125-d9ff499671   (ar71xx)
 -----------------------------------------------------
root@router2:~# cat /sys/kernel/debug/ieee80211/phy*/ath9k/gpio_mask
960
960
root@router2:~# cat /sys/kernel/debug/ieee80211/phy*/ath9k/gpio_val
640
384

I have considered adding lines to write those values into GPIO into the firmware extractions routine in /etc/hotplug.d/firmware/10-ath9k-eeprom

Project Manager
Christian Lamparter commented on 07.06.2020 21:24

Hello,

I've recently retired a WNDR3700v2, so I can play around with it. I've attached a patch that I think sets the GPIOs we want (EDIT: no, it needs more work). I'm not sure what these GPIO are controlling exactly (it's more likely be the power amplifiers, but I really don't know).

At least in my test the 2.4GHz Throughput (on a 1x1:1 HT20) test improved considerably.

It went from:


Server listening on 5201


Accepted connection from 192.168.8.226, port 46720
[ 5] local 192.168.8.7 port 5201 connected to 192.168.8.226 port 46722
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 3.27 MBytes 27.4 Mbits/sec 8 133 KBytes
[ 5] 1.00-2.00 sec 2.79 MBytes 23.4 Mbits/sec 1 112 KBytes
[ 5] 2.00-3.00 sec 2.73 MBytes 22.9 Mbits/sec 0 127 KBytes
[ 5] 3.00-4.00 sec 2.49 MBytes 20.9 Mbits/sec 0 140 KBytes
[ 5] 4.00-5.00 sec 2.43 MBytes 20.4 Mbits/sec 1 112 KBytes
[ 5] 5.00-6.00 sec 2.85 MBytes 23.9 Mbits/sec 0 136 KBytes
[ 5] 6.00-7.00 sec 2.32 MBytes 19.4 Mbits/sec 0 147 KBytes
[ 5] 7.00-8.00 sec 2.14 MBytes 17.9 Mbits/sec 1 113 KBytes
[ 5] 8.00-9.00 sec 2.79 MBytes 23.4 Mbits/sec 0 126 KBytes
[ 5] 9.00-10.00 sec 2.73 MBytes 22.9 Mbits/sec 1 103 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 26.5 MBytes 22.2 Mbits/sec 12 sender


to:


Server listening on 5201


Accepted connection from 192.168.8.226, port 46732
[ 5] local 192.168.8.7 port 5201 connected to 192.168.8.226 port 46734
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 4.89 MBytes 41.0 Mbits/sec
[ 5] 1.00-2.00 sec 5.26 MBytes 44.1 Mbits/sec
[ 5] 2.00-3.00 sec 5.43 MBytes 45.5 Mbits/sec
[ 5] 3.00-4.00 sec 5.15 MBytes 43.2 Mbits/sec
[ 5] 4.00-5.00 sec 5.27 MBytes 44.2 Mbits/sec
[ 5] 5.00-6.00 sec 5.40 MBytes 45.3 Mbits/sec
[ 5] 6.00-7.00 sec 5.10 MBytes 42.8 Mbits/sec
[ 5] 7.00-8.00 sec 5.32 MBytes 44.6 Mbits/sec
[ 5] 8.00-9.00 sec 5.38 MBytes 45.2 Mbits/sec
[ 5] 9.00-10.00 sec 5.34 MBytes 44.8 Mbits/sec
[ 5] 10.00-10.03 sec 182 KBytes 45.0 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.03 sec 52.7 MBytes 44.1 Mbits/sec receiver


Server listening on 5201


Hannu, do you want to pursue the userspace gpio-switch implementation, or would you
support this gpio-hog solution? (I've queued the patch in my tree and it'll be there for the time.)

(I've left the "off" gpios alone. usually they don't need initializing in order to stay off. But if it turns out this isn't enough and they need to be set to off, I can of course add them too.)

EDIT: looks like the patch needs more work.

Hannu Nyman commented on 07.06.2020 21:42

Sounds great that you have figured out a DTS based solution.
Much better than having to implement a kludge in userspace.

Good enough for me ;-)

Hannu Nyman commented on 08.06.2020 15:57

I noticed that you have now written a comments that the patch needs more work.

I tested the first patch in a new master build form 3700v2, and noticed no significant impact. The gpio values were not changed, so I am not sure if the patch worked at all.

I tested setting the gpio values in the eeprom hotplug script, but that worked only when there was no firmware from previous boots (so that the script got run). However, that mask/val setting did actually help especially with 2.4 GHz. (I tested external internet connectivity speed, so my 5 Ghz test was limited by my line speed). But setting the gpio values before the driver loads, does indeed help. If that userspace solution would be used, we would need to figure out a script run early enough in the boot process and regardless of firmware extract already extracted, so that the driver would have the gpio values there when it starts. Might need to be preinit ???

Project Manager
Christian Lamparter commented on 08.06.2020 17:14

No, it was my fault just going by the comment and not the code.

The code sets gpios 6-9 and not 0-3. I've fixed that, but I'm now really confused what's the 5GHz and what's the 2GHz chip. It seems either they've been switched or the comment about them is wrong...?! Figuring this out will take some time.

as for the gpio_vals & mask in /sys/kernel/debug/ieee80211/phyX/ath9k. The "set" values from gpio-hogs will not show up there. You can confirm this with the help of the 2.4Ghz and 5GHz LEDs on the device. These are connected to the AR9220's GPIOs (GPIO5) as the "power amplifiers" and you can easily control them through sysfs /sys/class/leds/.. interface.
Give it a try: toggle their brightness on and off and watch the gpio_val & mask. Their values "0" will not change. But the LED will go on and off.

Hannu Nyman commented on 08.06.2020 17:53

Christian,

I tested your second patch and I got mixed results.

I tested external internet speed with my PC, so this is not just about wifi, but gives still some insight. (PC connected via wifi to WNDR3700v2 10 meters away, from there wired to R7800 to internet. My ISP speed limits upload, so only download is interesting.

I also used my tablet to monitor signal strength.

ar71xx build a week ago:

2.4 GHz: download 47 Mb/s, signal -55 dB
5 GHz: download 140 Mb, signal -75

ath79 basic:

2.4 GHz: download 30 Mb/s, signal -70 dB
5 GHz: download 135 Mb, signal -75

ath79 your first path: no impact

ath79 your second patch:

2.4 GHz: download 80 Mb/s, signal -55 dB   *** great improvement
5 GHz: download 150 Mb, signal -75

I thought that you may have the phys wrong, as "ath9k0: wifi@0,11" should be 2.4 GHz. So I tested with your changes swapped

ath79 patch swapped:

2.4 GHz: download 40 Mb/s, signal -55 dB
5 GHz: download 140 Mb, signal -75

Some improvement, but not much (despite good 2.4 signal strength)

Pretty baffled at this point.

That made me wonder if the original ar71xx gpio values are right...

I looked further into into history to find out where that code actually originates. And this is it:
https://git.openwrt.org/?p=openwrt/svn-archive/openwrt.git;a=commitdiff;h=21beca0e326deaf5c55a8357e86bb39c28b437e8

And even more original first version:
https://git.openwrt.org/?p=openwrt/svn-archive/openwrt.git;a=commitdiff;h=aef61b273db555a25a6e6c48e34dfae47f13f7d3

So, no explanation for the values, but they originate from 2010-2011.

Hopefully you can figure out something.

Hannu Nyman commented on 08.06.2020 17:57
I'm now really confused what's the 5GHz and what's the 2GHz chip. It seems either they've been switched or the comment about them is wrong...?

I have noticed (when I did the original wifi ath79 import in 2018), that sometimes, rarely, the phy0 and phy1 get detected in wrong order.

I mentioned that in
https://github.com/openwrt/openwrt/pull/1284

phy0 should be 2.4 GHZ as far as I know based on the old code.
And it usually is.

Project Manager
Christian Lamparter commented on 08.06.2020 18:40
ath79 your second patch:
2.4 GHz: download 80 Mb/s, signal -55 dB   *** great improvement
5 GHz: download 150 Mb, signal -75

I'm also getting those values with iperf3 as well when the wndr3700 is just the AP...
but as you mention:

I thought that you may have the phys wrong, as "ath9k0: wifi@0,11" should be 2.4 GHz. So tested with your changes swapped
ath79 patch swapped:
2.4 GHz: download 40 Mb/s, signal -55 dB
5 GHz: download 140 Mb, signal -75

Some improvement, but not much (despite good 2.4 signal strength)

yes, this broke my brain. I went over the code and notes I could find several times... And I think the version of the patch I've attached "should" be the one where "everything" is now correct. Can you check if that's indeed the version that performs the best?

That made me wonder if the original ar71xx gpio values are right...
I looked further into into history to find out where that code actually originates. And this is it:
https://git.openwrt.org/?p=openwrt/svn-archive/openwrt.git;a=commitdiff;h=21beca0e326deaf5c55a8357e86bb39c28b437e8
So, no explanation for the values, but they originate from 2010-2011.

The explanation is likely hidden in the Atheros umac/madwifi blob of that device.
It would probably be faster to trace the paths of those GPIOs around the board and
see where they are leading to.

Note:
The reason why I have this "hunch" and named the line "power amplifier" is because of Netgear's own marketing. In there is a dedicated bullet-point: "High-end power amplifiers are included in the Wi-Fi Radio electronics".

Hannu Nyman commented on 08.06.2020 20:39

I googled further and found this interesting old bug report with lots of relevant discussion:

"wndr3700 weak signal rx/tx":
https://dev.archive.openwrt.org/ticket/6533.html

Especially comment 13 from Mark Mentovai:
https://dev.archive.openwrt.org/ticket/6533.html#comment:13

I (partially) disassembled the stock firmware’s WNDR3700-V1-0-4-68-GPL/madwifi-11n.git/lib/ath_dev.ko and found that it uses the following settings for AR9220/AR9223 GPIOs (6, 7, 8, 9) when enable_auto_switch_antenna is 0:
    fixed_antenna_group 1, (0, 1, 0, 1)
    fixed_antenna_group 2, (0, 1, 1, 0)
    fixed_antenna_group 3, (1, 0, 0, 1)
    fixed_antenna_group 4, (1, 0, 1, 0) 


With enable_auto_switch_antenna 1, selection is handled by the driver. I haven’t fully disassembled that routine yet.
>
> The stock firmware’s default is to use fixed_antenna_group 1 for the 2.4GHz band, and fixed_antenna_group 2 for the 5GHz band.

That is likely the original source of the current values. And based on dicussion & some comments on some of the relevant commits, there has also been bigendian/little-endian confusion on how to interpret 0 1 0 1 (or 1 0 1 0 as in the current ar71xx code).

Project Manager
Christian Lamparter commented on 09.06.2020 13:32

Ok, thanks :)

So this hunch about "power amplifiers enable" was all wrong. There really are antennae demuxer chips on the boards.

More interestingly, looking at the PCBs [ front back] of the WNDR3700v1 it came with eight independent antennae printed on the circuit board (unconvinced? look at the silk-screen there are labels from ANT_A1 to ANT_A8!)

The wndr3700v2 (and likely wndr3800/wndrmacv1?) have a different board and there are just the four 2.4Ghz printed circuit antennae left, whereas the 5GHz is handled by the two rayspan patch antennae.

Now we can decide. Should we continue with ar71xx's way of just doing this the same way or extend this so it can be (mis-)configured properly?

Sadly, I don't think we can just use the userspace gpio-switch without some overhaul.
The reason is that as Hannu mentioned, phy0 and phy1 can switch places between (re-)boots. Otherwise it would just need editing in generic/base-files/etc/board.d/03_gpio_switches

netgear,wndr3700)
   ucidef_add_gpio_switch "wifi1_ant_1" "2.4GHz Chain 1 Internal Antenna" "498"
   ucidef_add_gpio_switch "wifi1_ant_2" "2.4GHz Chain 1 Internal Antenna" "499" "1"
   ucidef_add_gpio_switch "wifi1_ant_3" "2.4GHz Chain 2 Internal Antenna" "500"
   ucidef_add_gpio_switch "wifi1_ant_4" "2.4GHz Chain 2 Internal Antenna" "501" "1"

   ucidef_add_gpio_switch "wifi2_ant_1" "5GHz Chain 1 Internal Antenna" "508"
   ucidef_add_gpio_switch "wifi2_ant_2" "5GHz Chain 1 Internal Antenna" "509" "1"
   ucidef_add_gpio_switch "wifi2_ant_3" "5GHz Chain 2 Internal Antenna" "510" "1"
   ucidef_add_gpio_switch "wifi2_ant_4" "5GHz Chain 2 Internal Antenna" "511"
   ;;
netgear,wndr3700-v2|\
netgear,wndr3800|\
netgear,wndr3800ch)
   ucidef_add_gpio_switch "wifi1_ant_1" "2.4GHz Chain 1 Internal Antenna" "498"
   ucidef_add_gpio_switch "wifi1_ant_2" "2.4GHz Chain 1 Internal Antenna" "499" "1"
   ucidef_add_gpio_switch "wifi1_ant_3" "2.4GHz Chain 2 Internal Antenna" "500"
   ucidef_add_gpio_switch "wifi1_ant_4" "2.4GHz Chain 2 Internal Antenna" "501" "1"
 
   # Could be skipped, if it wasn't for the 2.4GHz an 5GHz Radio switching places...
   ucidef_add_gpio_switch "wifi2_ant_1" "5GHz Chain 1 Internal Antenna" "508"
   ucidef_add_gpio_switch "wifi2_ant_2" "5GHz Chain 1 Internal Antenna" "509" "1"
   ucidef_add_gpio_switch "wifi2_ant_3" "5GHz Chain 2 Internal Antenna" "510" "1"
   ucidef_add_gpio_switch "wifi2_ant_4" "5GHz Chain 2 Internal Antenna" "511"
   ;;
Hannu Nyman commented on 09.06.2020 14:39
WNDR3700v1 it came with eight independent antennae printed on the circuit board (unconvinced? look at the silk-screen there are labels from ANT_A1 to ANT_A8!)
>
> The wndr3700v2 (and likely wndr3800/wndrmacv1?) have a different board and there are just the four 2.4Ghz printed circuit antennae left, whereas the 5GHz is handled by the two rayspan patch antennae.

Your observation that the circuit board differs from v1 to v2/3800 regarding the antenna count and type, made me first to think that we should handle the 3700v1 differently, as likely that 0101/0110 matches the original code from 2010 for v1. 3700v2 with a different board came later, a different board would explain why our changes had no impact on 5 GHz signal with the 3700v2 that I tested with.

Possibly v2 would need a different antenna group config, as the circuit board has changed. Possibly Netgear has adjusted for that in OEM firmware. We would be extremely lucky if the v2 antennas would still match the v1 grouping logic.

But then I searched the FCC database, and found
https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1354315 (FCC ID PY308300092 docs dated 10/05/2010)
that shows that for v2 (and 37800?) there is no selection of printed antennas any more, but instead just two connections for patch antennas.

So, I think that for 5GHz there is no actual difference for v2/3800 in what we config, but for v1 there might be, so sticking to the existing v1 values 0110 might be right and possibly that makes no difference for v2/3800.

Project Manager
Christian Lamparter commented on 09.06.2020 16:57
So, I think that for 5GHz there is no actual difference for v2/3800 in what we config, but for v1 there might be, so sticking to the existing v1 values 0110 might be right and possibly that makes no difference for v2/3800.

I've fixed my mistakes in the "ucidef_add_gpio_switch" code above so it works (if someone wants to play with it... however in that case please revert the patch with the gpio-hogs).

I played around (EDIT: on my WNDR3700v2, not a v1 as the reporter has) with the combinations 0,0,0,0 to 1,1,1,1 on the 5GHz and it didn't change the throughput. The Antennae on the 5GHz PHY really do seem to be permanently attached to the RF, so it makes sense that changing the GPIOs there will do nothing since they are probably not even wired up (the what-seem-to-be-demux chips that are present on the WNDR3700v1 on the 5GHz are missing on the v2).

As for changing the GPIO Values on-the-fly with the 2.4GHz PHY while it's serving data:
This always caused the speed drop and never come back (I think the PHY would need to re-calibrate and do ANI after the antenna being switched). So, this is probably a "set once" and keep it that way deal.

Hannu Nyman commented on 09.06.2020 17:12

Funny, i made pretty similar test this evening:

I compiled version with gpio values set for both radios 0101, 0110, 1001, 1010 in DTS. And I also tested without any antenna setting. Device used was WNDR3700v2.

I tested with my PC from 10 meters away (two light walls in between) and my tablet both at the office next to my PC plus about 4 meters away from router.

For 5 GHz there was no real difference.

For 2,4 GHZ:
* any combination of antennas increased the signal strength by 10-15 dB compared to the current "no antenna setting" situation.
* There was no clear winner among the antenna combinations. All antenna combinations increased speed (DSLreports test) at PC from 30 Mb/s to 45-70 Mb/s. For my own unit, the combination 0110 seemed to perform best, but that is likely just depending on the positioning of the device and objects between device and PC.

Looking at the FCC pictures, the 4 printed antennas are on the device pretty similarly, there is likely no real general winner for all users, but it will depend on many things.

(strangely my tablet got better 2.4 GHz results at the office 10 meters away than from 4 meters away. When antennas were not set, the situation was reversed and 4 meters away produced better speed, as expected. That was pretty much the only anomaly.)

I think that you could commit your current version. It will bring clear benefits for 2.4 GHz users in any case, might help with 5 GHz on v1 and should not hurt 5GHz users on v2/3800.

(And please also backport that to 19.07)

Project Manager
Christian Lamparter commented on 09.06.2020 20:14

Pushed, I'll follow up with the 19.07 version on the weekend (I don't think a 19.07 release is imminent, or is it?).

In the end, I put the wndr3700(v1) portion (5GHz Radio gpio mux settings) into the device specific wndr3700.dts file... while the shared 2.4 GHz radio setting stayed because it looks like every device needs it.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing