Re: [OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl
Hi Jouni! On Sat, May 16, 2020 at 11:54:55PM +0300, Jouni Malinen wrote: > 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.. I was intrigued by how fast Debian installer went through and after only a few minutes it booted with a working system, then installing build-essentials, automake, autoconf, libtool and git. The actual compile of wolfssl and wpa_supplicant then took several hours... > > 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 Thank you for finding the cause of the issue, fixing it and also for the detailed explaination! I can confirm that your commit does fix the issue on the QCA MIPS devices which were previously affected, they now reliably connect instantly now. Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl
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 MalinenPGP id EFC895FA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl
On Wed, May 13, 2020 at 03:19:32PM +0100, Daniel Golle wrote: > On Wed, May 13, 2020 at 04:01:03PM +0300, Jouni Malinen wrote: > > On Wed, May 13, 2020 at 11:46:03AM +0100, Daniel Golle wrote: > > > The build environment is currently on an otherwise unused system wired > > > up to the two QCA devices for testing. We could arrange remote access > > > remote access via SSH or you can tell me to build/test whatever you'd > > > like me to and I'll report back. > > > If you'd like to reproduce this locally or even include in your CI, > > > I guess that building Linux and wpa_supplicant for MIPS Malta (BE) and > > > running that in qemu-system-mips will show similar results as my > > > testing on real hardware. > > > > I guess it would be nice to get a big endian setup added for automated > > testing eventually, but setting that up with qemu sounds like something > > that is going to take significant amount of effort.. 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... If there is anything else I can do to help debugging this, let me know. Thank you! Best regards Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl
On Wed, May 13, 2020 at 04:01:03PM +0300, Jouni Malinen wrote:
> On Wed, May 13, 2020 at 11:46:03AM +0100, Daniel Golle wrote:
> > Odd, but could be endian or sizeof(int) related differences. I assume
> > you are testing on x86_64 glibc while I'm testing this on MIPS24kc
> > (big endian!) with musl libc running on QCA SoCs.
>
> Unfortunately, I don't have any convenient means for testing this
> combination on a big endian system. That said, the identified commit
> does not really have any area that would seem to be depending on
> endianness or word size of the CPU..
>
> > I've tried plain wpa_supplicant as well as with OpenWrt's patches, all
> > build against WolfSSL 4.3.0-stable.
> >
> > using git revision 2b84ca4d :
> >
> > root@OpenWrt:~# wpa_supplicant -ddd -P
> > /var/run/wpa_supplicant-wlan1-mesh.pid -D nl80211 -i wlan1-mesh -c
> > /var/run/wpa_supplicant-wlan1-mesh.conf
> > Successfully initialized wpa_supplicant
> > Using interface wlan1-mesh with hwaddr 64:70:02:xx:xx:xx and ssid ""
> > wlan1-mesh: interface state UNINITIALIZED->ENABLED
> > wlan1-mesh: AP-ENABLED
> > wlan1-mesh: joining mesh LiMe
> ...
>
> This wpa_supplicant build lacks all debugging detail.. Could you please
> enable full debugging, i.e., remove whatever OpenWrt patches and/or
> build configuration does to disable debugging? Without the details,
> there is not really much that can be done do figure out what exactly is
> failing since none of the SAE details are shown here.
I'm about to send you full logs (rather large) off-list.
>
> > The build environment is currently on an otherwise unused system wired
> > up to the two QCA devices for testing. We could arrange remote access
> > remote access via SSH or you can tell me to build/test whatever you'd
> > like me to and I'll report back.
> > If you'd like to reproduce this locally or even include in your CI,
> > I guess that building Linux and wpa_supplicant for MIPS Malta (BE) and
> > running that in qemu-system-mips will show similar results as my
> > testing on real hardware.
>
> I guess it would be nice to get a big endian setup added for automated
> testing eventually, but setting that up with qemu sounds like something
> that is going to take significant amount of effort..
>
> Could you please check that the following patch fixes the issue? In
> practice, this is reverting any functional difference of commit
> 6c9543fcb for SAE. This should not really fix anything based on code
> review, but I want to make sure that it is indeed this particular commit
> that explains the real issue before spending significant effort in
> figuring out how the move from wpa_supplicant internal random number
> generation to WolfSSL mp_rand_prime() could cause this type of an issue
> on some platforms (but not on x86-64).
That didn't help, unfortunately.
>
>
>
> diff --git a/src/common/dragonfly.c b/src/common/dragonfly.c
> index 547be66f1561..6bce5ee4e4fb 100644
> --- a/src/common/dragonfly.c
> +++ b/src/common/dragonfly.c
> @@ -8,10 +8,13 @@
> */
>
> #include "utils/includes.h"
> +#include
> +#include
>
> #include "utils/common.h"
> #include "utils/const_time.h"
> #include "crypto/crypto.h"
> +#include "crypto/random.h"
> #include "dragonfly.h"
>
>
> @@ -54,33 +57,41 @@ int dragonfly_get_random_qr_qnr(const struct
> crypto_bignum *prime,
> struct crypto_bignum **qr,
> struct crypto_bignum **qnr)
> {
> + size_t prime_bits = mp_count_bits((mp_int *) prime);
> + size_t prime_len = (prime_bits + 7) / 8;
> + u8 prime_bin[DRAGONFLY_MAX_ECC_PRIME_LEN];
> +
> + if (crypto_bignum_to_bin(prime, prime_bin, sizeof(prime_bin),
> + prime_len) < 0)
> + return -1;
> +
> *qr = *qnr = NULL;
>
> while (!(*qr) || !(*qnr)) {
> - struct crypto_bignum *tmp;
> + u8 tmp[DRAGONFLY_MAX_ECC_PRIME_LEN];
> + struct crypto_bignum *q;
> int res;
>
> - tmp = crypto_bignum_init();
> - if (!tmp || crypto_bignum_rand(tmp, prime) < 0) {
> - crypto_bignum_deinit(tmp, 0);
> + if (random_get_bytes(tmp, prime_len) < 0)
> break;
> - }
> + if (prime_bits % 8)
> + buf_shift_right(tmp, prime_len, 8 - prime_bits % 8);
> + if (os_memcmp(tmp, prime_bin, prime_len) >= 0)
> + continue;
> + q = crypto_bignum_init_set(tmp, prime_len);
> + if (!q)
> + break;
> + res = crypto_bignum_legendre(q, prime);
>
> - res = crypto_bignum_legendre(tmp, prime);
> if (res == 1 && !(*qr))
> - *qr = tmp;
> + *qr = q;
> else if (res == -1 && !(*qnr))
> - *qnr = tmp;
> + *qnr = q;
> else
> -
Re: [OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl
On Wed, May 13, 2020 at 11:46:03AM +0100, Daniel Golle wrote:
> Odd, but could be endian or sizeof(int) related differences. I assume
> you are testing on x86_64 glibc while I'm testing this on MIPS24kc
> (big endian!) with musl libc running on QCA SoCs.
Unfortunately, I don't have any convenient means for testing this
combination on a big endian system. That said, the identified commit
does not really have any area that would seem to be depending on
endianness or word size of the CPU..
> I've tried plain wpa_supplicant as well as with OpenWrt's patches, all
> build against WolfSSL 4.3.0-stable.
>
> using git revision 2b84ca4d :
>
> root@OpenWrt:~# wpa_supplicant -ddd -P /var/run/wpa_supplicant-wlan1-mesh.pid
> -D nl80211 -i wlan1-mesh -c /var/run/wpa_supplicant-wlan1-mesh.conf
> Successfully initialized wpa_supplicant
> Using interface wlan1-mesh with hwaddr 64:70:02:xx:xx:xx and ssid ""
> wlan1-mesh: interface state UNINITIALIZED->ENABLED
> wlan1-mesh: AP-ENABLED
> wlan1-mesh: joining mesh LiMe
...
This wpa_supplicant build lacks all debugging detail.. Could you please
enable full debugging, i.e., remove whatever OpenWrt patches and/or
build configuration does to disable debugging? Without the details,
there is not really much that can be done do figure out what exactly is
failing since none of the SAE details are shown here.
> The build environment is currently on an otherwise unused system wired
> up to the two QCA devices for testing. We could arrange remote access
> remote access via SSH or you can tell me to build/test whatever you'd
> like me to and I'll report back.
> If you'd like to reproduce this locally or even include in your CI,
> I guess that building Linux and wpa_supplicant for MIPS Malta (BE) and
> running that in qemu-system-mips will show similar results as my
> testing on real hardware.
I guess it would be nice to get a big endian setup added for automated
testing eventually, but setting that up with qemu sounds like something
that is going to take significant amount of effort..
Could you please check that the following patch fixes the issue? In
practice, this is reverting any functional difference of commit
6c9543fcb for SAE. This should not really fix anything based on code
review, but I want to make sure that it is indeed this particular commit
that explains the real issue before spending significant effort in
figuring out how the move from wpa_supplicant internal random number
generation to WolfSSL mp_rand_prime() could cause this type of an issue
on some platforms (but not on x86-64).
diff --git a/src/common/dragonfly.c b/src/common/dragonfly.c
index 547be66f1561..6bce5ee4e4fb 100644
--- a/src/common/dragonfly.c
+++ b/src/common/dragonfly.c
@@ -8,10 +8,13 @@
*/
#include "utils/includes.h"
+#include
+#include
#include "utils/common.h"
#include "utils/const_time.h"
#include "crypto/crypto.h"
+#include "crypto/random.h"
#include "dragonfly.h"
@@ -54,33 +57,41 @@ int dragonfly_get_random_qr_qnr(const struct crypto_bignum
*prime,
struct crypto_bignum **qr,
struct crypto_bignum **qnr)
{
+ size_t prime_bits = mp_count_bits((mp_int *) prime);
+ size_t prime_len = (prime_bits + 7) / 8;
+ u8 prime_bin[DRAGONFLY_MAX_ECC_PRIME_LEN];
+
+ if (crypto_bignum_to_bin(prime, prime_bin, sizeof(prime_bin),
+prime_len) < 0)
+ return -1;
+
*qr = *qnr = NULL;
while (!(*qr) || !(*qnr)) {
- struct crypto_bignum *tmp;
+ u8 tmp[DRAGONFLY_MAX_ECC_PRIME_LEN];
+ struct crypto_bignum *q;
int res;
- tmp = crypto_bignum_init();
- if (!tmp || crypto_bignum_rand(tmp, prime) < 0) {
- crypto_bignum_deinit(tmp, 0);
+ if (random_get_bytes(tmp, prime_len) < 0)
break;
- }
+ if (prime_bits % 8)
+ buf_shift_right(tmp, prime_len, 8 - prime_bits % 8);
+ if (os_memcmp(tmp, prime_bin, prime_len) >= 0)
+ continue;
+ q = crypto_bignum_init_set(tmp, prime_len);
+ if (!q)
+ break;
+ res = crypto_bignum_legendre(q, prime);
- res = crypto_bignum_legendre(tmp, prime);
if (res == 1 && !(*qr))
- *qr = tmp;
+ *qr = q;
else if (res == -1 && !(*qnr))
- *qnr = tmp;
+ *qnr = q;
else
- crypto_bignum_deinit(tmp, 0);
+ crypto_bignum_deinit(q, 0);
}
- if (*qr && *qnr)
- return 0;
- crypto_bignum_deinit(*qr, 0);
- crypto_bignum_deinit(*qnr, 0);
- *qr = *qnr = NULL;
- return -1;
+ return (*qr && *qnr) ? 0 : -1;
}
--
Re: [OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl
Hi Jouni,
thanks for the quick reply!
On Wed, May 13, 2020 at 11:38:17AM +0300, Jouni Malinen wrote:
> On Tue, May 12, 2020 at 10:46:12PM +0100, Daniel Golle wrote:
> > After hours of bisecting which change between hostapd_2_8 and
> > hostapd_2_9 broke SAE in mesh mode with WolfSSL we got a result:
> >
> > > commit 6c9543fcb7962e26c2a91c43089abe171d073b44
> > > Author: Jouni Malinen
> > > Date: Thu Apr 25 20:18:27 2019 +0300
> > >
> > > Share common SAE and EAP-pwd functionality: random qr/qnr creation
> > >
> > > Use a shared helper function to create random qr/qnr values.
> > >
> > > Signed-off-by: Jouni Malinen
> >
> > While when building against OpenSSL, things keep working also after
> > the above commit, when building against WolfSSL, the node hangs in
> > LISTEN state for a long time and then ends up BLOCKED.
> > I've tried with WolfSSL 3.14.4 and WolfSSL 4.3.0-stable-1 with
> > identical results.
>
> This works fine in my tests with 4.3.0. All the mac80211_hwsim test
> cases for mesh pass with the current wpa_supplicant snapshot built with
> WolfSSL 4.3.0.
Odd, but could be endian or sizeof(int) related differences. I assume
you are testing on x86_64 glibc while I'm testing this on MIPS24kc
(big endian!) with musl libc running on QCA SoCs.
>
> > Going back to commit 2b84ca4dd
> > ("Share common SAE and EAP-pwd functionality: suitable groups") makes
> > things working again also with WolfSSL.
> >
> > On first sight there seems nothing wrong with that commit to me, but
> > apparently it does break things :(
> >
> > Any ideas helping to fix this would be highly appreciated!
>
> Can you please share some more details on how you are testing this and
> ideally, debug logs from two devices for a case that fails with WolfSSL,
> but works with OpenSSL? I'd like to also get a confirmation that you are
> seeing the issue with the current snapshot of the master branch in
> hostap.git since that is the version I would be using for any debugging
> of the issue.
I've tried plain wpa_supplicant as well as with OpenWrt's patches, all
build against WolfSSL 4.3.0-stable.
using git revision 2b84ca4d :
root@OpenWrt:~# wpa_supplicant -ddd -P /var/run/wpa_supplicant-wlan1-mesh.pid
-D nl80211 -i wlan1-mesh -c /var/run/wpa_supplicant-wlan1-mesh.conf
Successfully initialized wpa_supplicant
Using interface wlan1-mesh with hwaddr 64:70:02:xx:xx:xx and ssid ""
wlan1-mesh: interface state UNINITIALIZED->ENABLED
wlan1-mesh: AP-ENABLED
wlan1-mesh: joining mesh LiMe
wlan1-mesh: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed
[id=0 id_str=]
wlan1-mesh: MESH-GROUP-STARTED ssid="LiMe" id=0
wlan1-mesh: new peer notification for 04:18:d6:xx:xx:xx
wlan1-mesh: mesh plink with 04:18:d6:xx:xx:xx established
wlan1-mesh: MESH-PEER-CONNECTED 04:18:d6:xx:xx:xx
using git revision 6c9543fc :
root@OpenWrt:~# wpa_supplicant -ddd -P /var/run/wpa_supplicant-wlan1-mesh.pid
-D nl80211 -i wlan1-mesh -c /var/run/wpa_supplicant-wlan1-mesh.conf
Successfully initialized wpa_supplicant
Using interface wlan1-mesh with hwaddr 64:70:02:xx:xx:xx and ssid ""
wlan1-mesh: interface state UNINITIALIZED->ENABLED
wlan1-mesh: AP-ENABLED
wlan1-mesh: joining mesh LiMe
wlan1-mesh: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed
[id=0 id_str=]
wlan1-mesh: MESH-GROUP-STARTED ssid="LiMe" id=0
wlan1-mesh: new peer notification for 04:18:d6:xx:xx:xx
wlan1-mesh: MESH-SAE-AUTH-FAILURE addr=04:18:d6:xx:xx:xx
wlan1-mesh: MESH-SAE-AUTH-FAILURE addr=04:18:d6:xx:xx:xx
wlan1-mesh: MESH-SAE-AUTH-FAILURE addr=04:18:d6:xx:xx:xx
wlan1-mesh: MESH-SAE-AUTH-FAILURE addr=04:18:d6:xx:xx:xx
wlan1-mesh: MESH-SAE-AUTH-BLOCKED addr=04:18:d6:xx:xx:xx duration=300
...(after a minute or two)
using git revision 0f58c88f :
root@OpenWrt:~# wpa_supplicant -ddd -P /var/run/wpa_supplicant-wlan1-mesh.pid
-D nl80211 -i wlan1-mesh -c /var/run/wpa_supplicant-wlan1-mesh.conf
Successfully initialized wpa_supplicant
wlan1-mesh: interface state UNINITIALIZED->ENABLED
wlan1-mesh: AP-ENABLED
wlan1-mesh: joining mesh LiMe
wlan1-mesh: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed
[id=0 id_str=]
wlan1-mesh: MESH-GROUP-STARTED ssid="LiMe" id=0
wlan1-mesh: new peer notification for 04:18:d6:xx:xx:xx
wlan1-mesh: MESH-SAE-AUTH-FAILURE addr=04:18:d6:xx:xx:xx
wlan1-mesh: MESH-SAE-AUTH-FAILURE addr=04:18:d6:xx:xx:xx
wlan1-mesh: MESH-SAE-AUTH-FAILURE addr=04:18:d6:xx:xx:xx
wlan1-mesh: new peer notification for 04:18:d6:xx:xx:xx
... (takes VERY long for each line)
using git revision 0f58c88f, but build against OpenSSL 1.1.1g:
root@OpenWrt:~# wpa_supplicant -ddd -P /var/run/wpa_supplicant-wlan1-mesh.pid
-D nl80211 -i wlan1-mesh -c /var/run/wpa_supplicant-wlan1-mesh.conf
Successfully initialized wpa_supplicant
wlan1-mesh: interface state UNINITIALIZED->ENABLED
wlan1-mesh: AP-ENABLED
wlan1-mesh: joining mesh LiMe
wlan1-mesh: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed
[id=0 id_str=]
wlan1-mesh: MESH-GROUP-STARTED
Re: [OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl
On Tue, May 12, 2020 at 10:46:12PM +0100, Daniel Golle wrote:
> After hours of bisecting which change between hostapd_2_8 and
> hostapd_2_9 broke SAE in mesh mode with WolfSSL we got a result:
>
> > commit 6c9543fcb7962e26c2a91c43089abe171d073b44
> > Author: Jouni Malinen
> > Date: Thu Apr 25 20:18:27 2019 +0300
> >
> > Share common SAE and EAP-pwd functionality: random qr/qnr creation
> >
> > Use a shared helper function to create random qr/qnr values.
> >
> > Signed-off-by: Jouni Malinen
>
> While when building against OpenSSL, things keep working also after
> the above commit, when building against WolfSSL, the node hangs in
> LISTEN state for a long time and then ends up BLOCKED.
> I've tried with WolfSSL 3.14.4 and WolfSSL 4.3.0-stable-1 with
> identical results.
This works fine in my tests with 4.3.0. All the mac80211_hwsim test
cases for mesh pass with the current wpa_supplicant snapshot built with
WolfSSL 4.3.0.
> Going back to commit 2b84ca4dd
> ("Share common SAE and EAP-pwd functionality: suitable groups") makes
> things working again also with WolfSSL.
>
> On first sight there seems nothing wrong with that commit to me, but
> apparently it does break things :(
>
> Any ideas helping to fix this would be highly appreciated!
Can you please share some more details on how you are testing this and
ideally, debug logs from two devices for a case that fails with WolfSSL,
but works with OpenSSL? I'd like to also get a confirmation that you are
seeing the issue with the current snapshot of the master branch in
hostap.git since that is the version I would be using for any debugging
of the issue.
--
Jouni MalinenPGP id EFC895FA
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl
Hi!
After hours of bisecting which change between hostapd_2_8 and
hostapd_2_9 broke SAE in mesh mode with WolfSSL we got a result:
> commit 6c9543fcb7962e26c2a91c43089abe171d073b44
> Author: Jouni Malinen
> Date: Thu Apr 25 20:18:27 2019 +0300
>
> Share common SAE and EAP-pwd functionality: random qr/qnr creation
>
> Use a shared helper function to create random qr/qnr values.
>
> Signed-off-by: Jouni Malinen
While when building against OpenSSL, things keep working also after
the above commit, when building against WolfSSL, the node hangs in
LISTEN state for a long time and then ends up BLOCKED.
I've tried with WolfSSL 3.14.4 and WolfSSL 4.3.0-stable-1 with
identical results.
Going back to commit 2b84ca4dd
("Share common SAE and EAP-pwd functionality: suitable groups") makes
things working again also with WolfSSL.
On first sight there seems nothing wrong with that commit to me, but
apparently it does break things :(
Any ideas helping to fix this would be highly appreciated!
Best regards
Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
