[lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, updated. STABLE-2_1_0_RELEASE-266-g534d3a7

[Dirk Ziegelmeier]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "lwIP - A Lightweight TCPIP stack".

The branch, master has been updated
       via  534d3a794c0e6a065ec4a9e60565093151ec77f1 (commit)
       via  fc8f6e8fd9599de011d8cc85da78aa4c06bc7ff0 (commit)
       via  df0699c143842e656176dfe65d89e183e697ef53 (commit)
      from  156bb74d17303683be46874a2d626365cb97ab7d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 534d3a794c0e6a065ec4a9e60565093151ec77f1
Author: Dirk Ziegelmeier <address@hidden>
Date:   Tue Apr 30 13:05:50 2019 +0200

    Minor compile fix for last commit

commit fc8f6e8fd9599de011d8cc85da78aa4c06bc7ff0
Author: David Girault <address@hidden>
Date:   Thu Apr 4 12:03:12 2019 +0200

    mqtt: fix first packet checking which fail if MQTT_VAR_HEADER_BUFFER_LEN > 
1516
    
    If client reception buffer is bigger than the first frame we receive, the 
first packet test
    will always fail for the second one if it is shorter the the diffence 
between reception
    buffer size and first frame length.
    
    For example, if we receive a PUBLISH message with length = 1517 (payload 
len = 1514 +
    header len = 3), this result in total message length of 1517.
    
    altcp_tls will send MQTT client frame up to 1516 bytes max. This result to 
PUBLISH
    message splitted in two frame: first is 1516 bytes, the second of 1 bytes.
    
    If MQTT_VAR_HEADER_BUFFER_LEN is 1520 (1516 + 4 bytes for stored fixed 
header), the
    second frame of 1 bytes is considered as first publish frame because
    client->msg_idx (1517) < MQTT_VAR_HEADER_BUFFER_LEN (1520).
    
    This result in disconnection AND application callback never called for the 
end of the
    payload.
    
    The fix will check `(client->msg_idx - (fixed_hdr_len + length)) == 0` 
which can be
    only true for the first frame of a message.
    
    Below logs showing the bug:
    ```
    April 3rd 2019, 23:14:05.459    lwip_dbg    mqtt_parse_incoming: Remaining 
length after fixed header: 1514
    April 3rd 2019, 23:14:05.460    lwip_dbg    mqtt_parse_incoming: msg_idx: 
1516, cpy_len: 1513, remaining 1
    April 3rd 2019, 23:14:05.460    lwip_dbg    mqtt_incomming_publish: 
Received message with QoS 1 at topic: v2/inte...
    April 3rd 2019, 23:14:05.461    lwip_dbg    mqtt_parse_incoming: Remaining 
length after fixed header: 1514
    April 3rd 2019, 23:14:05.461    lwip_dbg    mqtt_parse_incoming: msg_idx: 
1517, cpy_len: 1, remaining 0
    April 3rd 2019, 23:14:05.461    lwip_dbg    mqtt_message_received: Received 
short PUBLISH packet
    ```

commit df0699c143842e656176dfe65d89e183e697ef53
Author: David Girault <address@hidden>
Date:   Wed Jan 30 15:53:30 2019 +0100

    mqtt: support mostly zero-copy message analysis
    
    also ensure no parts of message are lost because cpy_len != buffer_space!

-----------------------------------------------------------------------

Summary of changes:
 src/apps/mqtt/mqtt.c | 49 +++++++++++++++++++++++++++++--------------------
 1 file changed, 29 insertions(+), 20 deletions(-)


hooks/post-receive
-- 
lwIP - A Lightweight TCPIP stack