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
(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
Added support for Symbian OS btsnoop.
The bluetooth HCI layer in Symbian OS can be configured to log all packets to a
file. The log format, "btsnoop" is based on the RFC1761 "snoop" format - but
differences in the header make it incompatible.
The btsnoop format supports logging of these formats:
"H1" (raw HCI packets without framing)
"H4" (HCI UART packets including packet type header)
"H5" (HCI 3 wire UART packets including framing)
"BCSP" (HCI bluecore serial protocol including framing)
"H1" and "H4" are section numbers in the original v1 bluetooth specifications,
but still used colloquially - wireshark's existing support for Linux bluez HCI
logs uses the "H4" name.
In practice, the "H1" format is used for H5,BCSP and USB HCI logs, as the HCI
packet logs are mainly useful for debugging higher layers, bluetooth profiles
and bluetooth applications.
From me:
Deleted some unused prototypes.
Mark an unused parameter.
svn path=/trunk/; revision=24263
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
acl chandle + direction + l2cap-CID to uniquely identify a single specific
flow of PDU packets.
So we need to pass the chandle upp from acl to l2cap at least.
It would have been nice to handle this using "conversations" but the bluetooth
stack does not eaily map to the idiom host:port<->host:port
instead in bluetooth you have unidirectional flows that are identified by ACL-chandle:L2CAP-CID:direction and additional state held inside l2cap would attach two such flows together into a "conversation".
Bluetooth packets themself only indentify "half" of the two way conversation.
svn path=/trunk/; revision=18218
the fragment reassembly from the old patch is commented out since it has to be redone completely using emem and se_trees the proper way.
but to do this i would need example captures of fragmented bluetooth traffic first.
svn path=/trunk/; revision=18149
Anders Broman