I mean Facetime calls without interuption while I move around in house and change AP's. Phones (I only have iPhones and iPads) tend to roam worse and "hang" on 2.4GHz AP's for much longer. They just snap on 5GHz 802.11ac AP's quicker.
SSID's and passwords must be the same. I have four Archer C7's acting as dumb AP's and it works very well. Do not hide SSID's.
I noticed that tendency to "latch" onto weak AP's is lower when "legacy b rates" is not enabled. I have no clue what it does except that it hurts my roaming.
Legacy b rates enables 802.11b rates including rates down to 1Mbps. This allows your device to remain connected at greater distances because the lower speed rates will operate over much longer distances (at low signal to noise). This means your device will tend to be able to hang on distant nodes much longer, at the expense of massive reductions in throughput for all devices.
The same issue applies to 5GHz, it has shorter range, and hence you will more rapidly roam between the stations. You can handle this by either adjusting down the power of the 2.4GHz radios, or adjusting the allowed rates to even higher rates... causing your device to disconnect more quickly.
And how quickly do you move? Have you made a test where you almost run?
But it sounds a bit as if e.g. WiFi calling with your iPhones could behave less optimal, and that's what I can observe.
I also find my OpenWRT Archer C7 V5 very enjoyable as an AP which manages my VLANs and, for now, runs minidlna. My OpenWRT R6120 also behaves well, within the range of its specification.
Would you be willing to share some details of your configuration? I re-read Why You Should Disable Lower Legacy Data Rates and it suggests setting 12 Mbit/s as the lowest basic rate, but what are you using? And how exactly is that configured in /etc/config/wireless?
I have come to the conclusion that I'd like to try it, but I'm not even sure how I would identify a problem in my configuration. I'd find it helpful if you could provide some details.
It seems like the "basic_rate" parameter lists rates that clients must support (all of them) in order to connect. "supported_rates" lists rates that clients may use after they've associated. So supported_rates must list all the basic rates, but can list more rates as well.
The 802.11a standard for 5 GHz never included "b" type modulation and rates. The minimum rate on 5 GHz has always been 6 Mbps, the same as the lowest "g" modulation. It is unclear what if anything the legacy_rates setting could do on 5 GHz.
also: the lowest basic_rate is used for multicast/broadcast (arp/dhcp) aswell as for the beacons. legacy_rates 0 removes the 11b rates from basic_rate but not from supported_rates so a client can make its roaming decision based on the signal strength of the beacon/basic_rate but is able to use the lower data-rates as a fallback.
i am unclear what the implications of restraining both are.
I read somewhere that beacons are supposed to be sent at the lowest basic rate, but that multicast/broadcast could be sent at the highest basic rate... I don't think this is actually what's done though, my impression is the lowest basic rate is what's actually used for multicast.
When I disable everything below 12Mbps things work fine on my home network, and clients roam a little more quickly. This is useful because when running WRT32X as my APs I can't control the signal strength (it's locked in the hardware to the max output) so by controlling the rates it forces my devices to move to their closest AP more quickly, otherwise they tend to stay locked even out to about the middle of my front yard.
Do you know what legacy_rates 0 would do at 5 GHz?
@ client roaming decision, playing with these settings has the objective odf making the client roam earlier, so enforcing a stronger broadcast while allowing a weaker transmission for the existing connection will, if in doubt, only support the STA in sticking longer to the AP it's already connected to.
that's right it's only the core n rates that go in there, higher rates are described by the extended MCS schemes that the two endpoints can still negotiate.
I made a mistake there. I mentioned 802.11n based on the data rates in your list, but it's really the 802.11g and 802.11a list of rates.
And I'm not so sure about your list of basic rates. I read that only 6, 12 and 24 Mbit/s must be implemented, so the question is, does your AP now excluide clients which don't implement 18, 36, 48 and 54.
I guess I'll try to configure basic rates 12 and 24, and the supported g / a rates beginning with 12, and see what happens.
Yes, I do think my config would exclude clients that don't implement 18,36,48, 54 but that seems to be exactly zero clients in my experience... either chipsets handle all the g, all the n, all the ac rates etc... no one implements just a weird list of just a few rates.
Is there evidence that disallowing low 802.11a/g rates leads to earlier 802.11n/ac roaming?
First, Why You Should Disable Lower Legacy Data Rates is about avoiding non-OFDM (aka 802.11b) rates due to their modulation (which can be achieved by option legacy_rates '0'). Second, 802.11n/ac specify rates as low as 6.5 Mbit/s. Third, I see my STAs negotiate and use these low rates even when I disable "basic" rates below 12 Mbit/s.
Another observation here is that my dual band 802.11n STAs make pretty suboptimal roaming decisions. I limited 2.4 GHz chans to 20 MHz due to the band being crowded, and they won't prefer 5 GHz although those are 80 MHz channels, of which they could use 40 MHz, if they chose to. Only one of my STAs is configurable in this regard. Since (I think) broadcasts contain speed information, I'm really not sure why these STAs behave like this.
My counter question is, do you ever see rates above 54 Mbit/s with your config?
From my observations, I currently believe only one statement can be true:
That either STA and AP can negotiate any 802.11n/ac MCS rate independently of the "core" rates, and then it's okay for them to negotiate 6.5 in accordance with 802.11n/ac regardless of supported_rates'. In this case, it's impossible to support roaming by disallowing low "core" rates in supported_rates`.
Or that supported_rates needs to list all allowed rates, 802.11a/g "core" and negotiated 802.11n/ac MCS rates. In this case, it's a rather long list and you won't see rates above 54 Mbit/s with your current config.
You wrote that "only the core n rates that go in there" (supported_rates) and that "higher rates are described by the extended MCS schemes that the two endpoints can still negotiate". But unfortunately, there are also lower rates which can be negotiated.
If that's the case then what is the exact logic which causes all negotiated 802.11n/ac rates to be higher than, well, I guess the lowest supported "core" rate?
I haven't finished testing all scenarios but I had strange effects and it took me a lot of time to try and isolate the config option which appeared to cause them. I even posted a wront response here. At some point in time, I had to postpone tests and get the system back to a reasonable level of WAF oriented operation.
BTW, which OpenWRT version do you have installed? Interestingly, the semantics of config options seems to change sometimes...
Sure, absolutely. Right now I've got clients connected to one of my APs at 150Mbps and 135Mbps modulation. I routinely get 100Mbps actual goodput to my phone in speed tests.
However, I do see that I have one device negotiated at 6.5Mbps MCS 0 so apparently you're right that you can't force devices to use 12Mbps or more. That being said, the beacons will still be sent at the lowest basic_rate and if the device can't hear the beacon it will be forced to switch, so there's still a good reason to make both basic_rates and supported_rates start at 12Mbps if you're trying to force earlier roaming.
If you want to make the 5Ghz and 2.4Ghz bands at a more even level, and you can't adjust the power output, you might even up the basic and supported rates for 2.4Ghz higher than the 5Ghz. Say start at 18 Mbps or 24, for the 2.4 Ghz radios.
Ah yes, that's the link I was missing. Thank you for pointing this out.
Still, that's exactly what legacy_rates '0' is supposed to achieve.
When I add basic_rate and supported_rates to the 5 GHz radio of the Archer C7 v5 with OpenWRT 18.06.2, one of the dual band 802.11n STAs (that ha a bitten fruit on it) refuses to prefer 5 GHz, which it usually does very quickly.
raise the 2.4 GHz min basic rate even higher than on 5ghz. see what happens
also the reason to raise the supported rates is to avoid low rate stations using up airtime. whereas the basic rates is to force beacons to go at higher rates and therefore force earlier roaming. they play slightly different roles
