[Dodge DeBoulet]

TLDR; Occasional disconnects, disappearance of BSSID, glitches/frame drops streaming games but performance is excellent when it's not doing those things

After a couple of years sitting idle on a shelf in my cellar, I've returned my R9000 to service with the latest release of dd-wrt.

Its sole purpose is to support a Meta Quest 3 VR headset using SteamLink, Virtual Desktop and occasionally AirLink for PC-based VR apps/games.

The PC in the mix is pretty beefy; an AMD Ryzen 9 7950X3D with 64GB of RAM and an AMD RX7900XTX GPU. Storage is commensurately fast with Samsung 980 Pro NVMe drives. The PC is directly attached to the R9000's switch via Ethernet.

The R9000 is configured as an AP, with the WAN port disabled. The connection to the LAN is also via one of its LAN ports. I have the 2.4GHz and 60GHz radios disabled since they won't be used.

The headset is less than 15 feet from the R9000 at all times, with direct line-of-sight. There are no other access points in detectable range using the frequencies allocated to channel 100/UUU (+14). The headset sees a connection of 1733Mb/s.

On power-up, the headset will see the other APs in the house immediately, but it may take 15-30 seconds for the R9000's BSSID (boomerfi) to appear. Once connected, starting and playing PCVR games seems to go as expected, but at some point the symptoms described in the TLDR at the top will occur. Performance in some very graphically intensive games like Half-Life Alyx goes from stunningly good to completely disconnected, or at some times just a few frames dropped. When disconnected, the R9000's BSSID is not visible in the list of available APs, but appears 30-60 seconds later.

Is there anything screwy or stupid in my settings that might account for this? I've attached them to this post ... thanks for taking a look and I appreciate the help!

[dpp3530]

The channels you're using are in the DFS range. These channels are shared by weather radar. When the AP first starts up, there's a Channel Availablity Check that can take several minutes. If it doesn't find anything, then the BSSID appears. If it does, it blocks the channel for 30 minutes. See https://netbeez.net/blog/dfs-channels-wifi/ for details. There's also a good diagram here - https://metis.fi/en/2018/02/5ghz-channels/. Unfortunately, with VHT160 channels, they pretty much all hit the DFS range somewhere. If your client supports it, you could try VHT80+80.

It could be that the R9000 is picking up signals once in a while from a nearby weather radar, causing one or more channels to go inactive temporarily. This would seem to follow the symptoms you describe.

[Dodge DeBoulet]

Is it just weather radar, or does that include air traffic too? I live roughly 7 miles from an "executive airport" that used to be a military air station.

And I have "radar detection" turned off in settings ... does that not do what one might think it would do?

And if it does, could it be the airport itself that's interrupting my connection?

[ho1Aetoo]

It is not permitted to use the frequencies in the vicinity of airports with radar.

The FCC says this is taboo within a 25km radius

If there is a system nearby, it has so much power that it will certainly interfere with your router.

[egc]

Network mode: AC/N

Channel width: 80 Mhz

Are safer options.

Start with channel 36
If that works you can try other channels

[Dodge DeBoulet]

So I tried VHT80+80 Channel 52 with wireless channel 2 at 114. Extension channel is UU (+6). My Samsung phone couldn't see the access point at all, but my both my Quest 3 and Samsung tablet were able to connect using VHT80SGI.

At 866Mb/s things seem to be a bit better; there was still a very, very small bit of lagging but no dropouts. To be fair, though it often started off well at VHT160 but then suddenly drops out completely or turns to crap.

I've since gone back to VHT160 on channel 64 with the extension channel at LLL(-14) and AC/N Mixed enabled. A reasonably long session where I would normally have experienced some sort of lagging or frame dropping went flawlessly. I'm guessing that's because I'm outside of the active radar frequency range of 5570-5670Mhz (channels 116-132).

I'm curious as to why AC/N would improve matters. I don't care about compatibility with anything but the headset, and that connects with the network mode set specifically to AC.

And

[ho1Aetoo]

First of all, there are practically no devices that support VHT80+80.

And if you have any devices that support VHT80+80, you will need to configure it correctly.

https://wiki.dd-wrt.com/wiki/index.php/QCA_wireless_settings#Valid_VHT80.2B80_Channels:

I have created the list.

and as a small remark
in your case you would have to select 52+106+UU to avoid entering the radar range
or e.g. 36+155+UU in order not to fall into the DFS range

but there's a very high probability that you don't have any devices that support VHT80+80 anyway

[dpp3530]

I've also had issues where certain wireless cards, generally Broadcom or Railink based, won't connect to the AP with AC-only mode, but did with AC/N. They still connected at AC 866MHz. Other clients connected just fine. I also have different SSIDs on 2.4GHz and 5GHz, so any N clients (like my printer and Kindle) go to 2.4.

Note that I'm using VHT80 because I have three APs to account for dead spots in my house and didn't want overlap.