[lwip-devel] [bug #61558] Possibly faulty behaviour on receiving large payloads with mqtt+tls causing disconnect

[Tove Rumar]

URL:
  <https://savannah.nongnu.org/bugs/?61558>

                 Summary: Possibly faulty behaviour on receiving large
payloads with mqtt+tls causing disconnect
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: evot1
            Submitted on: Thu 25 Nov 2021 01:01:37 PM UTC
                Category: pbufs
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 2.1.0

    _______________________________________________________

Details:

We are using 
When receiving packets that are larger than PBUF_POOL_BUFSIZE  with mqtt using
tls, the packets are not being chained correctly in altcp_tls_mbedtls.c. 

Data arrives in  altcp_mbedtls_handle_rx_appldata and are decrypted using
"mbedtls_ssl_read", and put in pbuf. 
Thereafter the pbuf should be chained if there is any unreceived pbufs still
in state-rx_app. 

This never happens since the pbuf is emediately passed to the application with
altcp_mbedtls_pass_rx_data. 
Mqtt does no sanity check to see if the received packet is a full packet with
header or not. Thus not returning an error when it receives only the first
PBUF_POOL_BUFSIZE bytes of a packet that should have another pbuf chained
after it. 
Since error is not returned back to altcp_mbedtls_pass_rx_data the
state->rx-app is set to NULL and the next part of the decoded message coming
out from "mbedtls_ssl_read" is never concated with the previous one. 
This pbuf is lacking mqtt headers since it should have been the tail of the
previous packet (pbuf-chain) and the mqtt stack can not deal with a headerless
packet, and random disconnects happen because the payload is being interpreted
as header data. 

Might this be bug or should this be handled somewhere else?

We think this fix have solved the issue but we are not sure if it should be
handled in a different way. 
We added an if check to see if the full incomming buffer is decoded. 

in "altcp_mbedtls_handle_rx_appldata" func:

if (state->ssl_context.in_msglen==0) {
   err = altcp_mbedtls_pass_rx_data(conn, state);
}






    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?61558>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/