FS#3088 - Decreased WiFi range switching from ar71xx to ath79 on WNDR3700 #7917
Comments
|
luca91: My mistake: in line 4 of "steps to reproduce", the image should be openwrt-19.07.2-ath79-generic-netgear_wndr3700 |
|
adrianschmutzler: Edited ath9k->ath79 in the title and |
|
mamciek: 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. |
|
adrianschmutzler: 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. |
|
mamciek: 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). So I am just confirming that openwrt-19.07.3-ath79-generic-netgear_wndr3700v2-squashfs-sysupgrade.bin causes problems in my case. |
|
hnyman: 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/1001?u=hnyman
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
I have considered adding lines to write those values into GPIO into the firmware extractions routine in /etc/hotplug.d/firmware/10-ath9k-eeprom |
|
chunkeey: Hello, I've recently retired a WNDR3700v2, so I can play around with it. I've attached a patch that At least in my test the 2.4GHz Throughput (on a 1x1:1 HT20) test improved considerably. It went from: Server listening on 5201Accepted connection from 192.168.8.226, port 46720 [ ID] Interval Transfer Bitrate Retr
|
|
hnyman: Sounds great that you have figured out a DTS based solution. Good enough for me ;-) |
|
hnyman: 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 ??? |
|
chunkeey: 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. |
|
hnyman: 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: ath79 basic: ath79 your first path: no impact ath79 your second patch: 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: 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: And even more original first version: So, no explanation for the values, but they originate from 2010-2011. Hopefully you can figure out something. |
|
hnyman:
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 phy0 should be 2.4 GHZ as far as I know based on the old code. |
|
chunkeey:
I'm also getting those values with iperf3 as well when the wndr3700 is just the AP...
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?
The explanation is likely hidden in the Atheros umac/madwifi blob of that device. Note: |
|
hnyman: I googled further and found this interesting old bug report with lots of relevant discussion: "wndr3700 weak signal rx/tx": Especially comment 13 from Mark Mentovai:
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). |
|
chunkeey: 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 [ [[https://openwrt.org/_detail/media/netgear/wndr3700/wndr3700_pcb_top.jpg?id=toh%3Anetgear%3Awndr3700|front]] [[https://openwrt.org/_detail/media/netgear/wndr3700/wndr3700_pcb_bottom.jpg?id=toh%3Anetgear%3Awndr3700|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. netgear,wndr3700) netgear,wndr3700-v2| |
|
hnyman:
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 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. |
|
chunkeey:
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: |
|
hnyman: 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:
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) |
|
chunkeey: 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. |
luca91:
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:
The text was updated successfully, but these errors were encountered: