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 |
One Answer:
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...
answered 18 May '16, 07:30  JeffMorriss ♦ |
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.
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!