esp-rs
Non-open softAP not supported
I know the readme already has a point about not supporting non-open softAP but there is no open issue about the general thing. https://github.com/esp-rs/esp-wifi/issues/454 exists but for WPA2-Enterprise, which is a subset that requires some authmode-specific code.
Let's start by stating that I've tried the obvious: copying config values from esp-idf-svc. Unfortunately, it looks like this issue isn't as easy as a misconfigured softAP.
My $0.02
Last time I tried to use the SoftAP with an auth method, I fell on the gettimeofday() that wasn't implemented. This has been fixed in esp-rs/esp-wifi#304, but this makes me think since a certain number of extern "c" fn are being called to initialize it, we should see if there isn't an issue there. It would have normally panicked, if we fell on an unimplemented one, but maybe an implemeted one doesn't return the right value that the precompiled libs expect. I also don't know what's the actual issue after copying the value, so my comment above might be off tracks.
Can we use this issue to track the implementation, and debugging? And post what bits of code you changed? Or maybe open a Draft PR.
I guess the problem is that we compile wpa_supplicant with TinyCrypt - not mbed-tls: https://github.com/esp-rs/esp-wireless-drivers-3rdparty/blob/master/patch/esp32c3/sdkconfig.defaults
The reason for that is mbed-tls is quite huge and pulls in a lot of stuff from esp-idf
This is also causing esp-rs/esp-wifi#109
My ultimate dream solution would be esp-rs/esp-wifi#158 ... but that's a huge thing
TinyCrypt
is that basically a no-op thing that makes things compile but break as soon as anything needs crypto? this is essentially what we seem to be experiencing
at any rate, this might probably be a blocker for esp-wifi based commercial projects
TinyCrypt only includes support for a subset of crypto that is needed for more advanced things: https://github.com/intel/tinycrypt/tree/master/lib/source
Probably the missing parts are no-ops then
Ah seems it's actually not TinyCrypt but some crypto impls in wpa_supplicant itself: https://github.com/espressif/esp-idf/blob/b4268c874a4cf8fcf7c0c4153cffb76ad2ddda4e/components/wpa_supplicant/CMakeLists.txt#L104-L161
But the thing about the crypto is just guessing currently - probably we need to test that with an ESP-IDF example and see what config options are really needed
Is there a workaround for this? Even one that imports an inconveniently-large lib?
I think the best bet would be to get https://github.com/esp-rs/esp-wifi/pull/394 working, and implement the crypto functions.
@bjoernQ Now that we support WPA enterprise (which IIRC forced us to pull in the crypto libs), is this more feasible to fix?
@bjoernQ Now that we support WPA enterprise (which IIRC forced us to pull in the crypto libs), is this more feasible to fix?
Not yet unfortunately - we have some more crypto functions now but IIRC non-open AP would need mbedtls - but worth to double check definitely
Is non-open softap planned to be added by May? I'm not putting pressure on anyone, I only want to know if it will be added.
Is non-open softap planned to be added by May? I'm not putting pressure on anyone, I only want to know if it will be added.
We want to support it, but I don't see it happen until May. Do you have a special use-case where you need it?
Is non-open softap planned to be added by May? I'm not putting pressure on anyone, I only want to know if it will be added.
We want to support it, but I don't see it happen until May. Do you have a special use-case where you need it?
I'm not even that sure I will need it, I will have a competition between RC 1:10 F1 cars, and other teams might be able to read our telemetry or I don't know what else. But I don't think they'll be this evil, it's a high school competition. So if it's not planned, no problem, take your time, I don't want to put pressure on an oss project.