Access Point Client Roaming / Ethernet Backhaul

Yes, you should definitely run in N only mode. The signal strength based client dropping is also useful. It lets the AP make use of its own info about how loud the client is. There's nothing "purer" about making the client do the work, particularly for devices with basically braindead client algorithms.

For OpenWrt check out the basic rates and supported rates parameters in the wireless config, see the wiki for details. To get started in Luci you can go to the SSID and click advanced and deselect the allow legacy rates, then in the wireless config you can cut out even a few of the remaining lower speed rates.

I was playing with a TP TL-MR3020 V1.9 which was collecting some dust, installed OpenWRT, looks good. But it's not suitable as my target device; I just conducted some feasibility tests.

Now I found out that the new device I have on my mind would use the ath10k driver which always reports a fixed TX rate and I'm wondering whether that would affect the logic of not allowing low transfer rates?

I was seeing over 500 mbps throughput in both directions on QCA4019 and QCA9888 yesterday using -ct drivers, so I’d be surprised if there is a general driver issue.

Thank you for sharing. In fact, I saw a review of a QCA8075 (I think) based product claiming it transmits only 6 mbps and I believe the reviewer was misled by the mentioned driver bug. According to the ath10k page, information in /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats should be correct, but somwhere else, the driver indicates a wrong rate of 6 mbps regardless of the actual tx rate (amd I'm not even sure where the wrong reporting can be found).

In my scenario, I want to follow the suggestion of disabling low rates, for which the best place would probably be basic_rate and supported_rates in /etc/config/wireless. So since ath10k somewhere indicates the wrong rate, I was wondering whether that should affect my buying decision or not.

OpenWRT's LUCI, at least for 18.06.2 and later, offers an advanced setting "distance optimization" that you didn't mention. Is it also worth testing whether it is helpful?

I'm asking because while I guess that STA and AP will not "negotiate" a "distance" but rather have their own ideas of how well they receive the other party's signal, I'm still looking for a mechanism where both parties actually "agree" on their connection's quality. (I'm aware that "distance" is derived from the signal, but at least the value is also shown in wifi analyzer apps.)

The distance setting is actively harmful, unless you know exactly what you're doing and need it for really long distance directed links (measured in multiple hundreds of metres or dozens of kilometres). It's best to leave it alone (unset) for 'normal' uses.

1 Like

same goes for meddling with supported_rates, n-only wifi and band-/ap-steering
will probably make it worse.

what is the symptom of the harmfulness of distance optimization? I've set mine to 60m on wrt32x does it even do anything on those drivers?

1 Like

Very often subtile issues, failing to connect, multiple re-auth attempts, packet loss, etc.

1 Like

I assume as the number is increased the problems should become less problematic? like 200m would be less likely to cause problems than 100m and if you make it 10m it'd be very problematic

Yes, although the clients also need to accept what they're presented with (that's why I referred to "long distance directed links" - as this means both peers are tuned the same way, without random clients being part of the story).

This is the opposite of what was suggested earlier in this thread, and also in Why You Should Disable Lower Legacy Data Rates which I already referred to.

Could it be possible that it depends on what one wants to fix? Do you have some links? Could you share some insights?

What does the feature even do? I would assume it's similar to the ASUS Roaming Assistant which I already mentioned, though one is set in dB and one in "distance".

I played with it and yes, clients are e.g. not so amused when the AP disconnects them and they don't have what they see as a better alternative. Actually that's something one can expect. However, e.g. Disconnect WiFi STA (clients) based on their signal levels (also mentioned in that post) provides some mechanisms to avoid problems in some ugly situations.

It mostly prolongs timeouts, to the levels necessary at multi-kilometre links.

yes. the point beeing that defaults are usually fine unless you have a problem.

I think the distance optimization controls timing. if you have a multi km link the AP needs to wait for ACKs due to the speed of light. if you set it to say 100m then anyone beyond that distance will have trouble connecting because they won't ack packets fast enough. this is a way you can keep people from connecting at longer distances. for example I have an unencrypted guest Network and want to keep people across the street or in neighboring houses off the net.

but power saving might also muck with timeouts for example and so too short of a distance might cause mobile phones to fail to maintain a connection or some similar issues... I'll have to play with it and will report back. also remember it's total propagation path length... so if you are connecting via signals reflecting off walls, down a hall and through doors the propagation path might be considerably longer than straight line distance.

If that's the case then it's not the right option for my scenario...


I have been doing this stuff with four AP's.

My findings:

  1. 802.11r was somewhat hard to set up (at least with 17.xx LEDE, perhaps better now).
  2. 5GHz roam MUCH better than 2.4GHz.
  3. 5GHz with legacy b-rates disabled roams even better.
  4. Apple stuff roams quite well even without 802.11r...just sharing SSID and pw between AP's.
  5. You must spread out AP's to different channels or it will get messy in-between border areas.

Thanks for sharing.

  • Do you hide SSIDs or not?
  • To me, it looks as if my dual band STAs lose 5 GHz AP connectivity, switch to 2.4 at the next, then "recover" to 5 only after some time of good signal strength. But I have to make more tests.
  • The Nintendo Switch does not seem to roam, atleast not with hidden SSIDs.

Hidden SSIDs help keep picker menus cleaner, but don’t add significant security, in my opinion. As you’ve noted some clients aren’t as robust with hidden SSIDs.