1. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
2. For all but FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN).
svn path=/trunk/; revision=39426
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
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
(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
Enhancement:
- TIPC is available in a new version (1.7), adding/removing fields while
keeping the same version number (2).
Minor bugs:
- In NAME_DISTRIBUTOR messages the origianting and destination node are
switched.
- The used size of BUNDLER messages payload is not calculated correctly when
size%4=0, this leads to the wrong assumption that the message would be
malformed.
svn path=/trunk/; revision=23291
- reassembling of fragmented TIPCv2 messages
- calling of heuristic subdissectors
- multicast upper+lower bound header fields are now shown
- corrects few typos in the comments in packet-tipc.c
svn path=/trunk/; revision=22889
Changes are only for protocol version 2.
The changes are:
- dissect "TIPC Bundler Protocol" messages correctly
- search for other dissectors which want to dissect encapsulated data according to the TIPC user or TIPC type of a message. The data dissection is difficult since a TIPC data message does not necessarily a "type" set. So for the moment - while TIPC is not widely used - just triggering for the user of a message will be sufficient for people looking into the TIPC protocol.
- "Dissect TIPC data" in the preferences is now switched on by default
- to show undissected data, the "data" dissector is now used.
- corrected some typos
svn path=/trunk/; revision=22183
most have been tagged unused (few have been deleted if dissector has not been
modified since a long time)
move packet-ssl-utils.c to DISSECTOR_SRC
svn path=/trunk/; revision=21431
This patch changes the name of "Link Configuration" Packets to "Neighbour Discovery" - as preferred by the creator of TIPC - and shows the TIPC src/dst in the columns instead of the MAC address for those packages.
svn path=/trunk/; revision=19887
- dissection of TIPCv2 internal messages now shows
all fields used according to the protocol spec
- there should be no issues with the current protocol
spec anymore
- the info column is more concise and gives more
details
- some code beautifications
svn path=/trunk/; revision=19354
Packet-g723.c - B0 and B1 should be treated together.
packet-tipc.c - Change desgementation code to handle more than 2 segments.
svn path=/trunk/; revision=17204
dissect (so that we report a packet cut short by the snapshot length).
Get rid of an unused variable..
As we restore "pinfo->fragmented" from "save_fragmented" regardless of
whether we're defragmenting or not, we have to save its previous value
in "save_fragmented" regardless of whether we're defragmenting or not.
svn path=/trunk/; revision=16808
tipc: First stab at reassembly, as tipc reasembly is based on reading the message length from the first segmented packet and then just add the bytes received I didn't find a better way of doing it.
svn path=/trunk/; revision=16724