Separate the stuff that any record could have from the stuff that only
particular record types have; put the latter into a union, and put all
that into a wtap_rec structure.
Add some record-type checks as necessary.
Change-Id: Id6b3486858f826fce4b096c59231f463e44bfaa2
Reviewed-on: https://code.wireshark.org/review/25696
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Follow up to having conversions use endpoint_type instead of
port_type.
Change-Id: Ifd59a33bd8b9a013c242bce5fcceb09533f02c17
Reviewed-on: https://code.wireshark.org/review/24172
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
For the moment this mirrors the port_type enumeration (PT_XXX), but the
intent is to move away from using "port types", eliminating most (if not
all)
Added conversation_pt_to_endpoint_type() so that conversations deal with the
correct enumeration. This is for dissector that use pinfo->ptype as input
to conversation APIs. Explicit use of port types are converted to using
ENDPOINT_XXX type.
Change-Id: Ia0bf553a3943b702c921f185407e03ce93ebf0ef
Reviewed-on: https://code.wireshark.org/review/24166
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
iBeacon is manufacturer specific (Apple) data in advertising packets.
Based on: https://developer.apple.com/ibeacon/Getting-Started-with-iBeacon.pdf
Use DecodeAs on advertise packet using field "BT EIR/AD Manufacturer Company ID"
then select this dissector "Apple iBeacon".
Change-Id: Ie3e50a391914054f33144d99734cf59fbda9683e
Reviewed-on: https://code.wireshark.org/review/19970
Petri-Dish: Michal Labedzki <michal.tomasz.labedzki@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Another format of beacon in advertising packet.
Based on: https://github.com/AltBeacon/spec
User needs to use DecodeAs to use this dissector - any manufacturer's
company id may be valid.
Change-Id: I5656d9dbb70b648b2fadba7f3b525d38a2fe8e57
Reviewed-on: https://code.wireshark.org/review/19971
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Updated on 5th February 2017:
- UUIDs
- Company Ids
Change-Id: I9868891ee2bdcdaa687bd45c76429f2b476889cc
Reviewed-on: https://code.wireshark.org/review/19973
Petri-Dish: Michal Labedzki <michal.tomasz.labedzki@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@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>
Update member UUIDs and CompanyIDs from Bluetooth Assign Numbers.
Change-Id: I5deb5b8e930d2df0296f17a3fe3b46989a28a86d
Reviewed-on: https://code.wireshark.org/review/15453
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
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>
For Broadcast address use FT_ETHER with FF:FF:FF:FF:FF:FF address
instead of string address "Broadcast".
Change-Id: I638d3d6a1baa9c965dd0a9f548cedbd81af3ec5b
Reviewed-on: https://code.wireshark.org/review/14767
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
This saves many dissectors the need to find the data dissector and store a handle to it.
There were also some that were finding it, but not using it.
For others this was the only reason for their handoff function, so it could be eliminated.
Change-Id: I5d3f951ee1daa3d30c060d21bd12bbc881a8027b
Reviewed-on: https://code.wireshark.org/review/14530
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
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>
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>
It works the same regardless of what flavor of USB metadata there is,
and there's no good reason for any Bluetooth code to know, or care,
about particular flavors of USB metadata.
Add some comments while we're at it.
Change-Id: I6ea2063a015e424fc84a407231e80ef3e2a79c98
Reviewed-on: https://code.wireshark.org/review/14001
Reviewed-by: Guy Harris <guy@alum.mit.edu>
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>
Add fields for the absolute time stamp (and another field for a presence
flag for the absolute time stamp) and the packet encapsulation for the
packet.
This lets us remove the field for the packet encapsulation in the
frame_data structure; do so.
Change-Id: Ifb910a9a192414e2a53086f3f7b97f39ed36aa39
Reviewed-on: https://code.wireshark.org/review/13499
Reviewed-by: Guy Harris <guy@alum.mit.edu>
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>
The "-Wwrite-strings" flag produces nuisance warnings. These warnings are
not useful, they're impossible to fix in a sane way and therefore are being
handled with casts of static strings to (char *).
This just moves the warning to [-Wcast-qual] and a compiler pragma is
in turn required (and used) to squelch that warning.
Remove the Wwrite-strings warning. Let that responsibility fall on the
programmer (as is done by casting).
Change-Id: I5a44dfd9decd6d80797a521a3373593074962fb5
Reviewed-on: https://code.wireshark.org/review/12162
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
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>
Some of the ASN.1 dissectors still generate a new_create_dissector_handle from the tool itself, so leave those for now.
Change-Id: Ic6e5803b1444d7ac24070949f5fd557909a5641f
Reviewed-on: https://code.wireshark.org/review/12484
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
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>
Update company IDs and Member/SDO UUIDs to latest Assign Number.
Change-Id: Ia543ab1bcf43cf5283658cbe0971c8bc9877426d
Reviewed-on: https://code.wireshark.org/review/11979
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
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>
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>
Change-Id: Iee1d1cf3e24dacca3c1a353001a8af71e074a96b
Reviewed-on: https://code.wireshark.org/review/11454
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
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>
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>
"GN" does not seems to be really useful, but "PAN GN" is reasonable.
Change-Id: Ia04aa20e4b95743c7db46e87606e3843a124d7e4
Reviewed-on: https://code.wireshark.org/review/10524
Reviewed-by: Michael Mann <mmann78@netscape.net>
+18 ATT attributes to be implemented (IPS 1.0 - 19 May 2015, etc.)
Change-Id: Ib30ea20fe9b32a4be842f01ad5b8e8ee081a14ff
Reviewed-on: https://code.wireshark.org/review/10095
Reviewed-by: Anders Broman <a.broman58@gmail.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>
Have the "data" argument to dissectors registered in thw wtap_encap
dissector table point to the pseudo-header for the packet.
Use that argument in the Bluetooth dissector.
Change-Id: I022bbfb796ef51d95df09fb952a149960170d631
Reviewed-on: https://code.wireshark.org/review/8951
Reviewed-by: Guy Harris <guy@alum.mit.edu>
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>
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>