Decoder Event Logging
The Frontline decoders collect a lot of meta-information. In Bluetooth, all sorts of information is collected along the way about connections, device identification and the data being passed back and forth. This information aids ComProbe software in decoding the data carried in later frames.
But some of that data is useful to see. On an ad hoc basis, some Frontline decoders can expose meta-information through the use of event logging. This topic will describe how to enable event logging and how to read the results. The ATT decoder will be used as an example.
Note: Enabling event logging involves physical disk writes. Event logging during a live capture will affect performance. Perform live captures with Event logging off. Then open the capture file and recreate companion files to see a log.
Enabling Event Logging
For this example we will use an ini file for handling 128-bit UUIDs: ATT_CustomLongUUIDs.ini. This decoder may exist in your My Decoders directory (C:Users/Public/Public Documents/Frontline/My Decoders/). If the file is not in your My Decoders directory, see "Handling 128-bit UUIDs" for instructions on building this file.
- Load ATT_CustomLongUUIDs.ini into a text editor.
-
Add a new section to the end of the file:
[DEBUG]
ATT_LOG_LongUUID = 1
ATT_LOG_Mappings = 1
ATT_DUMP_Mappings = 1
- Save the .ini file to your My Decoders directory.
Important notes:
- The .ini file must reside in the root of your My Decoders directory.
-
The .ini file is loaded exactly once when the ComProbe software is run.
- Reloading the decoders will not reload this file.
- Recreating companion files will not reload this file.
What you get from event logging
In the code above, setting the values to "1" will enable the log. Setting the value to "0", commenting the code out with a semi-colon, or deleting the line will disable logging. The default condition of these values is "0".
The code will provide the following information to the log:
| Code | Log Description |
|---|---|
| ATT_LOG_LongUUID | Logging of the mapping of Long (128 bit) UUIDs to arbitrary 32 bit numbers. |
| ATT_LOG_Mappings | Log Mapping events. These events occur only when a new item is discovered and the mapping database changes. |
| ATT_DUMP_Mappings | 3. Log Dump. Every time the mapping database is accessed, the entire contents are dumped to the event log. |
Reading the result
Long UUID events: Consider the following two events.
Event 1: Frame 0 Mapping UUID: b8d02d816329ef968a4d55b376d8b25a = 0x7f000001
Event 2: Frame 0 Mapping UUID: 5a50528de5ba462090ac33e5b913684c = 0x7f000002
In event 1, CPAS has loaded a mapping for a 128 bit UUID and it maps to 0x7f000001.
Event 124: Frame 76 mapping UUID 7f000001 to handle 73
Event 125: Frame 76 Mappings list: 1 items
Event 126: Frame 76 dc3df4b4:1,73,7f000001
In event 124, we see that handle 73 has been mapped to 0x7f000001. That means that when we receive a transaction (read or write) for handle 73, we can map it all the way back to UUID b8d02d816329ef968a4d55b376d8b25a and the decoder will know what to do.
In event 125, still at frame 76, we see a full dump of our mappings database. We see that for AccessID, side 1 (Advertiser/Peripheral), there is a link between handle 73 and UUID 0x7f000001.
Events 1 and 2 were created as a result of ATT_LOG_LongUUID = 1.
Event 124 was created as a result of ATT_LOG_Mappings = 1.
Events 125 and 126 were created as a result of ATT_DUMP_Mappings = 1.