Device dialog appears when user double clicks on device in
Devices dialog (Bluetooth->Devices). It provides
summary of device, like BD_ADDR, name, timeouts, etc.
Base on information from HCI layer, so this feature is more interesting
for local devices (capturing on its side). Each field has changes counter,
what mean that value at specified field changes in time, for example:
user change device name 3 times. Please note that initial change
is not counted. It means that you can see fielkd without any value
then change occur and counter is not increased. It will be increased
next time. Reason for that is in most cases field value is unknown
at start.
Change-Id: Ife0a6bd454eac00a28f8eb2906e1b395695b0307
Reviewed-on: https://code.wireshark.org/review/15793
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
Now it is possible to DecodeAs manufacturer specific content of
EIR or AD, so you are able to write custom plugin to dissect it.
New dissector table: btcommon.eir_ad.manufacturer_company_id
Change-Id: Iac458cd51f7b9bab51ccf7a4411984fb269a86ef
Reviewed-on: https://code.wireshark.org/review/13389
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
That's a much cleaner way of determining whether you found no matchin
bluetooth_uuid_vals_ext than checking whether val_to_str_ext_const()
returned the "use this if unknown" value.
It also lets us avoid a wmem_strdup().
Make print_numeric_uuid() and print_uuid() return const gchar *; there's
no reason for them *not* to be const, and that means we don't have to
throw away constness.
Change-Id: I62fb0b81c64c107dfea6c16ca8c5b9593f8f2a9d
Reviewed-on: https://code.wireshark.org/review/12126
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Some vendors use UUID128 as own services/attributes.
Sometimes they use UUID16 for it too. Support both cases.
Change-Id: I001692b94fcc2f86eafa81012790e9134b0f2a36
Reviewed-on: https://code.wireshark.org/review/11976
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
HCI Summary dialogue collect HCI Opcodes, HCI Events, Hardware Errors,
Statuses and Reasons. Also show occurrence of them. The top level item
is group of items (by OGF or types), the second level item is in real
command, event, hardware error, status or reason. The third level items
are direct link to packet that contains second level item type.
Change-Id: I6b6bd02533c4605a2dd2c1f5dfee46f72a0f3fdc
Reviewed-on: https://code.wireshark.org/review/9676
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Replace L2CAP Service, RFCOMM Service and AVCTP PID dissector table
by shared Bluetooth Service UUID table. It also supports UUID16,
UUID32 and UUID128 by hex-string, like for AVRCP: "110e".
Change-Id: I473bc73d10939e8ed6dd55a6a92387c7a1ec125a
Reviewed-on: https://code.wireshark.org/review/9678
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Make the "previous protocol data" union in bluetooth_data_t a
discriminated union, and use the discriminator to decide whether to use
a given member of the union or not (or to check whether the member you
plan to use is valid).
Have separate top-level dissectors depending on what the data type
pointed to by the "data" argument is.
Use that member to point to pseudo-header metadata, and, for now, set it
to point to the appropriate pinfo->pseudo_header value; eventually, we
plan to pass the pseudo-header pointer in as the "data" argument from
the "frame" dissector.
Don't overwrite the pseudo-header in the packetlogger dissector -
construct a new one and pass it in.
Change-Id: Ia1ef71e7082a964c5d92d47221f8c00e32f3f087
Reviewed-on: https://code.wireshark.org/review/8943
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Please found it under Bluetooth menu. It shows all devices found
in logs, not only connected, all that its address can be found in
logs. Show if device is local (in most cases: capturing on it side)
and manufacturer and LMP version what should answer the question what
version of Bluetooth is used by Bluetooth device chip.
Also firmware version.
Change-Id: I32e3b7100cdebcaa850b6541de0ab89dff41c0e1
Reviewed-on: https://code.wireshark.org/review/8901
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
HCI Commands in most cases generate response in Event queue, so try
to map event to command and give user response time information.
Change-Id: Ib4956829b7d0064ab528aa3202f8f959d8d371b7
Reviewed-on: https://code.wireshark.org/review/8514
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
uuid_t is a data type provided by a number of environments, thanks to
the Open Software Fuundation; calling the Bluetooth code's data type,
which includes an actual OSF-style UUID as a member, "uuid_t" can lead
to confusion and *does* lead to compile errors on platforms where, for
better or worse, system headers such as <unistd.h> define uuid_t (and
are included by, for example, Qt headers).
Just rename it "bluetooth_uuid_t".
Change-Id: Ic742723913ba4105cd3269dd24fc821147285176
Reviewed-on: https://code.wireshark.org/review/7017
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It is a GUI+QT feature that introduce Bluetooth menu and
"ATT Server Attributes" that present all handle+UUID pairs
as table. User may copy cell value, row, selected rows or whole
table within header. On activate user will go to packet that
introduce UUID for specified handle.
Change-Id: If17e53aff5feb89ededc740a595ba5882b90be5e
Reviewed-on: https://code.wireshark.org/review/6911
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
ATT dissector is now able to decode GATT level fields.
This is results of added request-response tracking/share information.
Change-Id: I41ac622a38916a7a20f625fa30ac72d7812446c6
Reviewed-on: https://code.wireshark.org/review/6904
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
There is information about manufacturer of Bluetooth chip.
Also try to detect if that "permament" info is not changed,
if so informs user about this rare event (probably there is an issue)
Change-Id: I1fa748a67ad7943e61d4445d240f0578b94560fc
Reviewed-on: https://code.wireshark.org/review/6408
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
Since those command/events are vendor specific and proprietary
not all commands/events are implemented. All implemented commands can be
found in Open Source implementations for Broadcom chip. If you found more,
please let me know.
Change-Id: Ie68d3737c88a8cef39260a9d93192cfc81871d6c
Reviewed-on: https://code.wireshark.org/review/6406
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
Bluetooth dissector is used to add ability to filter all bluetooth
payload from capture files (there are many transport like:
hci_h4, hci_h1, hci_usb, hci_mon, btle). Also it is used to placeholder for
all data tree used to store additional informations like bd_addrs, names, etc.
Finally it is used to be one point for Bluetooth
Endpoints/Conversation filtering what is enabled now.
Also add Master/Slave Role and Connection Mode tracking.
Change-Id: I67048080fb8ee16fa0f4ec429c1257de81ddd737
Reviewed-on: https://code.wireshark.org/review/5771
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Michal Labedzki