Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I'm attempting to make an HTTP request of about 2541 bytes. It worked fine using HTTP, but now I'm trying to use HTTPS, and I'm having trouble with multiple packets. When I tried smaller requests (~370 bytes) it succeeds just fine
I run into the assert in wiced_https_get()->wiced_tcp_send_buffer()->wiced_tcp_send_packet()->wiced_tls_encrypt_packet()->wiced_packet_set_data_end().
It's asserting because data_end is always 5 bytes larger than packet->nx_packet_data_end.
I know the packet pools are created with a size of 1548 bytes, and it's trying to send a packet size of ~1384 bytes.
Any clue why this might be happening? Is there some macro that I should look into changing?
I'm not entirely sure about how this assert is failing, but here is another reference point.
Unlike HTTP that uses byte stream oriented writes, for HTTPS TLS each write is encapsulated as TLS message, including HMAC and encrypted payload. This is not something unique to WICED, but is part of how the TLS standard is defined and interoperates.
In practice this requires an internal TLS transmit buffer big enough for the message.
As you already discovered, if you write smaller message payloads it works,
but if you go over the limit it stops.
In later releases of uSSL SDK included in WICED, the secure socket API adds a new function ussl_write_chunked()
that breaks down an arbitrary size payload write into smaller TLS message chunks.
Try just adding something similar in your application, tune it to