Kirill Lukonin (Evil Wireless Man)

Sure. No problem. https://groups.google.com/forum/m/#!topic/openwisp/SquuMmCCQCI

@nemesisdesign I made some tests and ipv4 devices worked as usual. So, looks like we have a good chance ))

I'll let myself to answer. First of all, some packages such as Suricata require Rust to work properly. https://github.com/openwrt/packages/pull/8659

@greearb This issue can be fixed with beacon_int = 10 too. We had the same issue and now we can't trigger a problem with such low beacon interval.

Hello! This looks quite like the same issue we faced and reported in dec 2016. 100% reproducible with 10.1 firmware and QCA988X. @oamouroux Please can you check this issue again?...

Hello, @oamouroux and @greearb . We've jist triggered this issue in our lab again. Look's like thr problem can be solved (or mitigated) with this parameters: 1) max_nss = 2...

Hello, Ben! @greearb Looks like a found a bug. @oamouroux Please check your issue too. if we look into fwstats, there will be a strange behavior. Look at the first...

@greearb We also noticed that the first peer should not exist at all. there are no any mac address with this value BUT please look below. ath10k PEER stats (3)...

We see this phantom peer all the time, even with AP interface without any sta connected. For example: ath10k PEER stats (1) ================= Peer MAC address 2b:00:00:00:5a:be Peer RSSI 45976...

I can confirm that max_nss = 2 with beacon_int = 10 helps. max_nss = 2 alone doesn't help We will try to test only beacon_int = 10 hack and I'll...