I am now using Wi-Fi-as-wan. Though it's less desirable, I've been using two SSIDs/networks on my 5GHz radio. One configured as the STA that used for my WWAN. The other as an AP for my own devices.
When I set this up a few days ago, there was no issue. It worked beautifully. In fact, the performance was far better than I expected. But this morning the upstream WiFi changed channel (from 40 to 60), and since then nothing I do can get the radio to come up as both STA and AP.
I expect it has to do with DFS/TPC, since channel 40 in Canada doesn't need that and 60 does. I just don't know how to poke the AP into working.
This is on a BPI-R3 which has, essentially, a pair of 4x4 mt7915s at 2.4 & 5GHz.
Here's the kernel log when the radio is reset:
[ 9425.248011] br-lan: port 6(phy1-ap0) entered disabled state
[ 9473.549120] device phy1-ap0 left promiscuous mode
[ 9473.553945] br-lan: port 6(phy1-ap0) entered disabled state
[ 9474.794200] br-lan: port 6(phy1-ap0) entered blocking state
[ 9474.799823] br-lan: port 6(phy1-ap0) entered disabled state
[ 9474.805612] device phy1-ap0 entered promiscuous mode
[ 9474.810755] br-lan: port 6(phy1-ap0) entered blocking state
[ 9474.816323] br-lan: port 6(phy1-ap0) entered forwarding state
[ 9474.822622] br-lan: port 6(phy1-ap0) entered disabled state
[ 9554.816446] phy1-sta0: authenticate with xx:xx:xx:xx:xx:xx
[ 9554.840513] phy1-sta0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[ 9554.850157] phy1-sta0: authenticated
[ 9554.868351] phy1-sta0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[ 9554.878246] phy1-sta0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x1011 status=0 aid=14)
[ 9554.896042] phy1-sta0: associated
[ 9555.028666] phy1-sta0: Limiting TX power to 24 (24 - 0) dBm as advertised by xx:xx:xx:xx:xx:xx
[ 9555.028792] IPv6: ADDRCONF(NETDEV_CHANGE): phy1-sta0: link becomes ready
You can't poke it...
Typically the radio must listen for a period of time to ensure that there is no radar and then it can come up. And it will obviously go down if it detects a radar hit (and/or if the AP upstream goes down).
Your channel selection should be set to auto, though... this way it will scan for the SSID and connect if it is available. The AP mode must be on the same channel, so it is possible that the sta mode may connect but the AP may stay down for a bit until it is deemed safe to bring it up.
Right. The scan time elapses and the STA connects. But no matter how long I wait, the the AP never comes up.
If I use auto channel, then amusingly the automatic channel selection occurs on the AP before the STA comes up, and it tries to select a different channel from the one the STA uses. From syslog:
If you can use the 2.4Ghz simultaneously - it is better to use the AP over a different radio. If the target network is present, the AP mode will start only after the STA mode is up. There could be some additional script to disable the STA mode if you have a backup connection for example. There are different channel widths and power levels over the 5GHz band, so everything should be on auto if expecting the channel to change.
The wifi radio firmware and/or the kernel/driver could contain more limited outdated copy of these.There could be also hardware limit lower than the regulatory one.
This one is related to a STA mode probe request issue.
Agreed. But none of my devices have 2.4GHz AX, which limits their bandwidth to about 5MB/s. I need the 5GHz side for the bandwidth. I also want to figure out what's wrong, because this should workl. If it's an issue with snapshot or my firmware, for example, I'd like to identify this.
I thought so too, but as I mentioned, when upstream is on a DFS channel, putting my device's 5GHz radio on auto-channel causes a delay in the STA connecting that's long enough that the AP completes auto-channel-selection before the STA connects. I suspect this is because the AP logic wants to do ACS before it decides whether or not to do a DFS listen. This places the radio's STA and AP internally on different channels and I get errors about a wrong channel coupling in the syslog.
The only way I don't get those errors is if I set the channel explicitly.
I think the default behaviour is to establish the STA and only then to attempt the AP. So not having the STA mode stable will delay it further (possibly breaking and starting over the DFS). When having STA mode, the channel setting is likely to be ignored, but can possibly speed the DFS/radar detection if set. It could be also some known issue: https://github.com/openwrt/openwrt/pull/4904
With the "iw" command you can check the current regulatory/hardware power limits. The far end if not managed by you may disobey the regulatory requirements, skipping the radar detection. For some countries fixing the power level (TPC disabled ) should result in theory 3dB lower limits. If you are over the power/bandwidth limit the radio may not start. Both APs will see each other, so the remote AP may select even a bad channel, since the current is already occupied. If having radars in the 5GHz band, the chance of picking up a pulse raises when the radio wants to occupy more channels.
If only 40-50Mbps are usable over the 2.4 band you are possibly using only 1 TX antenna on a 20MHz and N on channel with some interference. Try to select it manually. Some low-end wi-fi cards are relying only on one active antenna and AC/AX over the 5Ghz band for adequate speed and will have poor performance over the 2.4 Ghz band.
Using the same radio as STA+AP is likely to reduce the speed in half of the remote AP. You may check this with a cable connection. You may check the exact markings over the radio chips - some do support both 2.4 and 5GHz. The M.2 slot could be possibly used (via an adapter) to install an additional PCIe WiFi card.
My take from reading this is it is verifies that issues in hostapd require the channel to be set explicitly. However it doesn't seem to explain why, when the channel IS set, it's not working on DFS channels.
At this point, I'm not really trying to use AP+STA on one radio as a final solution. I have other solutions. Now I'm just trying to figure out why AP+STA isn't working and determine the scope of the issue.
Actually, IIUC, it's actually the opposite. The AP mode must be set to auto. It is the sta-mode connection (and the upstream AP's channel) that will dictate the channel of the downstream AP when using a single radio. This is because the it is not practical for the AP to be on a different channel than the AP mode (not sure if it even possible to configure the wifi radio to toggle between the two rapidly).