Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_BOOLEAN
FT_IPv4
FT_EUI64
FT_GUID
FT_UINT_STRING
Also: For type FT_ITv6 use ENC_NA. (This was missed in SVN #39260)
svn path=/trunk/; revision=39328
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_OID
Note: Encoding field set to ENC_NA only if the field was previously TRUE|FALSE|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN
svn path=/trunk/; revision=39260
Add a new tap flag to indicate that a tap listener is just a "dissector helper",
that is, a tap which is used by a dissector to help it do its dissection but
does not, itself, require dissection.
Use this new flag in the dissectors which register taps.
Remove the (now-unused) have_tap_listeners() function.
svn path=/trunk/; revision=37069
pseudo-header, and hence there's no direction indication. Don't set
pinfo->p2p_dir for it. Use WTAP_ENCAP_BLUETOOTH_H4_WITH_PHDR, not
WTAP_ENCAP_BLUETOOTH_H4, for capture files where we have the direction.
Don't assume pinfo->p2p_dir is either P2P_DIR_SENT or P2P_DIR_RECV when
setting the info column in various Bluetooth dissectors; it might be
unknown.
In the HCI H4 dissector, put the direction into the info column
regardless of whether we have a type match or not; the dissectors for
HCI packet types appear to assume it's been set (as they put a blank at
the beginning of the stuff they append to the direction).
svn path=/trunk/; revision=35933
Bluetooth profiles and protocols above RFCOMM and L2CAP can not be dissected correctly because the required information (server channel and dynamic PSM value mappings to services/profiles) about the type of data carried in the payload is not available. RFCOMM is currently hardcoded to handoff all payload data to the obex dissector though it may carry e.g. handsfree, dial-up networking or serial port profile related data.
The patch consists of modifcations to the following dissectors:
btsdp: Extraction of RFCOMM server channel and L2CAP dynamic PSM with service mapping is provided to RFCOMM and L2CAP through a tap interface. In addition, the packet list info is beautyfied and extended with more details for better
overview.
btl2cap: Adds a new dissector table with services and dynamic PSM mapping which is filled by a tap listner catching the info from btsdp. More info added to packet list.
btrfcomm: Adds a new dissector table with services and server channel mapping which is filled by a tap listner catching the info from btsdp. Dissectors for handsfree, dial-up netorking and serial port profiles (all based on RFCOMM) are also added.
btobex: Registers several obex based profiles (e.g. obex push, file transfer, basic printing etc.) in both RFCOMM and L2CAP. Some cleanup.
svn path=/trunk/; revision=35323
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
the data source does not need to be allocated if (!tree).
Rev 30158 took the if (!tree) check out indicating that the check was invalid.
So: (since packet_add_new_data_source() now only calls add_new_data_source()),
remove packet_add_new_data_source().
svn path=/trunk/; revision=34717
1) The tvb + name (aka. data_source) is only used when the protocol tree is visible
The current implementation of add_new_data_source() doesn't take this into account and simply allocates a data_source regardless. This is what packet_add_new_data_source() tries to rectify.
A couple of dissectors have already been switched over to the new packet_add_new_data_source(). Many are still missing. Help appreciated!
svn path=/trunk/; revision=29427
The Bluetooth AMP Manager protocol was recently adopted by the Bluetooth SIG.
This protocol sits on top of L2CAP and requires a few changes in order to
accommodate the new move/create channel request.
This patch includes:
* a new Bluetooth AMP Manager Protocol dissector
* changes to L2CAP to handle the new move/create channel signals
* introduce a dissector table for fixed channel, allowing btamp dissector to
handle the BT AMP Manager Protocol channel
* Preliminary changes in L2CAP to support the new enhanced L2CAP modes
(enhanced retransmission/streaming mode)
svn path=/trunk/; revision=28819
(1) Trailing/leading spaces are removed from 'name's/'blurb's
(2) Duplicate 'blurb's are replaced with NULL
(3) Empty ("") 'blurb's are replaced with NULL
(4) BASE_NONE, NULL, 0x0 are used for 'display', 'strings' and 'bitmask' fields
for FT_NONE, FT_BYTES, FT_IPv4, FT_IPv6, FT_ABSOLUTE_TIME, FT_RELATIVE_TIME,
FT_PROTOCOL, FT_STRING and FT_STRINGZ field types
(5) Only allow non-zero value for 'display' if 'bitmask' is non-zero
svn path=/trunk/; revision=28770
The L2CAP dissector assumes all packets on a connection oriented channel are
B-frames (basic mode, or v1.1 backwards compatibility).
Retransmission mode or flow control mode (introduced in v1.2 bluetooth spec)
use I-frames and S-frames, which are described in the current 2.1 spec here:
Volume 3 (core, host volume) - Part A (L2CAP) - 3.3 (CONNECTION-ORIENTED
CHANNEL IN RETRANSMISSION/FLOW CONTROL MODES).
svn path=/trunk/; revision=26383
L2CAP dissector is missing retransmission & flow control modes (these were
introduces in BT 1.2 specification)
Configuration commands were not fully decoded because of a bigend/littleend
issue
L2CAP commands had the wrong length set to the protocol tree by reading from
the wrong buffer offset
Also the dissect_options() function consumes all remaining data in the L2CAP
packet, which prevents decoding of other commands which follow a config
request/config response in the same packet.
From me:
Mark an unused parameter.
svn path=/trunk/; revision=24262
- if offset is 0, tvb_length is the same as tvb_length_remaining, just faster.
Replace
- col_append_fstr() with faster col_append_str()
- col_add_str() with col_set_str()
when it's safe
svn path=/trunk/; revision=23252
doing the reassembly internally in acl instead of calling reassembly.c since the fragmentation is so simple and packets are so small anyway so full reassembly.c support would be overkill.
svn path=/trunk/; revision=18223
higher layer protocols need the chandle, cid and direction (from pinfo) in order to identify packets for the same "conversation"
(it is not a conversation per se in bluetooth butn one unidirectional flow that we track)
svn path=/trunk/; revision=18220