Hi everyone, I wanted to share some insights and experiences regarding BLE packet loss during firmware updates, something that has been quite a puzzle for my team. We’re working on electronic board games and recently encountered an issue where Samsung phones were struggling to complete firmware updates due to packet loss over BLE connections. While the BLE connection remained active, it seemed that some ATT packets were being lost because L2CAP fragments weren’t being retried. This was particularly noticeable on the Samsung Galaxy S9, which we were using for testing.
The process of firmware transfer involves sending header packets, followed by multiple data packets, and then receiving acknowledgments from the peripheral device. However, during this process, our device would occasionally hang, as it wasn’t acknowledging the most recent chunk. The logs from our BLE sniffer revealed that while some GATT writes were successful, others were lost, especially when fragmentation occurred. This led us to experiment with reducing the packet size to avoid fragmentation entirely, which surprisingly resolved the issue. It seems that when fragmentation isn’t an issue, retries work more reliably.
I’m now suspecting that this might be a bug in how Samsung’s BLE radio handles L2CAP loss during fragmented ATT transmissions. It’s concerning that the connection remains open despite the packet loss, which could lead to inconsistent firmware updates. I’d love to hear if anyone else has encountered similar issues or has insights into how Samsung’s BLE implementation handles such scenarios.
On a positive note, adjusting the packet size to avoid fragmentation provided a reliable workaround. It’s a reminder of how crucial it is to test firmware updates across different devices and BLE implementations. I’m hopeful that by sharing our findings, others might avoid similar pitfalls or contribute to a better understanding of this issue.