That can't be the case here, since we see it break the mesh too (where the clients are other QCA radios.)
We're now seeing very slow mesh peering with a 9882 leaf to a 4019 gateway, with the second version of this patch. It took more than five minutes for one of the leaves to successfully peer (and the other 9882 leaf, despite achieving peering, never managed to get DHCP, implying that something is broken with data frames and this patch on qca9882.) On Tue, Oct 24, 2017 at 9:09 AM, Ben Greear <gree...@candelatech.com> wrote: > On 10/23/2017 09:50 PM, Kalle Valo wrote: >> >> Jasmine Strong <j...@eero.com> writes: >> >>> That's what I saw. A bcom client was able to associate and not pass >>> any traffic. This is on all three of 9882, 9888 and 4019. >> >> >> Thanks for the report, we'll investigate it. And I see that your email >> was now succesfully delivered to the list: >> >> http://lists.infradead.org/pipermail/ath10k/2017-October/010325.html > > > > I'm not sure if this is helpful or not, but in the transition from 10.1 to > 10.2 firmware, > there was some tricky re-work of the PN counter logic in the firmware > source. It had > specific impact on the broadcom driver interaction. > > Possibly a similar issue is being seen with this driver patch? > > Thanks, > Ben > > -- > Ben Greear <gree...@candelatech.com> > Candela Technologies Inc http://www.candelatech.com >
