Thank you for your help Rajkumar, We've traced the problem down to a peering issue. Looks like there was a missing compile flag that caused some kind of incongruence. My best guest is that beacons are generated by firmware and advertise support for AC mode, whereas wpa_supplicant, when not compiled with CONFIG_IEEE80211AC=y, sends mesh peering messages and creates peers without AC support, causing firmware to get confused. After recompiling supplicant with the correct flag, no more crashes were observed in casual testing. I submitted a pull request to LEDE to, hopefully, fix it in upstream. Best regards, Alexis On Tue, Dec 13, 2016 at 3:51 PM, Manoharan, Rajkumar <rmanohar@xxxxxxxxxxxxxxxx> wrote: >> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT >> encryption and it still crashes. I suspect this means wpa_supplicant is setting up >> the interface incorrectly and/or transmitting a malformed packet that is causing >> the driver to crash. >> > Ben, > > IIRC mesh support was validated in qca988x in VHT mode while ago. Either it could > be regression in driver/fw or lede mac80211 package. > > 1) Could you please try plain backports in lede w/o applying ath10k patches. > I do see 160MHz support in LEDE. > 2) There are some peer stats dump from your earlier log. Disable peer stats > by "peer_stats" debugfs. > 3) Please confirm the behavior with older firmware revisions. > 4) use iw to bring up open mesh to rule out wpa_s config > > -Rajkumar >
