RAK3312+Zephyr+Wifi+LoRa

Please include the following information, in order for us to help you as effectively as possible.

  • RAK3312
  • Zephyr v4.3.0

Has anyone successfully configured and compiled a Zephyr app that enables both LoRa and Wifi? I am getting duplicate definitions of aes_encrypt. I’ve found three so far that get pulled into the build and they do not have the same signature.

  • lorawan-node
  • wpa_supplicant (from ESP32 wifi)
  • mbedtls

All the above have implementations that conflict. Is this a common configuration/problem or am I just special :slight_smile: ?

jk

Hi @jkeane ,

I relayed the issue to our engineers.

This is their recommenation.

One practical fix is to namespace the AES symbols used by LoRaMac-node when CONFIG_HAS_SEMTECH_SOFT_SE is enabled. For example, in zephyr/modules/loramac-node/CMakeLists.txt, we can add compile definitions to rename the LoRaMac-node AES symbols:
aes_encrypt=loramac_aes_encrypt, aes_set_key=loramac_aes_set_key, etc.

Another option is to avoid Zephyr’s native LoRaWAN stack and use usp-zephyr instead. Since usp-zephyr uses a different LoRaWAN integration path, it should avoid this specific LoRaMac-node AES symbol conflict.


Thanks for checking. I’ve actually created a patch file to patch the soft-se implementation. If interested, I can provide the file. This is for Zephyr v4.3.0.
Also ran into some interesting fun with restarting the device with stored wifi credentials. It seems it puts a great deal more stack pressure on the Main stack causing a hard crash. I had to bump the main stack size up to 4096 to handle it. TBH, i have a bunch of other sys init going on before my main thread starts to all of it together push the boot into a panic.

I’ll also check out usp-zephyr. It looks young and not broadly tested against other zephyr versions, but it may be an option to consider.