This commit adds a new feature to generate a salt and verifier pair for a given username and
password during the provisioning process. This is useful in scenarios where the pairing pin is
randomly generated and shown via some interface such as a display or console.
- Uses the provided username and password to generate a salt and verifier pair
- Adds support for dev mode where the pin/password can still be read from flash
In esp_eth_test_apps.c:
Add test of loopback functionality. Change speed/duplex/autonegotiation test - remove need to enable loopback (required
for it to work on some phys supported by ESP-IDF)
In Kconfig.projbuild:
Add parameters to select which configuration is used - standard or custom.
Add for custom configuration parameters to select MDC and MDIO pins (required to work with WESP-32 and other boards that
use non-standard pin assignments).
In esp_eth_test_common.c:
Add code to support changes made in Kconfig
In sdkconfig.ci.default_rtl8201:
Change config which is used. Now custom is used and MDC is gpio 16, MDIO is gpio 17. Reuqired to work with WESP-32
In esp_eth_phy_802_3.h:
Make 802.3 API public.
In esp_eth_phy_802_3.c:
Add loopback check in eth_phy_802_3_set_duplex(). Now ESP_ERR_INVALID_STATE is invoked on attempt to set duplex to half
when loopback is enabled.
Remove static property from esp_eth_phy_802_3_autonego_ctrl and esp_eth_phy_802_3_loopback.
In esp_eth_phy_dm9051.c:
Add dm9051_loopback() because DM9051 requires setting additional bit to enable auto-negotiation loopback for data to be
received. Add dm9051_set_speed() which invokes ESP_ERR_INVALID_STATE on attempt to set speed to 10 Mbps when loopback is
enabled because such speed configuration is unsupported.
In esp_eth_phy_ksz80xx.c:
Add ksz80xx_set_speed() which invokes ESP_ERR_INVALID_STATE on attempt to set speed to 10 Mbps when loopback is enabled
because such speed configuration is unsupported.
In esp_eth_phy_ksz8851snl.c:
Change phy_ksz8851_set_duplex() to invoke ESP_ERR_INVALID_STATE on attempt to set duplex to half when loopback is enabled.
In esp_eth_phy_dp83848.c, esp_eth_phy_rtl8201.c:
Add autonego_ctrl implementation which prevents enabling autonegotiation when loopback is enabled.
Add loopback implementation which disables autonegotiation prior to enabling loopback.
In esp_eth_phy_lan87xx.c:
Add autonego_ctrl implementation which prevents enabling autonegotiation when loopback is enabled.
Add loopback implementation which disables autonegotiation prior to enabling loopback.
Fix link indicating being down when loopback is enabled by force setting link up.
This commit removes the lock from the list manipulation code in esp_netif_objects.c,
because we already have another lock/task context for lwip.
So the list manipulation is unsafe and safety must be assured by the stack layer
(in esp_netif_lwip).
Problems with current locking:
* implementation of locking was wrong -- lazy init style of creating the mutex is not
thread safe (and destroying it if we have no interface makes the problem exhibit very frequently)
* locking only the list won't solve issues when assessing interfaces atomically
* maintaining multiple locks is problematic, as we often switch between
lwip context and user context in internal implementation of esp_netif_lwip
Closes https://github.com/espressif/esp-idf/issues/12261
fix(esp_pm): fix psram access failed after pd_cpu wakeup if uart driver driven console is used (backport v5.1)
See merge request espressif/esp-idf!27051
Used esp-rom tag esp32s3-20210327 and did manual cleanup.
Rename s_usb_osglue to rom_usb_osglue like it was done for esp32s2.
Some comments in esp32s2 headers are synced from esp32s3.
- Add ECDSA peripheral chapter and instructions to program efuse key block
- Update security guide for ECDSA peripheral mention for device identity
- Link with ESP-TLS guide about using ECDSA peripheral in TLS connection
For ESP32-H2 case, the hardware k mode is always enforced through
efuse settings (done in startup code).
For ESP32-P4 case, the software k mode is not supported in the peripheral
itself and code was redundant.
In ESP32-H2, the ECDSA peripheral by default uses the TRNG (hardware)
generated k value but it can be overridden to software supplied k.
This can happen through by overriding the `ECDSA_SOFTWARE_SET_K` bit
in the configuration register. Even though the HAL API is not exposed
for this but still it could be achieved by direct register
programming. And for this scenario, if sufficiently random k is not
supplied by the software then it could posses a security risk.
In this change, we are unconditionally programming the efuse
`ESP_EFUSE_ECDSA_FORCE_USE_HARDWARE_K` bit during startup security
checks itself. Additionally, same is ensured in the `esp_efuse_write_key`
API as well. This always enforces the hardware k mode in the ECDSA
peripheral and ensures strongest possible security.
From: Arno Moonen <arno.moonen@airios.eu>
Follows original message from Arno Moonen <arno.moonen@airios.eu>
While integrating the ESP-IDF into our existing CMake structure,
I've come across quite some hurdles. Most I've been able to fix
in our CMake files, however this one I could not.
Most of the targets created by the esptool_py component assume
that the EXECUTABLE IDF build property (which contains the name
of the CMake executable target) always equals the name of the
created binary.
This is however not always true. For instance, in our setup we use
CMAKE_EXECUTABLE_SUFFIX_C and CMAKE_EXECUTABLE_SUFFIX_CXX in our
toolchain file (both set to .elf). If we do add_executable(my_app),
the target binary file would actually be my_app.elf.
In order to fix this, I've updated it to use the TARGET_FILE generated
expression. That way we also no longer need the EXECUTABLE_DIR IDF build
property here.
I've fixed this on v5.0.1 (as that's the ESP-IDF version I'm currently
trying to integrate), but I assume it should be easy to apply the same
fix to newer versions and the master branch as well.
Note that this problem might exist in multiple places where EXECUTABLE
is being used. While going through the ESP-IDF code base, I even noticed
that a few places actually already seem to use the TARGET_FILE expression.
To be honest the property name might be somewhat confusing as well, as it
is actually the executable target.
Closes https://github.com/espressif/esp-idf/pull/12558
1. Added new API functions that can add 32 and 128-bit UUID to the EIR data
when these UUIDs are set in SDP.
The old functions that only work with 16-bit UUIDs have been left
unchanged to avoid having to redo code that already utilizes them.
2. Fixed bug with zero handler return in btc_sdp.c
sdp_create_record.handle in tBTA_SDP struct wasn't saved before.
Because of it Bluetooth stack always returned zero handler to
application callback.
Closes https://github.com/espressif/esp-idf/issues/11529
