The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---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 <rmano...@qca.qualcomm.com> 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 >
--- End Message ---
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
