lwIP - A Lightweight TCP/IP stack - Bugs: bug #65388, MQTT infintie loop if incoming...
You are not allowed to post comments on this tracker with your current authentication level.
bug #65388: MQTT infintie loop if incoming pbuf chained
Submitter: | Alexander <pronkin> | ||
Submitted: | Fri 01 Mar 2024 08:38:15 AM UTC | ||
Category: | apps | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | 2.2.0 |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Powered by Savane 3.13-aa77.
Corresponding source code
in this commit the optimisation added in line 891
this cause to infintie loop if p is chained (two or more pbufs), because when whe move on next pbuf
cpy_len become zero and we never processed more data. here is the log:
Proper version of this must look like (same as check in pbuf_get_contiguous)
with this fix, I successfully received large files without fails.
The next is optimization part (my proposals)
Since zero copy always perform so pbuf_get_contiguous never use our rx_buffer
it may be replaced with
More over, since our rx_buffer is not used, it is not necessary to limit cpy_len to available space in buffer
this leads to the following that bigger parts of data process directly from pbufs in mqtt_message_received and user app (not by peaces).
However there is a LWIP_ERROR in mqtt_message_received that check data fits in rx_buffer
I found out that no problems occur to process bigger data.
Also docs mention that app callbacks data valid only before callback returns without limiting its size.
So I deleted this check and ran some tests.
Everything works ok. I received larger peaces of data in app callback
and overall download time of large file (~600K) decreased from 5min to 1min.