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
- Added support for the optional "flag" field in the SVR4 NFS file handle
(checked with OpenSolaris, NFSv3 and NFSv4).
When the server file system is UFS, the SVR4 decoding works fine. ZFS still
needs some work.
I'm one of the "5 people or less in the world" (see checkin comment r18530),
who care about the inner structure of NFS file handles. I may even re-enable
the heuristics to determine the file handle type automatically, but the old
NETAPP heuristics was definitely much too weak.
svn path=/trunk/; revision=26871
NFSV4 parsing of the GETATTR reply is broken. I'm not sure what is going on,
but I re-wrote the GETATTR parsing anyways and my version of the parsing does not
exibit the same problems.
svn path=/trunk/; revision=26304
callback address/port with only 2 octets (high/low port) i.e. witout
specifying the ip address.
this caused wireshark to corrupt memory when trying to 0-terminate the
original string after the fourth '.' which happened to be beyond the
end of the string.
svn path=/trunk/; revision=26296
when we check and ignore the two names "." and ".."
we must do so for both methods a caller can provide the name :
offset into a tvb, as well as a char* to a string.
also add ->full_name in the dissection to the replies so that fh
matches
both request and reply and not ->name
svn path=/trunk/; revision=25941
Tigran Mkrtchyan: decode and display fattr4_fs_layout_types.
Thijs Stuurman: Synchronize names used by wireshark with those used in
latest pnfs draft.
J. Bruce Fields: Use large default max_rpc_tcp_pdu_size setting
The linux server will do up to 1M these days, so the current default is
very likely to discard all reads and writes from such a server.
Thanks to Jim Rees for catching this.
Jeff Morriss: limit the max_rpc_tcp_pdu_size increase to 4M instead of the 16M
proposed. Memory is cheap but still not unlimited.
svn path=/trunk/; revision=25769
The attached patches bring the wireshark code up to date with the latest
NFSv4.1 protocol drafts (in ietf last call now, so hopefully not too much more
of this will be required).
They also cover more of the protocol, and do some minor cleanup (e.g. remove
some operations which were really only used by one prototype implementation,
and never part of the protocol.)
A few ops and attributes are still missing.
svn path=/trunk/; revision=25727
When parsing nfsv4 GETATTR reply in attribute fs_location wireshark displays incorrect content for the attribute value. It looks like instead of parsing as rpc arrays, value gets parsed as
rpc linked list. This patch which fixes the problem
I also noticed that FATTR4_MOUNTED_ON_FILEID attribute is not getting parsed, so I added parsing for that as well.
svn path=/trunk/; revision=23917
It looks like in dissect_nfs_open_claim_delegate_cur4() instead of dissection
stateid we are doing something wierd and dissecting uint64 instead(remnants of
rfc3010 where stateid was 64 bit number?). We already have function for
dissecting stateids, so just a matter of making a different call.
From me:
Also deleted the hf_nfs_stateid4_delegate_stateid entry.
svn path=/trunk/; revision=23571
Add basic support for NFSv4.1, as of about draft 13 of the current spec.
The protocol is not completely finished yet, and future patches will be
needed to bring it up to date.
From me:
- Add a check for valid pointers in nfsv4_operation_ett
- Always increase offset when calling dissect_nfs_devices4
- Added a default case in dissect_rpc_secparms4
svn path=/trunk/; revision=23570
(the old one was mapping file handles that differed only by one bit to
the same hash value; the new one mapped them to different hash values).
svn path=/trunk/; revision=22065
routines and routines using those routines. GLib might use different
modifiers for 64-bit quantities than the platform's C library does.
svn path=/trunk/; revision=21990
Fix an obvious error in the nfs4 stateid parsing. The stateid is used in a number of common operations (such as open and setattr), so this caused a lot of misparsing.
svn path=/trunk/; revision=20700
This patch adds support for dissecting ontap's nfsv4 filehandle,
as well as some updates to nfsv3 filehandle as well in the nfs
dissector.
Alex.
checked in with minor changes
svn path=/trunk/; revision=19345
replace overly convoluted code with much simpler code.
stateid is a simple 16 byte structure and there is no need to make it more complex than it is.
svn path=/trunk/; revision=18555
1, (minor) the heuristics are too weak and everyting is always decoded either as netapp filehandles or one of the others even when just capturing ibetween say two classic unix boxens
2, (major) you can not filter on specific subfields of the filehandle
observation: 5 people or less in the world care about implementation specific storage of data inside an opaque blob.
remove the too weak heuristics for nfs filehandles.
make decoding of filehandles accorrding to specific implementations controlled by a preference setting.
default this setting to "unknown"
display unknown filehandles using proto_tree_add_item() FT_BYTES/BASE_HEX to make it fitlerable instead of a useless proto_tree_add_text()
wiki needs to be updated tomorrow
svn path=/trunk/; revision=18530
put useful info like type,mode,uid,gid on the expansion lines so we dont have to open the expansion to see these values.
allow it to push this info multiple expansion lines upward
and optionally (such as for GETATTR replies) put this info in the info column as well
svn path=/trunk/; revision=17783
