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 an earlier SVN)
svn path=/trunk/; revision=39329
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=39292
This patch adds support for displaying OPC UA ExtensionObjects.
An ExtensionObject is a mechanism to transport user defined structures as
serialized blobs. Some types of ExtensionObjects are already defined by the OPC
Foundation's OPC UA Specifications.
These types can be implemented by this dissector, because they are well-known.
Real user-defined or vendor-defined types are unlikely to be implemented by a
passive dissector, because this would require browsing of the UA server's
address space to retrieve the type information.
Currently only the following types are supported:
* DataChangeNotification
* EventNotification
Others OPC defined types will follow.
From me: fix warnings: "format not a string literal and no format arguments"
svn path=/trunk/; revision=34906
This patch fixes displaying OPCUA Strings and ByteStrings.
From me: fix warnings: "format not a string literal and no format arguments"
svn path=/trunk/; revision=34905
I attached a patch which fixes some problems in the array handling of OPC UA
data when the array length is zero or -1 which is a Null-Array.
svn path=/trunk/; revision=34880
(Thank you, sed, for doing the 90% of the work for me.)
Note that two of these files says "do not modify" implying that they are
machine generated but AFAIK we don't have the means to rebuild them.
svn path=/trunk/; revision=32561
ABSOLUTE_TIME_LOCAL or ABSOLUTE_TIME_UTC, indicating whether to display
the date/time in local time or UTC. (int)ABSOLUTE_TIME_LOCAL ==
(int)BASE_NONE, so there's no source or binary compatiblity issue,
although we might want to eliminate BASE_NONE at some point and have the
BASE_ values used with integral types start at 0, so that you can't
specify BASE_NONE for an integral field.
svn path=/trunk/; revision=31319
Move header field info declarations into function scope.
This is the first step. Another patch will be submitted which actually scrubs
the header field info declarations (remove empty blurbs, etc.)
svn path=/trunk/; revision=28797
