On Wed, May 13, 2020 at 05:34:31PM +0100, Daniel Golle wrote: > I've just built OpenWrt for MIPS malta (BE) with mac80211-hwsim and > hereby confirm the problem shows up there in exactly the same way. > Also on MIPS malta with mac80211-hwsim, mesh with SAE works with > WolfSSL up to and including hostapd git revision 2b84ca4dd work fine, > starting from revision 6c9543fcb7 don't. > > As OpenWrt might not be what you want for QA, I've been following > https://markuta.com/how-to-build-a-mips-qemu-image-on-debian/ > and ended up with a functional Debian install inside QEMU about 20 > minutes later. (I had to replace kernel image vmlinux-4.9.0-6-4kc-malta > mentioned in that guide with vmlinux-4.19.0-9-4kc-malta which is the > current version and exists on Debian's download server) > This would allow to run the whole test-suite as-is on MIPS32 BE, maybe > even with buildbot.w1.fi... Thanks for the pointer. That 20 minutes seemed a bit optimistic for the full setup, but I did get this running with buildroot-based cross compiler setup. Emulating a big endian MIPS processor with QEMU does not look exactly fast, though.. This can get the mac80211_hwsim test cases started, but significant portion of them fails due to various timeouts and it takes hours--or well, maybe days--to run through the full test set (but to be fair, I could run multiple VM instances in parallel to speed this up). Anyway, this can be quite useful to have available for manually testing some specific implementation details.. As far as this issue with SAE is concerned, there is actually nothing wrong with the calculation results, i.e., all the values are correct and I was able to get SAE completed with the current snapshot.. However, it is really slow. To the point of taking close to a minute to complete authentication. I'd assume you are seeing timeouts from this or just giving up on waiting before the operation is completed. While the current standard version of SAE is inconveniently slow on low end processors, it was not supposed to be this slow. It turned out that the real issue here is in not exactly ideal implementation of the wolfssl wrapper function crypto_bignum_rand(). This function is expected to return a random value between 0 and m-1. That is what the function did, but it did that by finding a random _prime_ double the maximum length of that range and then scaling to to the range which is significantly harder calculation (took around 40 times longer than needed in some of my tests) and completely unnecessary for this function. This commit fixes that issue: https://w1.fi/cgit/hostap/commit/?id=eb595b3e3ab531645a5bde71cf6385335b7a4b95 -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
