esp32_sha errors -> 5.6.6-stable-update2-esp32 #7210
Comments
|
Hello @AchimPieters - I've been able to reproduce the problem you are seeing. The cause appears to be that with hardware acceleration enabled (by default), the ESP32 libraries do not properly handle this define in your Remove that line should fix the compile problem you are seeing. Additionally, a few other observations and recommendations: Your example contains an entire copy of wolfSSL. I've (painfully) learned this can be problematic to maintain and troublehoot. The latest versions of the There's also a potential problem of distributing wolfSSL. I'm not a licensing expert, so it is probably best to contact support@wolfssl.com It is best to include the wolfSSL I'm leaving this issue open, as the |
|
@gojimmypi The No SHA did the trick, git some errors that are hardware specific related, but not with Wolfssl. I'm going to see if I can add wolfssl as a submodule: https://components.espressif.com/components/wolfssl/wolfssl If you have any recommendations, I would like to here them. |
|
@gojimmypi I solved all problems with the latest version of Wolfssl (v5.6.6-stable), I can compile my code for esp32 but now have this issue? And when compiling for an ESP32C3: The latest information can be found here: https://github.com/AchimPieters/esp32-homekit-demo.git |
|
Hello @AchimPieters !
Yes, I really need to put a blog together to better explain that. First: I'm not so much a fan of using submodules, as least not as a developer. It's great for distribution of a final product but does not lend itself to being able to easily make changes. Regarding the link you mentioned, that's an Espressif Managed Component. It is a wonderful tool for easily getting started, but that too - does not lend itself to making changes as a developer. In fact, it is even less friendly than a submodule: as soon as a change is detected, it complains. It is great for maintaining code integrity, but not for making changes. In your example, I deleted everything in this directory except for the I then made one change to the I was able to successfully compile the example LED project that references wolfSSL. The cool thing here that as a developer, we can more easily see changes and contribute. The library can be shared among as many projects as desired, and versions can easily be changed either with git hashes or even pointing to a completely different directory. Regarding the more recent SRP errors you are seeing: is that for the LED or some other example? I'm wondering if there's an issue finding the I might try isolating the project and using wolfSSL as a local component as seen in the examples. |
|
Hello @gojimmypi,
Also for the esp32C3 or ESPC2?
Did you do so with my current version, or my I have tried everything with the latest version of wolffsl 5.6.6-stable-update2-esp32 but noting works any more? Even the basic ESP32 setup, that worked like a charm, doesn't work any more. Maybe clone my latest repro to see what I mean? https://github.com/AchimPieters/esp32-homekit-demo |
I did this with the same code clone mentioned above, so within the last couple of weeks.
I only tested for the ESP32, but would expect similar successful results with others such the -C3 ad -C2. Did you see different results?
I'll need a little more detail, please.
I'll revisit switch your latest code soon. I just need to finish up a few customer requests. Any additional information would be helpful, such as specific error messages, please. |
|
Reproduction steps Open a terminal window:
Open a new (second) terminal window: screen /dev/tty.usbserial-01FD1166 115200 in HomeKit app -> Unable to add Accessory |
|
Hello @AchimPieters It looks like you are making excellent progress on your project! I've reviewed your log, above: it appears wolfSSL is compiling and working properly for you now. What was the problem & solution with your SRP initializer? Recall I don't have any Apple products, so I am unable to test the HomeKit app with your examples. The message |
|
Hello @gojimmypi, I'm totally lost, can we take it from the top again? Reproduction stepsOpen a terminal window on your mac.
And then the errors appear: here is my current I've tried the "old" fixes, but they resolve the problem "kindisch", maybebe we can have a look specific at the current setup en solve them step by step, to see if this solves the problems? |
|
Hello @AchimPieters I have been able to replicate the compile problem you are seeing. I appreciate your persistence and patience as we work through these issues. Try adding these to your wolfssl #define WOLFCRYPT_HAVE_SRP
#define HAVE_CHACHA
#define HAVE_POLY1305
#define WOLFSSL_BASE64_ENCODELet me know if that works for you. |
|
@gojimmypi I added the lines and did a compile, everything worked fine until this error?
When changing the partition table to: I can compile without any error, but then when I want to add the accessory to HomeKit it gives this errror: so the known I could follow the steps above, but want to do this together with you, so we are and stay on the same page. So what do you recommend doing. |
Well, yes, we turned on new features. We saw that error last year. Curious that you ran out of memory, as I still had 2% available yesterday on my classic ESP32 and did not need to adjust the partition size. btw - see my defaults, in particular the partitions_singleapp_large.csv that may be helpful.
It looks like the suggested settings from dgarske are missing from your user_settings.h: Please add the I suggest keeping Seems you are very close! It would be great to see this all working as desired. |
|
Okay, that did something. Now I still get "Unable to add accessory" and in the terminal: The SRP works kindich... Current files and setup: https://github.com/AchimPieters/esp32-homekit-demo.git |
|
It seems you are really close! Excellent. What's different from when you last had this working? It's getting a bit more difficult for me to help, given that I don't have any of the Homekit hardware. I do have some suggestions though:
Recently while working on the SSH to UART example, I discovered a problem with SHA256 hardware acceleration as noted in wolfSSL/wolfssh-examples#4. I'm working on a solution to both fix the code, and capture in wolfCrypy test. The root cause was a hash interleave that I did not properly take into account when in The brute-force method to start with is to disable all hardware acceleration in the user_settings.h:
Let me know how that goes. I'd really like to see the your Homekit examples working again. Best Regards |
|
@gojimmypi The first test worked, I'm going to do some tests this weekend to see if it also works on a ESPC2-02 and other esp models. I Will let you know, so far so good! I enabled all these lines in user_settings.h |
|
Tested: ESP32 WROOM 32D - SUCCES! The SRP error is back |
|
Hi @AchimPieters - That's awesome you have it working! Regarding your ESP-C3-12F Kit: The default hardware acceleration disabling is SoC-specific. Can you please confirm you've disabled it for the ESP32-C3 in your user_settings.h for the You may also consider moving the definitions completely outside of the conditional SoC check to disable all hardware acceleration for all devices. I'll need to look into why the hardware acceleration passes all tests but apparently causes the SRP to fail. Well done on making such great progress! Cheers |
|
@gojimmypi, You are awesome, couldn't do it without you! Thank you so much! Regarding the User_settings.h here is my latest files: https://github.com/AchimPieters/esp32-homekit-demo.git I'll keep working en testing this weekend, and will share my results! |
|
@gojimmypi I have checked, double-checked, Krajiceked... But the I also have ordered some ESP32XX Devkits for better debugging capabilities... |
|
Hello @AchimPieters - Can you please confirm the SRP is fully operational with the hardware acceleration confirmed as disabled for the respective target ESP32 SoC flavor? (I'm not sure I understand the Richard Krajicek tennis link: essentially "quadruple checked"?). Your prior comment seemed to indicate success, but the most recent comment indicates otherwise. Unless running out of heap or stack, or something wrong with the calling application... I would expect the wolfSSL SRP to be 100% operational in software only mode. (and in theory with hardware acceleration, if everything there is working properly). I'm assuming this is a hardware acceleration problem, similar to the issue I mentioned with the wolfSSH signature and the interleaved hash calcs not being handled properly. I recently updated the wolfCrypt tests for checking SHA interleaving in #7262. I believe I've resolved SHA interleave problem with another PR coming soon. It could well be the SRP has a similar or same problem. I'll be giving this a high priority to resolve. I need to be 100% certain of the results your are seeing, particularly since I don't have the hardware to reproduce myself. If you are ordering new ESP32 boards: one thing I should have mentioned that in addition to the Tigard external JTAG, the newer Espressif boards with 2 USB ports typically also have JTAG built-in to the board. It is of course not as flexible as having a stand-alone JTAG, but at least that specific board can use the JTAG debugger quite easily. Thanks for your help. Cheers |
|
@gojimmypi the SRP is fully operational with the hardware acceleration confirmed as disabled for the respective target ESP32 SoC flavor, But Not for the ESP32C3 and other models. The Krajicek, was maybe a bad word joke, sorry but that.... ETA for the new ESP boards with double USB ports for better debugging is 7 days, once I receive them, I can do a model by model test. Thank You for your continuous support, you're the best! |
|
@gojimmypi, I received the modules ESP32, ESP32C2, ESP32C3 and ESP32S3. As said the ESP32 works, but the other models got SRP errors, I attach a log from every model. |
|
@AchimPieters Thank you for the additional details and congratulations on your new purchases of other ESP32 devices! As you said the ESP32 works, but we disabled the hardware acceleration there, right? It appears that your user_settings.h also has hardware disabled for the ESP32-C3. Are you saying that even in software-only mode, you are still seeing SRP errors? If indeed your are seeing software-only problems, I suggest turning on the stack smashing and heap corruption detection. Perhaps there's a low memory problem. The SRP is fairly robust and unlikely to have problems with hardware acceleration turned off. I'm actively working on a solution to this & appreciate any additional information. |
|
Are you saying that even in software-only mode, you are still seeing SRP errors? So I'm going to try to follow your advice and turn on the stack smashing and heap corruption detection, and keep you updated. |
|
Thanks for the confirmation. I have a fix in the works for the SRP issue. It's my active development branch, but this commit should be relatively good if you'd like to take it for a test drive. In particular, I have this updated wolfssl_test app that specifically includes a test for the SRP enabled. (and many other features enabled, for the most exhaustive ESP32 test ever). fwiw - I never saw an SRP failure in software-only mode. It is of course not the same as your actual Homekit app: Perhaps an updated test is in order if you've found something new. I hope to have a PR together in the relatively near future. |
|
@gojimmypi Okay I have given it a try, but got this error: I don't know whether I did something wrong or something wrong with your branch? |
|
My branch is under active development so at some point, there might have been inoperable code at some point. When The wolfcrypt TFM library does not include this by default. I must have been testing something. Feel free to add the include or simply comment out those lines. They are only interesting with My latest branch update is working well with SRP and includes an improved logging messages when heap allocation fails. It would be great for you to take it for a test drive. |
|
@gojimmypi upgraded today to 5.7.0 and got new errors: |
|
@gojimmypi changed some settings: ESP32 works, but the ESP32C2 gives me the same error: So back to square one... |
|
Hi @AchimPieters - thank you so much for providing the The first thing that comes to mind with one device working but not another is your memory configuration: Note that the C2 has less RAM: 272 KB of SRAM (16 KB dedicated to cache) *1 vs the ESP32 that has 520 KB SRAM *2. Could you please provide all of the settings in your Also, I didn't see any setting for session caching. See the user_settings.h for the TLS Client Example. Smaller cache can save memory. That said, the most recent wolfSSL v5.6.0 does not include all of my changes. One thing in particular with is SHA interleaving improvements that I am still testing. I'm not referring to the HW interleave capability, but rather the current HW implementation with multiple, concurrent SHA calculations that typically occur in something such as SRP. I recently added #7262 that helps detect this. See the Espressif-specific wolfssl_test example. |
|
@gojimmypi Here is the complete Turning on stack smashing and/or heap corruption detection, didn't provide any useful information. I added Smaller cache: user_settings.txt but gave me the same error: |
|
Hello @AchimPieters TL;DR: The version of wolfSSL you are using does not have my SRP fix. Try this one. Here are my notes: Heads up the I tried to submit a request on the Visual Studio Developer Community without much luck. When using Linux and adding an upstream like this: I saw this So I ended up having to delete the entire repo and forking a fresh one. Ha! Today I also learned one cannot have two forks of the same repo, even if the first fork is renamed. In an any case, my new fork of esp32-homekit-demo seems to be much happier. Upon inspection, the first thing I noticed is that the esp32-homekit-demo wolfssl component appears to be a copy of the wolfSSL v5.7.0 Espressif Managed Component. Please note that not only have my SRP changes mentioned above not made it into the The good news, is that my 9x SRP testing. (all passing) commit at See the wolfssl_test app at that point in history on my fork. How to proceed? For me, I'd clone wolfssl at the root level of the project, with the same parent directory as Then in the
The CMakeLists.txt has a feature that searches for wolfssl or you can set an environment variable called Once you plug in my The big thing again is memory. You'll see in my user_settings.h I added a sanity check at the end: #if defined(CONFIG_ESP_MAIN_TASK_STACK_SIZE)
#if defined(WOLFCRYPT_HAVE_SRP)
#if defined(FP_MAX_BITS)
#if FP_MAX_BITS < (8192 * 2)
#define ESP_SRP_MINIMUM_STACK_8K (24 * 1024)
#else
#define ESP_SRP_MINIMUM_STACK_8K (28 * 1024)
#endif
#else
#error "Please define FP_MAX_BITS when using WOLFCRYPT_HAVE_SRP."
#endif
#if (CONFIG_ESP_MAIN_TASK_STACK_SIZE < ESP_SRP_MINIMUM_STACK)
#warning "WOLFCRYPT_HAVE_SRP enabled with small stack size"
#endif
#endif
#else
#warning "CONFIG_ESP_MAIN_TASK_STACK_SIZE not defined!"
#endifThe 28K is a very bare-minimum amount for the Here's the output from my test script showing the SRP passing on all devices:
Note I've also added some additional Let me know if you are able to test with my version of wolfSSL. I am certain we can get your Apple Homekit project working on every flavor of ESP32. Thank you again for your patience and persistence. Cheers. |
|
@gojimmypi thank you for the extensive work you have done, at the moment I am ill (Notting serious), but gave it a quick go: you can find the branch here: https://github.com/AchimPieters/esp32-homekit-demo/tree/RSP-WOLFSSL But now I got these errors: Maybe It will give you an idea right away, but for me, I have to put it on hold, until i'm better. |
|
@gojimmypi did some tweaking to But now I got a real strange one when compiling for esp32: And But when I'm looking into the source directory's: the I don't want to fiddle too much, because otherwise we don't remember what we did, don't you agree? Thanks for spending time on making a robust design and writing code and tests with best practices. It took you some extra effort, but this will benefit the product in the long run. |
|
Hi @AchimPieters sorry you are not well. I hope you are feeling better soon.
Ah yes. One of these days I will improve the
I was working on this a bit yesterday & saw the same message. This is related to a new feature moving some code like wifi and time to wolfssl helpers. It seems that when the wolfSSL component is in a different directory than the project being built, there's a problem finding the Espressif dependency. I've pushed some new code that disables the new libraries by default. "A code segment is work a thousand words". Let's try this: # Setup your ESP-IDF environment as needed.
# Any ESP-IDF v5.2 should work. This one shown for my WSL using VisualGDB:
WRK_IDF_PATH=/mnt/c/SysGCC/esp32/esp-idf/v5.2
. ${WRK_IDF_PATH}/export.sh
# Fetch a copy of esp32-homekit-demo
git clone --recursive https://github.com/gojimmypi/esp32-homekit-demo.git esp32-homekit-demo-gojimmypi
cd ./esp32-homekit-demo-gojimmypi
# Optionally set upstream
git remote add upstream https://github.com/AchimPieters/esp32-homekit-demo.git
# Fetch a copy of the gojimmypi wolfssl fork into current directory (from ./esp32-homekit-demo-gojimmypi)
git clone https://github.com/gojimmypi/wolfssl.git
# Checkout the desired commit:
cd wolfssl
git checkout a84feaba2454b4262f29dd9b1ee80465d00114c7
cd ..
# Still in esp32-homekit-demo-gojimmypi directory.
# Remove the existing component source for the published 5.7.0 version:
rm -rf ./components/wolfssl/examples
rm -rf ./components/wolfssl/src
rm -rf ./components/wolfssl/wolfssl
rm -rf ./components/wolfssl/wolfcrypt
rm ./components/wolfssl/.component_hash
rm ./components/wolfssl/idf_component.yml
# Get a recent version of wolfssl component CMake file:
cp ./wolfssl/IDE/Espressif/ESP-IDF/examples/template/components/wolfssl/CMakeLists.txt ./components/wolfssl/CMakeLists.txt
# Optionally set location of wolfSSL. The location of the clone in the parent should be found even without this:
# WOLFSSL_ROOT=/mnt/c/workspace/esp32-homekit-demo-gojimmypi/wolfssl
cd ./examples/led
idf.py set-target esp32
idf.py menuconfig
idf.py buildThe important things here are:
It is also important to ensure the calling freeRTOS stack (or your main app) has enough stack configured for SRP. I was thinking it might be useful (and a common testing ground, since I don't have any Apple products), if you'd like to try calling the wolfSSL test right before your connection test? When you get a chance, please give this a try and let me know how it goes. btw, while compiling I saw this "flash nearly full" warning: Thanks again for your help on this. Your project structure has definitely pointed out some weaknesses in my settings and cmake files. Cheers |
|
@gojimmypi Here are what I did and the results:
ESP32
ESP32C2
Unfortunally I did not got the If you need any specifics, please let me know, I'm happy to follow your steps. |
|
@AchimPieters that's curious the SRP is failing on your ESP32-C2, but not the ESP32. Do you have any other flavors to test with? Can you provide your stack and IRAM settings? Here are mine: IRAM
Stack
Heap
See also my: In particular, although the ESP8266 is configured for #define FP_MAX_BITS MIN_FFDHE_FP_MAX_BITS due to limited memory, the C2 is using the full-sized #define FP_MAX_BITS (8192 * 2). I think we tried this before, but what happens if you disabled all hardware acceleration? (There's limited capability in the ESP32-C2 anyhow) To disabled all HW acceleration: #define NO_ESP32_CRYPT
#define NO_WOLFSSL_ESP32_CRYPT_HASH
#define NO_WOLFSSL_ESP32_CRYPT_AES
#define NO_WOLFSSL_ESP32_CRYPT_RSA_PRILet's see what the results of the wolfssl_test are on your device. Would you please build and flash that onto your device and let me know the results? For completeness, here's my ESP32-C2 log showing a passing SRP test: I expect the SRP test to pass on your device. We can then compare if there are any configs in the user_settings.h and/or sdkconfig,defaults that are different from yours. It is possible that something else is going on, and the current SRP test is missing something that the Apple Homekit is doing. |
|
@gojimmypi Can you provide your stack and IRAM settings? Sure, here are mine: ESP32C2 IRAM: ESP32C2 STACK: ESP32C2 HEAP: regrading: disabled all HW acceleration: they are disabled already? |
|
@gojimmypi the results of the wolfssl_test are as following: ESP32
Here are the results: ESP32C2
Here are the results: So, I think I did everything you asked... |
aha! The first thing I notice is our sdkconfig settings differences, in particular the main task stack:
That alone is not necessarily the root cause, as I see you have several freeRTOS tasks, such as the one in led/main/main.c allocating only 2K stack. See the Espressif docs on There's also the components/homekit/src/server.c that appears to allocate only 1664 bytes if I don't recognize the There's a cmake definition in the esp32-button, and the homekit component but I'm not certain that the task calling the wolfSSL SRP sees that & the appropriate stack size. It might be a good idea to ensure we know the exact value of It is challenging for me to not have any of the Apple Homekit products. Are you aware of any emulation environments that I might be able to use to test? It would make this exercise much easier. You might also consider turning on stack smashing features to see if the code will tell us if indeed there's a stack problem. See the
Excellent! That at least confirms the SRP test is passing on your ESP32C2. Even more evidence this is a stack setting issue. |
|
@gojimmypi good to hear this gives more insight in the problem, regarding your question about an emulator, there are a few out there depending on which you have a good feeling, there is this one for example: https://dev.to/ianito/how-to-emulate-ios-on-linux-with-docker-4gj3 or I have an old iPhone, that I could send to you by mail? I'm going to look into the intel you provided... |
|
Hi @AchimPieters - I know you mentioned you've not been feeling well... so no rush here.. just wondering if you have an update on the ESP32-C2 SRP Homekit failure that you were seeing? I took a brief look at some of the Apple emulators and simulators. One cannot deny the simplicity of testing on real hardware. If you are still seeing problems & have a loaner iPhone that I can for testing, that would be great! That's a very generous offer. Please reach out to me via email: jim (at) wolfssl.com In return I can probably arrange to send you some wolfssl swag & I'll of course return the device upon completion of our exercise. |
|
@gojimmypi no update yet, I'm going to try doing some test this weekend ;) I'm currently a little behind, but I'll be fine! I will email you, to discuss some things regarding the iPhone. |
|
Okay, let's start from my repro at this moment: https://github.com/AchimPieters/esp32-homekit-demo with my current user_settings.h and go from here... |
|
@AchimPieters - excellent! I believe I have all the issues worked out. Having the iPhone was quite helpful. Thank you again. See your PR AchimPieters/esp32-homekit-demo#3 and wolfSSL #7505. For reference, here are my instructions to test on my fork: |
|
That's fantastic news! It's great to see progress being made. However, despite following all your instructions, I wasn't able to reproduce it. Even after accepting your merge request and trying again, I still couldn't get it to work. I suspect the difference in operating systems, Windows versus macOS, might be causing the issue. I had to revert the merge again. Additionally, the changes to the local, static, stale copy of wolfSSL are causing complications, along with the fact that I'm using Docker. I'd prefer to use wolfSSL via https://components.espressif.com/ because I've built this repro for beginners, so they can start with creating a HomeKit device in a simple and educational way. For this reason, I'd like to offer a repro that includes all the necessary components to start without any extra steps. Once again, it's amazing that it worked for you! Now, I'll need to figure out how to make it work on my platform. |
Yes! I'm confident we'll be able to get this working properly.
I'll need a little more than "couldn't get it to work", please. New error messages? Some of the changes to your code in my repo are essential to getting the ESP2-C2 to work, as well as changes to wolfSSL: Key to this working is also the merge of #7505 into wolfSSL, which has not occurred yet. You can continue to test with my branch, if you'd like. Any other option is unlikely to succeed without code changes.
I'll need specifics to "complications" in order to be able to help. There must be changes to wolfSSL in order for the ESP32-C2 to work properly for all your Homekit examples and all the Espressif targets. I'm particularly interested in the value of
I'm using the Espressif v5.2. If you are using the same version, I think it is highly unlikely (though not impossible) that OS difference would cause problems. I need to see the errors you are encountering.
Yes, I agree, however that's not going to happen today, nor in the immediate future, at least not for the official wolfSSL. I do however, have a staging instance of wolfssl called Using the managed component would also address any possible license issues of distributing wolfSSL source code with your project or anyone else that uses it and distributes it. I suggest trying my PR-wolfssl branch of your repo, even making wolfSSL a temporary, static local copy with my wolfSSL PR Branch called I assumed you'd do the testing as noted in AchimPieters/esp32-homekit-demo#3 instruction before merging. The instructions there are for the forks and branches. The most important thing to look for is the value of We need to also ensure you are not using wolfSSL in the ESP-IDF components. (see When following those instructions, I'd like to see the value of I'd like to see full build/flash logs and any relevant device output on the serial monitor, please. I realize that we're 9 time zones apart and it is later for you at the moment, but if you can get that to me today, I'll work on it today. Thanks so much for your persistence. We're really close, and I am completely confident we'll have a solid solution soon. |
|
@gojimmypi Her is what I tried so far: Followed your instructions, as far as the are applicable on my system (macOS), I made a shell script (.sh) file and run it: with this as result: Then I started my ESP-IDF environment (docker), Notice I run it from the main dir 'test-homekit', so all dirs are included!
with this as the result As you can see the error: So I looked at 'set(WOLFSSL_ROOT "c:/workspace/wolfssl-gojimmypi")' You use 'c:/.....' That doesnt work on my mac and tried to change it to several paths but without anny result... There has to be an easier way, as said here above 'because I've built this repro for beginners', Just say your reply, gonna read that now ;) |
Aha! yes. Cool. I see the problem. I'm so sorry. My bad. I thought I commented that out. That certainly explains why it worked on my machine and not yours. The local cmake assignment takes precedent over environment variables and searching parent directories for wolfSSL source: Try setting that to the path of your local copy of my wolfssl branch Specifically edit line 33 of your You can either set a static value for our testing, or comment it out and use the environment variable. Once editing the file to comment it out, you might as well put in a static value for the wolfSSL location. |
Oh, and as for that: yes, I completely agree. I had not expected you to merge the changes without testing. For an interim solution, I think setting the environment variable for the location of wolfSSL source code is fairly straightforward for beginners. I've confirmed that simply commenting out the The cmake file will automatically find I've updated my branch commenting out that path. Once my wolfSSL PR #7505 gets merged and there's a new, official stable release (probably in a couple of months), the wofssl Managed Component is definitely the way to go, as you stated. Let's get it confirmed working for you and then we can do some polishing. |
|
@gojimmypi I have made progress!! Here is what I did: I took my working repro, then I cloned: Replaced the directories, Then I started compiling as always, I saw these warnings for the ESP32 module: But it compiled and worked under HomeKit as usual. Then the test for the ESP32C2 and once again the warnings: But it compiled and worked under HomeKit!! so progress! Here is the update repro: https://github.com/AchimPieters/esp32-homekit-demo |
|
Hi @AchimPieters !
YAY! That's excellent!!
oof, that's a bit of a brute-force method, but I'm glad it worked for you!
Those warnings are because you didn't replace the It's no big deal... it's just what it says: some files "do not need to be compiled separately from ssl.c". I'll refresh my fork from your changes & create a new PR soon. The important thing is you are using the changes in wolfSSL PR #7505 (in particular the changes to Thank you again for all your cooperation. I'm so glad it is working for you. Cheers! |
|
Hello @AchimPieters - I've created AchimPieters/esp32-homekit-demo#6 that adds Apple HomeKit support using wolfSSL as a Managed Component. Pre-release version See: https://components.espressif.com/components/wolfssl/wolfssl/versions/5.7.1-preview2e I've only updated the LED example. I've included instructions in the README on adding this to other examples. Basically just do this from the and ensure the
|
Version
5.6.6
Description
Follow-up on #7155
For reproduction and latest changes, see: https://github.com/AchimPieters/esp32-homekit-demo
The text was updated successfully, but these errors were encountered: