Cannot receive large MQTT packets. Was the problem with large MQTT packets on WICED ever fixed?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
PeRa_4144941
Level 2
Level 2
First solution authored First like received First reply posted

Hi All,

I saw this older post: https://community.cypress.com/t5/forums/searchpage/tab/message?advanced=false&allow_punctuation=fals...

and have recently run into the exact same problem with the CYW43907, and WICED Studio v6.4.  When using secure MQTT with TLS, we can transmit large packets (50 KB say), but we cannot receive them.  We see TCP receive errors, 0 sized TCP windows, and then we get disconnected from the MQTT broker with a "socket error".  The same large message works great without TLS.  We are using NetX Duo by the way.  Was the problem (originally reported back in 2018) ever fixed?

 

0 Likes
1 Solution
PeRa_4144941
Level 2
Level 2
First solution authored First like received First reply posted

It's actually a really easy fix...  We just need to replace the single call to wiced_tcp_receive() in  mqtt_process_tcp_receive() in libraries/protocols/MQTT/mqtt_network.c with a while() loop.  In other words, keep on calling wiced_tcp_receive() in that function while there are still data fragments in the packet to consume.  It works wonders, not unlike Double Diamond in fact.

Allegedly some other protocols in the WICED code may suffer from the same problem; this one for example: https://community.cypress.com/t5/WICED-Studio-Wi-Fi-Combo/Can-t-receive-the-data-larger-than-1447-by... so maybe the same fix needs to be applied there as well.

There's another problem in mqtt_network.c too by the way.  If we get unexpectedly disconnected from the broker while in the middle of receiving a large MQTT message (because of the first bug described above), then we cannot reconnect to the broker afterwards.  You need to add this:

if ((conn != 0) && (conn->cached_frame.data_pending != 0))
conn->cached_frame.data_pending = 0;

     to the MQTT_DISCONNECT_EVENT: case in mqtt_thread_main(), and it too works wonders.

And yes, you can now close this case and mark this as the accepted solution, and maybe update that old case from 2018 to point to this solution too.

View solution in original post

2 Replies
PeRa_4144941
Level 2
Level 2
First solution authored First like received First reply posted

It's actually a really easy fix...  We just need to replace the single call to wiced_tcp_receive() in  mqtt_process_tcp_receive() in libraries/protocols/MQTT/mqtt_network.c with a while() loop.  In other words, keep on calling wiced_tcp_receive() in that function while there are still data fragments in the packet to consume.  It works wonders, not unlike Double Diamond in fact.

Allegedly some other protocols in the WICED code may suffer from the same problem; this one for example: https://community.cypress.com/t5/WICED-Studio-Wi-Fi-Combo/Can-t-receive-the-data-larger-than-1447-by... so maybe the same fix needs to be applied there as well.

There's another problem in mqtt_network.c too by the way.  If we get unexpectedly disconnected from the broker while in the middle of receiving a large MQTT message (because of the first bug described above), then we cannot reconnect to the broker afterwards.  You need to add this:

if ((conn != 0) && (conn->cached_frame.data_pending != 0))
conn->cached_frame.data_pending = 0;

     to the MQTT_DISCONNECT_EVENT: case in mqtt_thread_main(), and it too works wonders.

And yes, you can now close this case and mark this as the accepted solution, and maybe update that old case from 2018 to point to this solution too.