This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Wireshark BLE L2CAP packet reassembly

I have some BLE traffic that I have sniffed and am displaying in Wireshark. Most of the opcodes (read/write request/response indications/notifications etc.) are parsed/displayed correctly. However, I have some packets that are prepare write requests/responses and these just show as L2CAP fragments. Is there a way to reassemble fragmented prepare write requests/responses in Wireshark so that I can see the header data (attribute opcodes 0x16, 0x17) and reassembled value?

  • Nope. There's no code in wireshark which does that for BLE. In fact there's not much stateful conversation parsing in the BLE dissectors at all.

    You could add code to do that and submit it to wireshark, but you probably want to check it's not already on someone's radar and if it's the kind of stateful dissection they'd want.

  • FormerMember
    0 FormerMember

    It should work fine to see prepare write request/response in wireshark. Which version of wireshark do you use? The sniffer works best with version 1.10.x (I just tested with wireshark 1.10.14).

  • You can see the individual packets but wireshark's BLE dissector doesn't re-assemble separate packet fragments into entire messages in the same way it does with some TCP and other protocols. That was what the OP was asking.

  • Thanks for the clarification. I can see the packet fragments and can manually extract the header/reassemble the value but as RK mentioned I was looking for a way similar to TCP and SSL protocols to have wireshark automatically reassemble the L2CAP fragments.

    FYI I'm using wireshark v 1.12.5 and have noticed that the nordic BLE sniffer meta doesn't show up correctly in newer versions (I have had to mention using an older version to several colleagues). One colleague uses 1.10.x and the L2CAP fragments show as "Malformed Packet" rather than "L2CAP Fragment"

  • There were quite a lot of changes to the BLE dissectors between 1.10/1.11 and 1.12 which is very similar to what ended up in 2.x and I'm not entirely sure I totally understand some of them. Some of the useful header information (like direction) is explicitly stripped on the way down the dissector chain which seemed a bit daft to me. I have to assume that there were cases it was wrong but I didn't manage to get a straight answer out of the mailing list.

    I maintain the OSX port of the sniffer, I didn't have trouble on 1.12, but had to make a few changes to support 2.x and recompile it against latest libraries and use that one now, and live with the annoyances in the latest BLE dissector codebase.

Related