Field 'Response Value' (btatt.user_control_point.response_value) has a conflicting entry in its value_string: 4 is at indices 3 (Operation Failed) and 4 (User not Authorized))
Change-Id: Idb1f023c3dde00f7dcfc8b16e91d0a15a24072dd
Reviewed-on: https://code.wireshark.org/review/20740
Reviewed-by: Michael Mann <mmann78@netscape.net>
"Resolvable Private Address" comes in Core 5.
Also fix expert infos (usage) for all GAP characteristics are
described in Core 5.
Change-Id: I8386f5908b64cb758e2a973fb6f92fabcb30885a
Reviewed-on: https://code.wireshark.org/review/19974
Reviewed-by: Michael Mann <mmann78@netscape.net>
Instead of using a dissector function placed in a dissector table, just use the
protocol information registered with the dissector table to create the desired
dissector tree.
Change-Id: Ic32b15e3c05d73df6e8f69890c47172e991bda6f
Reviewed-on: https://code.wireshark.org/review/19509
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This emphasizes that there is no such thing as *the* routine to
construct a subset tvbuff; you need to choose one of
tvb_new_subset_remaining() (if you want a new tvbuff that contains
everything past a certain point in an existing tvbuff),
tvb_new_subset_length() (if you want a subset that contains everything
past a certain point, for some number of bytes, in an existing tvbuff),
and tvb_new_subset_length_caplen() (for all other cases).
Many of the calls to tvb_new_subset_length_caplen() should really be
calling one of the other routines; that's the next step. (This also
makes it easier to find the calls that need fixing.)
Change-Id: Ieb3d676d8cda535451c119487d7cd3b559221f2b
Reviewed-on: https://code.wireshark.org/review/19597
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add missed expert info for IEEE 11073-20601
Regulatory Certification Data List.
Change-Id: Id9520e1c604ee38bf11ce42248357ca007bffcfd
Reviewed-on: https://code.wireshark.org/review/18233
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Have all dissector tables have a "supports Decode As" flag, which
defaults to FALSE, and which is set to TRUE if a register_decode_as()
refers to it.
When adding a dissector to a dissector table with a given key, only add
it for Decode As if the dissector table supports it.
For non-FT_STRING dissector tables, always check for multiple entries
for the same protocol with different dissectors, and report an error if
we found them.
This means there's no need for the creator of a dissector table to
specify whether duplicates of that sort should be allowed - we always do
the check when registering something for "Decode As" (in a non-FT_STRING
dissector table), and just don't bother registering anything for "Decode
As" if the dissector table doesn't support "Decode As", so there's no
check done for those dissector tables.
Change-Id: I4a1fdea3bddc2af27a65cfbca23edc99b26c0eed
Reviewed-on: https://code.wireshark.org/review/17402
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It is described in Personal Health Devices Transcoding White Paper v1.6
at Bluetooth.org. It is not detailed implementation, because
white paper is not specification for this, but it is really
"giant leap for mankind".
Change-Id: I476b242a67c7c0b24e450ad347216c708cc12879
Reviewed-on: https://code.wireshark.org/review/17079
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>
This is an attempt to standardize display/handling of checksum fields for all dissectors.
The main target is for dissectors that do validation, but dissectors that just report the
checksum were also included just to make them easier to find in the future.
Bug: 10620
Bug: 12058
Ping-Bug: 8859
Change-Id: Ia8abd86e42eaf8ed50de6b173409e914b17993bf
Reviewed-on: https://code.wireshark.org/review/16380
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
GATT Service may define own error code. Add them.
Change-Id: I9e5c0d38b2dd01c16cfd47578f151cefdc9393fe
Reviewed-on: https://code.wireshark.org/review/16467
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
PLXS is Pulse Oximeter Service used by some pulse oximetry sensor
for consumer and professional healthcare
applications.
Change-Id: Iab5b7dd3e4bfb58cef0cc2c76df1e3aab69f35c7
Reviewed-on: https://code.wireshark.org/review/15452
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
The root of rr intervals subtree provided no information
about it's content.
Add count of contained rr intervals to it.
Change-Id: Ia9cb0a1dd8968643e6c6907cebe2f0336c09059d
Reviewed-on: https://code.wireshark.org/review/14988
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>
There can be multiple rr intervals in single HRS packet,
and currently they are just displayed on the same level
as other values in the packet. This may get hard to read
if there are many of them (eg. 8)
Gather RR Interval values into a subtree.
Change-Id: Idf0f0f9fa1265b04eb56defe5960da560d904026
Reviewed-on: https://code.wireshark.org/review/14917
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Packets from Heart Rate Service can contain
multiple rr interval values. They are appended
at the end of the packet. Before this patch
Wireshark recognized only the first value.
Make wireshark properly recognize them and decode
properly.
Change-Id: I3f3d8db4e0a941a690cd6a14dda84503e166f6e7
Reviewed-on: https://code.wireshark.org/review/14910
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Use wmem_strconcat and g_strconcat instead of wmem_strdup_printf and
g_strdup_printf when we register various protocols. This shows a fairly
significant speedup in the Visual Studio profiler.
Change-Id: I98709329513daa66ad3665925dc69149c43df884
Reviewed-on: https://code.wireshark.org/review/14855
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Started by grepping call_dissector_with_data, call_dissector_only and call_dissector and traced the handles passed into them to a find_dissector within the dissector. Then replaced find_dissector with find_dissector_add_dependency and added the protocol id from the dissector.
"data" dissector was not considered to be a dependency.
Change-Id: I15d0d77301306587ef8e7af5876e74231816890d
Reviewed-on: https://code.wireshark.org/review/14509
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This will make it easier to determine protocol dependencies.
Some LLC OUI dissector tables didn't have an associated protocol, so they were left without one (-1 used)
Change-Id: I6339f16476510ef3f393d6fb5d8946419bfb4b7d
Reviewed-on: https://code.wireshark.org/review/14446
Reviewed-by: Michael Mann <mmann78@netscape.net>
Now GATT dissectors need to have opcode to properly dissect attribute
or return expert info if possible (wrong usage).
Change-Id: Ife79bbf0682967a8bef8efadd8b242aa147315a7
Reviewed-on: https://code.wireshark.org/review/14314
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>
Bluetooth Specifications specify properties of every characteristics
(read, write, indicate, notify, write without response, signed write etc.)
Check it and add expert info about invalid usage if detected use of wrong
opcode with the characteristic.
Change-Id: I98ad8280b9ee65b4015a021e732ea748cc9e7a83
Reviewed-on: https://code.wireshark.org/review/14313
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Change-Id: Ie719e2f14c6eaf536035ab30dcb40e91c431c6e4
Reviewed-on: https://code.wireshark.org/review/14061
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
There are three level of characteristics: Services, Characteristics and
Configuration Characteristics. To properly analyzing packets
there is a need to display all three why dissecting UUID.
Change-Id: I3121338942c990b52ac2b3a45ced0529f80d4114
Reviewed-on: https://code.wireshark.org/review/13742
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>
OTS/OTP is the newset "profile" announced by Bluetooth SIG.
It name describe what it doing: Object Transfer Service/Profile,
so it is something like OPP.
While we are at this move some HID attributes to get right
order in switch-case.
Change-Id: I460963a422c7292b2cabf7e88f32dbd6e8d7051f
Reviewed-on: https://code.wireshark.org/review/13735
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>
Change-Id: I3c55af73ba989080cf6dfe206d25a6d4923ac7f1
Reviewed-on: https://code.wireshark.org/review/13622
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
It's not tied to the frame_data structure any more, so it belongs by
itself.
Clean up some #includes while we're at it; in particular, frame_data.h
doesn't use anything related to tvbuffs, so don't have it gratuitiously
include tvbuff.h.
Change-Id: Ic32922d4a3840bac47007c5d4c546b8842245e0c
Reviewed-on: https://code.wireshark.org/review/13518
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That removes most of the uses of the frame number field in the
frame_data structure.
Change-Id: Ie22e4533e87f8360d7c0a61ca6ffb796cc233f22
Reviewed-on: https://code.wireshark.org/review/13509
Reviewed-by: Guy Harris <guy@alum.mit.edu>
TDS is one of the newest profiles announced by Bluetooth SIG last time.
Also start adding expert info about usage of characteristic.
In this case mandatory properties are Write or Indicate,
so warn in other cases.
Change-Id: I0474c1986ddb16c4bcd03aa9160a07b0cacc76c6
Reviewed-on: https://code.wireshark.org/review/13391
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>
Print in Info column:
- service names while Discovery
- additional characteristic informations while Finding
- service name for characteristics, for example Handle: 0x002F (Battery Service: Battery Level)
- service name, characteristic name and additional configuration characteristic
name while read/write/etc it, for example:
Handle: 0x0030 (Battery Service: Battery Level: Client Characteristic Configuration)
Reason: "Client Characteristic Configuration" is configuration of characteristic,
in this case "Battery Level". Service name may be useful is somebody involved own service
with the same characteristic - "Battery Level".
Change-Id: I846755d58708ca60ad2a223b24a4a164b3c7cc14
Reviewed-on: https://code.wireshark.org/review/13390
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>
Change-Id: I8cfb0b375d4585bbeb890e79c1a41303e0277065
Reviewed-on: https://code.wireshark.org/review/13387
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Petri-Dish: Anders Broman <a.broman58@gmail.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>
Add TDS and OTS/OTP UUID, OTS PSM (I cannot find it, but
it seems to be linear), update CompanyIds and add three
EIR/AD codes: URI, Indoor Positioning and Transport Discovery Data.
Implementation of new "numbers" will be done later.
Change-Id: I8ad4d9c1d55c1824d87e88303c28e67dd445ec98
Reviewed-on: https://code.wireshark.org/review/13386
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add support for IEEE-11073 32-bit FLOAT and 16 bit SFLOAT field types.
Use them in Bluetooth ATT dissector.
Change-Id: Ife0f3843da84a9af23483b0a0d9b69cd2f511d08
Reviewed-on: https://code.wireshark.org/review/12680
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>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Change-Id: Ie39ef054a4a942687bd079f3a4d8c2cc55d5f22c
Reviewed-on: https://code.wireshark.org/review/12485
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Add HTTP Proxy Service attributes and UUID.
Change-Id: If0ab490f2df0930d2b80687ac4c9a1d7e4d463e4
Reviewed-on: https://code.wireshark.org/review/11978
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
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>
Change-Id: Id218dec9e5a721d6c63fd34962ffe50b6ab8dd56
Reviewed-on: https://code.wireshark.org/review/11946
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Reviewed-by: Diederik de Groot <dkgroot@talon.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The target here is the Decode As dialog where protocols have multiple registrations into a dissector table and that shows up as multiple entries in the Decode As dialog list with the same name so users are unsure which "dissector" they are choosing.
The "default" behavior (done in this commit) is to not allow duplicates for a dissector table, whether its part of Decode As or not. It's just ENFORCED for Decode As.
Bug: 3949
Change-Id: Ibe14fa61aaeca0881f9cc39b78799e314b5e8127
Reviewed-on: https://code.wireshark.org/review/11405
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Hear Rate flags should be 8-bits, not 16.
Change-Id: I31e3219bcdc60f3c649ef2c4f7775c10c1391d6f
Reviewed-on: https://code.wireshark.org/review/11022
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>
Use a standard way of displaying 128 UUIDs (like GUID).
This also change a way that UUID are handled by dissector tables.
Change-Id: Ie0f880f58480c34b40dd23c426202349e0620b12
Reviewed-on: https://code.wireshark.org/review/11018
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Each category of Appearance has "Generic" value (0x00), so show it as "Generic"
rather then "Unknown".
Change-Id: I572c8336a836a543d82975f0a27f0a06648132b8
Reviewed-on: https://code.wireshark.org/review/11017
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
There is no good reason to keep decodingAs on ATT layer,
while it is already done for whole Bluetooth: see "BT Service UUID",
which is "always" accessible.
Change-Id: I3df60aa7e781238c5af2af25abc188e9066e1707
Reviewed-on: https://code.wireshark.org/review/11016
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
There is possible that request will be send from two devices
in the same time. Fix request-response tracking to support this case.
Change-Id: Iaacf910d952f8dff96073e7155ea4947f9b8cbc3
Reviewed-on: https://code.wireshark.org/review/11014
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>
Alexis La Goutte