lwIP - A Lightweight TCP/IP stack - Bugs: bug #53103, MQTT corrupted mesages
You are not allowed to post comments on this tracker with your current authentication level.
bug #53103: MQTT corrupted mesages
Submitter: | David Bourgeois <jaguarondi> | ||
Submitted: | Fri 09 Feb 2018 02:44:47 AM UTC | ||
Category: | apps | Severity: | 3 - Normal |
Item Group: | Crash Error | Status: | Works For Me |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | git head |
Jump to the original submission
Mon 21 Aug 2023 03:16:53 PM UTC, comment #8: |
Roger Sala <rsala> |
Sat 19 Aug 2023 08:10:00 AM UTC, comment #7: This is similar to what we found when the MQTT topic is in segmented packets, this is described in bug #57734 |
David Bourgeois <jaguarondi> |
Fri 18 Aug 2023 04:49:48 PM UTC, comment #6: ... so I turned on the MQTT_DEBUG_TRACE and was able to establish that my problem was occurring when the ring buffer rolled over and a mqtt publish became fragmented which caused the TLS layer on the broker machine to issue a "bad record MAC" alert and then the mosquitto broker to subsequently close the connection.
|
Roger Sala <rsala> |
Wed 16 Aug 2023 05:25:18 PM UTC, comment #5: Same MQTT ring buffer corruption issue with LwIP 2.1.2, MbedTLS, FreeRTOS on STM32H7. In my case the publishes are not taking place in a tight loop and if I publish at a lower frequency, the crash always takes place after the exact same number of packets sent. The bigger the ring buffer the longer it runs, but it always crashes as in the attached pcap. |
Roger Sala <rsala> |
Fri 16 Feb 2018 11:05:59 AM UTC, comment #4: Cool, I think that's the first bug found with the new LWIP_ASSERT_CORE_LOCKED() code :-) |
Simon Goldschmidt <goldsimon> |
Fri 16 Feb 2018 10:53:54 AM UTC, comment #3: You are right, it was indeed a threading issue on our side, not calling LOCK_TCPIP_CORE and LWIP_ASSERT_CORE_LOCKED() indeed revealed the problem. Sorry for the trouble. |
David Bourgeois <jaguarondi> |
Wed 14 Feb 2018 08:04:39 PM UTC, comment #2: I just tested this and it works for me.
|
Simon Goldschmidt <goldsimon> |
Wed 14 Feb 2018 11:34:06 AM UTC, comment #1: Are you 100% sure this is no threading issue? That code executing mqtt_publish() in a tight loop looks suspicous! When correctly following threading rules, you'd have no chance to process TCP ACKs with this code.
|
Simon Goldschmidt <goldsimon> |
Fri 09 Feb 2018 02:44:47 AM UTC, original submission:
In the attached wireshark capture, we can see a series of corrupted messages in packet 454, which trigger a disconnection by the broker.
|
David Bourgeois <jaguarondi> |
Depends on the following items: None found
Items that depend on this one: None found
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.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2023-08-16 | rsala | Attached File | - | Added mqtt.pcapng, #55051 | |
2018-02-14 | goldsimon | Status | None | Works For Me | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed | |||
2018-02-09 | jaguarondi | Attached File | - | Added mqtt_garbage_capture.pcapng.gz, #43211 |
Powered by Savane 3.13-02a9.
Corresponding source code
Am I reading bug #57734 correctly to be open and unassigned?