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

Wed Jun 13 09:07:44 EDT 2018

Trying one thing at a time, as legacy_rates=‘1’ didn’t do anything noticeable, which is not surprising when we probably don’t have many ‘b' devices connecting. We hit 4.9s ping times this morning, good work. :)

Even though isolation couldn’t be turned on in the admin interface (because it says it can’t do it when bridging to a VLAN, for some reason), I was able to enable isolation for both SSIDs and it still seems to work, so that’s the change as of now:

wireless.ap0_1.isolate='1'
wireless.ap0_2.isolate=‘1’

Before I could ping between clients, and now I can’t, so apparently isolation is doing what it should. The next test will be tonight.

I’m still waiting for the digging / cabling project to happen, which is what I expect to bring the biggest benefit. Again, that will add a new cabled AP which will serve as a gateway for cabin 12 and split cabins 12 and 20. This should also improve the signal to 12 vastly, which is one of the most loaded APs and currently only has RSSI -71 / MCS 5 or 6 to its parent AP, now that the leaves are full on the trees.

> On Jun 9, 2018, at 5:32 PM, bkil <bkil.hu+Aq at gmail.com> wrote:
> 
> 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/
>> 