this issue is mainly exposed when using larger (4096) client key in TLS mutual auth,
since it uses multiplications > 2048 when mbedtls_mpi_mul_mpi is used in recursion,
which works only if both operands point to different location than result since
mpi_mult_mpi_overlong() called mbedtls_mpi_grow() to reallocate buffers used in previous
pointer arithmetics and thus corrupting it. Fixed by growing the mpi buffer before
calling mpi_mult_mpi_overlong()
The following commit refactors the CAN driver such that
it is split into HAL and Lowlevel layers. The following
changes have also been made:
- Added bit field members to can_message_t as alternative
to message flags. Updated examples and docs accordingly
- Register field names and fields of can_dev_t updated
tcp_transport/ws_client: websockets now correctly handle messages longer than buffer
Closes IDF-1084 and IDF-1083
See merge request espressif/esp-idf!6740
For SoftAP provisioning, if we start Wi-Fi connection as soon as the
apply config request is received, it has been observed that the clients
(Phone apps mostly) do not get the response for this as we switch the
Wi-Fi channel, causing a momentary disconnection.
Delaying the connection calls helps mitigate the issue.
Signed-off-by: Piyush Shah <piyush@espressif.com>
transport_ws can now be read multiple times in a row to read frames larger than the buffer.
Added reporting of total payload length and offset to the user in websocket_client.
Added local example test for long messages.
Closes IDF-1083
DISABLED_FOR_TARGETS macros are used
Partly revert "ci: disable unavailable tests for esp32s2beta"
This partly reverts commit 76a3a5fb48.
Partly revert "ci: disable UTs for esp32s2beta without runners"
This partly reverts commit eb158e9a22.
Partly revert "fix unit test and examples for s2beta"
This partly reverts commit 9baa7826be.
Partly revert "efuse: Add support for esp32s2beta"
This partly reverts commit db84ba868c.
The upper transport layer is using big endian ordering. The
PreviousAddress field of a Friend Request message should therefore
be converted to native endianess using sys_cpu_to_be16().
If the duration to publish is roughly the same as the period, we might
end up with elapsed == period, which returns 0 and cancel the periodic
publication. Instead 1 should be returned, just like when the elapsed
time is greater than the period.
Previously the FastPeriodDivisor value was introduced to the model
publication struct. Based on the way it was grouped it seems the
intention was to fit it within the same octet as other bit fields,
but it actually makes the octet overflow by one bit. This ends up
creating another u8_t variable which in turn adds 24 bits of padding
after it.
To keep the size of the struct as compact as possible, group the flag
together with the key index, since that only requires 12 bits. Some
care is needed here, since the mesh stack does have special internal
key index values that require more than 12 bits such as
BLE_MESH_KEY_UNUSED and BLE_MESH_KEY_DEV. In this case restricting
ourselves to 12 bits is fine since the value in the model publication
struct follows 1:1 the value received in the Config Model Publication
Set message, and there the parameter is defined to be exactly 12 bits.
For Low Power node and Proxy Server, the two features
depend on BLE_MESH_NODE in Kconfig.in, here in the
stack there is no need to judge if CONFIG_BLE_MESH_NODE
is enabled.
According to Mesh Spec 3.4.5.3, a node shall implement a local
network interface. And here we limit the situation just based
on the spec, and Provisioner directly sending the msg without
passing through the local network interface.
The 16-bit format group addresses will be stored,
but we don't store (or restore) the virtual label UUIDs,
i.e. after a power cycle the 16-bit group addresses
would be meaningless.
Creates macros for determining model message lengths based on opcode,
payload length and MIC size. Also adds macro wrapping
NET_BUF_SIMPLE_DEFINE to serve the most common use case.
Re-encrypts single-segment application messages when the network seqnum
has changed, to avoid encrypting messages with different seqnums in
network and transport. This operation is only required for unsegmented
messages, as segmented messages don't need to use the same seqnum in
network.
Reinstates the special adv data for friend messages to store the app key
index.
Stores friend queue packets unencrypted, removing any out-of-order
issues caused by seqnum allocation. Also moves as much of the metadata
storage as possible into the packet, allowing us to free up some bytes
of net_buf user data for friend packets.
newlib/assert: replace unlikely with likely to keep original assertion
newlib/assert: fix assert macro that uses likely
freertos/port: add the missing sdkconfig.h back
newlib/assert: assert macro back to a single line
esp_common/esp_compiler: renamed esp_macros file to a more specific one
esp_common/esp_compiler: removed CONTAINER_OF macro, it was a duplicate
components/freertos: placed likely macros around port and critical sections
component/freertos: placed likely macros on lists module
components/freertos: placed unlikely macros inside of assertion points, they likely wont fail
components/freertos: added likely macros on queue modules
FreeRTOS queues are one of most hot code path, because to queues itself tend to
be used a lot by the applications, besides that, queues are the basic primitive
to form both mutexes and semaphores, The focus here is to place likely
macros inside lowest level send and receive routines, since they're common
from all kobjects: semaphores, queues, mutexes and FR internals (like timer queue)
components/lwip: placed likely/unlikey on net-interfaces code
components/fatfs: added unlikely macros on disk drivers code
components/spiffs: added unlikely macros on low level fs driver
components/freertos: added likely/unlikely macros on timers and ticker
freertos/event_group: placed likely/unlikely macros on hot event group code paths
components/sdmmc: placed likely / unlikely macros on lower level path of sdmmc
components/bt: placed unlikely macros around bt HCI functions calling
components/lwip: added likely/unlikely macros on OS port code section
components/freertos: fix code style on tick handler
On Xtensa, backtrace can not recover the two most significant bits of
the address, as the window call size is encoded in these bits.
Because of this, __builtin_return_address modifies these MSBs to
match those of the callee, "fixing" the address. An unfortunate side
effect is that the zero return address, which usually terminates the
backtrace, gets converted to 0x40000000. While there is a valid
instruction at this address, its occurrence in the backtrace is
highly unlikely: this is the first instruction of WindowOverflow4
vector, and IDF apps switch VECBASE to an IRAM location very early at
startup.
