mirror of
https://github.com/lwip-tcpip/lwip.git
synced 2024-11-16 23:15:37 +00:00
lwIP mirror from http://git.savannah.gnu.org/cgit/lwip.git
fc8f6e8fd9
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 ``` |
||
---|---|---|
.vscode | ||
contrib | ||
doc | ||
src | ||
test | ||
.gitattributes | ||
.gitignore | ||
.travis.yml | ||
BUILDING | ||
CHANGELOG | ||
CMakeLists.txt | ||
COPYING | ||
FEATURES | ||
FILES | ||
README | ||
travis.sh | ||
UPGRADING |
INTRODUCTION lwIP is a small independent implementation of the TCP/IP protocol suite. The focus of the lwIP TCP/IP implementation is to reduce the RAM usage while still having a full scale TCP. This making lwIP suitable for use in embedded systems with tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM. lwIP was originally developed by Adam Dunkels at the Computer and Networks Architectures (CNA) lab at the Swedish Institute of Computer Science (SICS) and is now developed and maintained by a worldwide network of developers. FEATURES * IP (Internet Protocol, IPv4 and IPv6) including packet forwarding over multiple network interfaces * ICMP (Internet Control Message Protocol) for network maintenance and debugging * IGMP (Internet Group Management Protocol) for multicast traffic management * MLD (Multicast listener discovery for IPv6). Aims to be compliant with RFC 2710. No support for MLDv2 * ND (Neighbor discovery and stateless address autoconfiguration for IPv6). Aims to be compliant with RFC 4861 (Neighbor discovery) and RFC 4862 (Address autoconfiguration) * DHCP, AutoIP/APIPA (Zeroconf), ACD (Address Conflict Detection) and (stateless) DHCPv6 * UDP (User Datagram Protocol) including experimental UDP-lite extensions * TCP (Transmission Control Protocol) with congestion control, RTT estimation fast recovery/fast retransmit and sending SACKs * raw/native API for enhanced performance * Optional Berkeley-like socket API * TLS: optional layered TCP ("altcp") for nearly transparent TLS for any TCP-based protocol (ported to mbedTLS) (see changelog for more info) * PPPoS and PPPoE (Point-to-point protocol over Serial/Ethernet) * DNS (Domain name resolver incl. mDNS) * 6LoWPAN (via IEEE 802.15.4, BLE or ZEP) APPLICATIONS * HTTP server with SSI and CGI (HTTPS via altcp) * SNMPv2c agent with MIB compiler (Simple Network Management Protocol), v3 via altcp * SNTP (Simple network time protocol) * NetBIOS name service responder * MDNS (Multicast DNS) responder * iPerf server implementation * MQTT client (TLS support via altcp) LICENSE lwIP is freely available under a BSD license. DEVELOPMENT lwIP has grown into an excellent TCP/IP stack for embedded devices, and developers using the stack often submit bug fixes, improvements, and additions to the stack to further increase its usefulness. Development of lwIP is hosted on Savannah, a central point for software development, maintenance and distribution. Everyone can help improve lwIP by use of Savannah's interface, Git and the mailing list. A core team of developers will commit changes to the Git source tree. The lwIP TCP/IP stack is maintained in the 'lwip' Git module and contributions (such as platform ports) are in the 'contrib' Git module. See doc/savannah.txt for details on Git server access for users and developers. The current Git trees are web-browsable: http://git.savannah.gnu.org/cgit/lwip.git http://git.savannah.gnu.org/cgit/lwip/lwip-contrib.git Submit patches and bugs via the lwIP project page: http://savannah.nongnu.org/projects/lwip/ Continuous integration builds (GCC, clang): https://travis-ci.org/lwip-tcpip/lwip DOCUMENTATION Self documentation of the source code is regularly extracted from the current Git sources and is available from this web page: http://www.nongnu.org/lwip/ Also, there are mailing lists you can subscribe at http://savannah.nongnu.org/mail/?group=lwip plus searchable archives: http://lists.nongnu.org/archive/html/lwip-users/ http://lists.nongnu.org/archive/html/lwip-devel/ There is a wiki about lwIP at http://lwip.wikia.com/wiki/LwIP_Wiki You might get questions answered there, but unfortunately, it is not as well maintained as it should be. lwIP was originally written by Adam Dunkels: http://dunkels.com/adam/ Reading Adam's papers, the files in docs/, browsing the source code documentation and browsing the mailing list archives is a good way to become familiar with the design of lwIP. Adam Dunkels <adam@sics.se> Leon Woestenberg <leon.woestenberg@gmx.net>