Closed enricop closed 4 years ago
Hi Enrico,
Which transport you use? Assuming it's mqtt over ssl, so one issue which you might have just bumped into is that the payload gets silently truncated on transport layer.
From the sdkconfig: CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=8192
Could you please try to enlarge this value to a theoretical maximum of TLS packet (~40k as well) to see if the problem goes away?
PS: If it was the case, please note that we already have a fix in IDF (fragmenting data on esp-tls layer) PPS: About mqtt buffer: Publishing messages larger than mqtt buffer is supported too, and should work correctly.
Hi @david-cermak
thank you! we put CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN to 16k and set mqtt buffer size to 16k as well.
We will test this afternoon the sending of a big payload to verify outgoing message fragmentation is done inside the mqtt component.
PS: If it was the case, please note that we already have a fix in IDF (fragmenting data on esp-tls layer)
are you referring to this commit ?
PS: If it was the case, please note that we already have a fix in IDF (fragmenting data on esp-tls layer)
are you referring to this commit ?
I meant this one ragmenting on esp-tls layer. The one you're referring to is fragmenting on mqtt level
@enricop Closing as resolved in this esp-idf commit: https://github.com/espressif/esp-idf/commit/a9e63d947bc864a2aaa30389c911777f362f93b1. Please reopen if needed
Hi @david-cermak
we are publishing with
esp_mqtt_client_publish()
function this payload: passed_to_API_payload.txtIt is 13434 bytes
What is actually sent on the wire by the MQTT component is this payload: published_payload_error.txt
In the second attachment you can see that at line 234 the payload it is corrupted (it contains actually the string of the topic). After line 234 the payload it is actually repeated.
Fundamentally the sent payload has the same size (13421 bytes), but the content is cutted out and repeated.
We have a 40k buffer size for send/receive: sdkconfig.txt