[Make-wifi-fast] mesh deployment with ath9k driver changes

Sat Jun 9 11:32:58 EDT 2018

Hello,

That's nice. You would probably get most of the benefits already if
you could manage to prune B/G rates. You're right in that pruning the
N rates is a different question. I think it is good enough already to
allow G >= 12Mb/s and N >= MCS-0. Using N rates by itself would also
enable all the benefits of LDPC, STBC, aggregation, (beam forming) and
other goodies your chipsets could offer, thereby freeing up your
spectrum some more.

legacy_rates=0 seems to be an alias for enabling all g-rates and
disabling b-rates:

https://github.com/lede-project/source/blob/69f544937f8498e856690f9809a016f0d7f5f68b/package/network/services/hostapd/files/hostapd.sh#L110

So this should be the way to go in your device section:

option hwmode g
option htmode HT20 # probably already set
option distance 450 # minimal coverage
option beacon_int 200 # power/bandwidth saving
option basic_rate '12000 24000'
option supported_rates '12000 18000 24000 36000 48000 54000'
... (some other options automatically generated)

I also add these to the interface section:

option isolate 1 # intra-BSS
option dtim_period 5 # cheap power saving

Although I've seen a site where they mention that pruning N rates (and
announcing a strange restricted set in the beacons) could cause issues
with some drivers, they didn't say which specific drivers or devices
had this issue. Maybe it was just a rule of thumb of theirs. Anyway,
wpa_supplicant has a setting for this as well (ht_mcs):

https://github.com/helmut-jacob/hostapd/blob/a35e34106723eb0b23df9114364d6fbc46fffab6/wpa_supplicant/wpa_supplicant.conf#L893

https://github.com/helmut-jacob/hostapd/blob/a35e34106723eb0b23df9114364d6fbc46fffab6/wpa_supplicant/config_ssid.h#L551

So some higher level patching might also be possible to enable hostapd
doing the same.

Although the effect is not entirely the same, it is already possible
to instruct the AP TX to use only the higher rates (except for
lookaround) by running these after wifi is up (in conjunction with the
config above):

iw dev wlan0 set bitrates # clear mask

iw dev wlan0 set bitrates legacy-2.4 12 18 24 36 48 54 ht-mcs-2.4 1 2
3 4 5 6 7 # ... up to max MCS

Regarding isolation, correct me if I'm wrong, but ap_isolate in
hostapd should be at another level and is enabled default, so it is
also a good idea to disable it:

# Client isolation can be used to prevent low-level bridging of frames between
# associated stations in the BSS. By default, this bridging is allowed.
# https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf

This came up on the forums as well recently:
https://forum.lede-project.org/t/how-to-prevent-guest-network-clients-to-communicate-with-each-other/14831

Could you please verify that when you connect two devices to the same
AP, they can't reach each other? (firewalls put aside) Even disabling
local broadcasts could help a bit if you say that complete isolation
is not feasible.

Not sure if the said campers have already arrived, but SmokePing stats
for today had greatly improved compared to the previous days. We'll
see after a few more days, but it's good to know that you still have
some more options to tweak.

It would be great if OpenWrt shipped with 802.11b disabled by default
and let the user decide whether she wants to enable it for legacy
users. I haven't encountered a 802.11b-only device in many years, and
they say that >95% of clients are already N/AC capable.

Regards

On Fri, Jun 8, 2018 at 11:37 AM, Pete Heist <pete at eventide.io> wrote:
>
> On May 31, 2018, at 2:52 AM, David Lang <david at lang.hm> wrote:
>
> On Sat, 19 May 2018, bkil wrote:
>
> In reply to this thread:
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2018-April/001787.html
>
> Sorry for the late response, although I can see from yesterday's
> SmokePing plots that the issue still prevails.
>
> 1.
> You should definitely not allow rates as low as 1Mb/s considering:
> * plots of signal vs. rate,
> * topology of closely packed cabins;
> * mostly static, noise-free camp ground.
>
> Almost all of your clients were able to link with >20Mb/s even at
> 70-80dBm. Those below were probably just idling. I'd limit the network
> to 802.11g/n-only, and would even consider disabling all rates below
> 12Mb/s.
>
>
> I have been wanting to do this on my APs for Scale (wndr3800 APs with ath9k
> chipsets) and have been unable to find how to do this on these chipsets.
>
>
> I also didn’t manage to disable specific MCS rates:
> - supported_rates and basic_rate in /etc/config/wireless seem to only affect
> legacy rates, not ht-mcs-2.4 rates.
> - "iw dev wlan0 set bitrates” only sets the transmit rate for the AP
>
> But what I did do at 10:45am today, June 8, was disable 802.11b rates with:
>
> uci set wireless.radio0.legacy_rates=‘0'
> uci commit
> reboot
>
> So at least the minimum rate should be limited to 6Mbit. We’ll see if this
> helps in the next few days as the camp fills, and if I hear any complaints:
>
> https://www.drhleny.cz/smokeping/
>

--
If you need an encryption key / ha kell titkosító kulcs:
http://bkil.blogspot.hu/2014/08/public-key.html

On Fri, Jun 8, 2018 at 11:37 AM, Pete Heist <pete at eventide.io> wrote:
>
> On May 31, 2018, at 2:52 AM, David Lang <david at lang.hm> wrote:
>
> On Sat, 19 May 2018, bkil wrote:
>
> In reply to this thread:
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2018-April/001787.html
>
> Sorry for the late response, although I can see from yesterday's
> SmokePing plots that the issue still prevails.
>
> 1.
> You should definitely not allow rates as low as 1Mb/s considering:
> * plots of signal vs. rate,
> * topology of closely packed cabins;
> * mostly static, noise-free camp ground.
>
> Almost all of your clients were able to link with >20Mb/s even at
> 70-80dBm. Those below were probably just idling. I'd limit the network
> to 802.11g/n-only, and would even consider disabling all rates below
> 12Mb/s.
>
>
> I have been wanting to do this on my APs for Scale (wndr3800 APs with ath9k
> chipsets) and have been unable to find how to do this on these chipsets.
>
>
> I also didn’t manage to disable specific MCS rates:
> - supported_rates and basic_rate in /etc/config/wireless seem to only affect
> legacy rates, not ht-mcs-2.4 rates.
> - "iw dev wlan0 set bitrates” only sets the transmit rate for the AP
>
> But what I did do at 10:45am today, June 8, was disable 802.11b rates with:
>
> uci set wireless.radio0.legacy_rates=‘0'
> uci commit
> reboot
>
> So at least the minimum rate should be limited to 6Mbit. We’ll see if this
> helps in the next few days as the camp fills, and if I hear any complaints:
>
> https://www.drhleny.cz/smokeping/
>