This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

custom BTLE dissector with wireshark 2

0

I'm updating a dissector I wrote for a byte stream the Nordic BTLE sniffer puts out. I wrote it originally for 1.10 and now it's time to make it available for Wireshark 2.

It registers as a USER10 wtap because it's not a protocol you'd see out in the wild, it's Nordic-specific. I have two small issues with the dissector now I've moved it to 2.0.

1) There's a btle_context structure which gives some information about CRC validation, information I do have. So I create one of those and pass it as data to the btle dissector, and that used to work. However now the btle dissector checks that the dissector above it is one of a set of specific dissectors, else it ignores the data, so the information about CRC doesn't get used. I can't add the nordic detector into the list of 'allowable parents' because it's 3rd party thing loaded just by people using Nordic's sniffer. Is there any way I can either pretend to be a dissector it recognises or otherwise get the btle dissector to use the context?

2) All the ATT messages show as 'UnknownDirection' because the p2p_dir is stripped from the pinfo by the btle dissector and replaced with 'unknown' before being passed to the lower dissectors. I can't really see why this is being done and I can't currently see a way around it. Have I missed something? The direction is known and was properly set in the pinfo.

Any pointers in the right direction would be helpful. The dissector works ok as it is, but it would be nice if it had the CRC info init and showed the ATT message direction properly.

asked 16 May '16, 01:40

rols's gravatar image

rols
6223
accept rate: 0%


One Answer:

0

I guess this is this dissector?

Hmm, this is probably a question best answered by Mr. Bluetooth (@Michal Labedzki) but I'll do my best...

  1. The BTLE dissector is doing this to know what structure is being passed in. I'd suggest that this should be refactored so that, for example, the structure tells you what is being passed in. Besides being cleaner this would allow your dissector to work. I'd suggest opening an enhancement request (if you do, please reference this question and also report the number back here for cross-referencing purposes).
  2. That came in with this change; looking at the diffs I suspect that the code is assuming that the underlying dissector isn't setting the direction correctly--which presumably yours is. I'd suggest asking this to be enhanced--probably in the same enhancement request as above.

answered 18 May '16, 07:30

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k572
accept rate: 27%

Thanks for that in-depth answer; I thought it was probably done to know whether the structure was valid or not as the BTLE detectors became more widely used, but didn't know of a good way to suggest passing that knowledge down without specifying parent detectors. I'll have a look through the codebase and see if there's a pattern for passing down information is valid like that which is generally used. I can think of several, like magic bytes etc, but I'm sure this requirement has been seen before and has a usual solution.

I get what you're saying about the direction field, and indeed quite a few of the encodings don't have that information, however you'd expect it already to be 'unknown' in that case. The way it is right now, the direction is correctly-used in the upper level dissector (master -> Slave or vice versa) and then tossed away. There must be a use-case there from history which prompted the change.

And yes this is the nRF dissector, although not that version of it, it's the OSX one which I was bringing up to v2.0. It is so nice not to have to fiddle with X11 on OSX any more!

Let me hunt the codebase a little more and see if I can find a good pattern to suggest and then take this over to the enhancement site.

Thanks again for the answer, very helpful.

(18 May '16, 17:16) rols

The way it is right now, the direction is correctly-used in the upper level dissector (master -> Slave or vice versa) and then tossed away. There must be a use-case there from history which prompted the change.

I'd guess that there's some scenario where BT is carried over some other protocol (possibly IP-based?) which sets its own direction which was somehow irrelevant to the BT direction. But that's a WAG.

And: you're welcome!

(18 May '16, 17:58) JeffMorriss ♦