Use tvb_ip_to_str().
There's no need to pass the result of tvb_get_ptr() as the 'value' in
proto_tree_add_*(): just use proto_tree_add_item().
Replace some tvb_get_ptr()s with tvb_get_ephemeral_string()s to ensure the
return string is NULL terminated.
svn path=/trunk/; revision=35547
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
(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
Wed, Jan 31, 2007 at 7:24 PM
To: wireshark-dev@wireshark.org
Hello,
Please consider for checkin the following new dissectors, for the FMP protocol.
FMP (File Mapping Protocol) is the network protocol basis for EMC's HighRoad (MPFS) technology. Highroad is used to allow multiple clients to share access to NAS-shared files while allowing clients to directly access data volumes (via, for example, Fibre Channel or iSCSI). EMC currently uses this technology in our Celerra NAS servers, and we're currently in the process of open sourcing portions of the technology.
FMP actually consists of two ONC/RPC-based protocols - the core FMP protocol, and FMP/Notify. The latter is used as an asynchronous callback to inform clients of status changes, such as lock revocation.
We'd like to offer these dissectors to Wireshark users for help in debugging or otherwise troubleshooting MPFS-related problems. There are still a few minor changes that need to be made ( i.e. a handful of fields that aren't decoded) but the dissector is overall fairly complete and very usable.
Let me know if there are questions or feedback, or otherwise if other info is needed (like sample captures, which I don't want to send out to the mailing list).
Thanks,
Ian Schorr
EMC Corporation
svn path=/trunk/; revision=20679