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
Sort certain value_string arrays to be in ascending numeric order;
Do minor whitespace cleanup and reformatting of long lines.
svn path=/trunk/; revision=34780
The NFS dissector (all versions) show access types that have not been requested
to be checked as "not allowed" in the call and reply. This is incorrect and
misleading. At present one must manually compare what was requested in order
to assess if access was actually denied for that type. When there are hundreds
or thousands of these ACCESS requests in a capture, it is not possible or
practical to manually check each one.
The submitted patch does the following:
* Passes the access mask in the call to the reply for comparison
* Adds filterable fields for each supported (v4) and access type
* Adds a pseudo field, nfs.access_denied
* Lists the access types to be checked in the summary and tree
* Separately lists the supported, denied, and allowed access types in the
summary and tree
The changes are applied to all NFS versions.
From me: a couple of small changes to make it compile without warnings.
svn path=/trunk/; revision=34141
Decode of SETCLIENTID calls in the Windows x86 version fail with "[Dissector
bug, protocol NFS: STATUS_ACCESS_VIOLATION: dissector accessed an invalid
memory address]". This error occurs in packet-nfs.c in
dissect_nfs_clientaddr4() where vars 'protocol' and 'universal_ip_address' get
stepped on following the call to scanf(). The b1-b10 vars are declared as
quint8. While "hh" modifier used in the scanf() is documented in Linux to
correspond to an a signed/unsigned char arg, I cannot find a similar
designation in Windows (MSDN). The Windows C compiler interprets %hhu as
corresponding to a int16 rather than int8.
svn path=/trunk/; revision=34115
"hf_slotid4 is used for all possible slotid fields in sequence op. This patch
separates them out and makes it useful for filtering."
See: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4995
svn path=/trunk/; revision=33601
NFSv4 COMMIT Requests are not decoded. NFS "malformed packet" logic is
tripped.
This was a bug introduced with the changes in bug 4975. The dissector
erroneously tries to decode 4 bytes past the end of the packet.
A patch is attached that fixes that, as well as adds "Offset" info in the Info
column for COMMIT calls.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4990
svn path=/trunk/; revision=33478
packet-nfs.c:699: warning: type defaults to 'int' in declaration of 'nfsv4_operation_tiers'
packet-nfs.c:9583: warning: unused variable 'saved_fh_hash'
packet-nfs.c:9580: warning: unused variable 'name'
svn path=/trunk/; revision=33448
Add the data read/write length to the NFS tree so it is filterable.
From me: don't bother incrementing the offset just to decrement it again.
Change the hf info a bit.
(Ideally the RPC dissector would add the length to the tree not as a text
item; that is left for future work.)
svn path=/trunk/; revision=33101
"The method used in packet-nfs.c to calculate a 32-bit hash representing the
32-byte filehandle is faulty in that the hash often matches multiple
filehandles."
"This patch uses CRC-32 to calculate the hash.
We (EMC GNS) have tested this patch for the past two years and we have not
found a single case where the hash matched more than one filehandle."
See Bug #4839: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4839
svn path=/trunk/; revision=33079
Add field 'nfs.ops.count' in the detail pane of NFSv4 calls and replies that
displays the number of operations in NFSv4 COMPOUND requests/replies.
From me: change the blurb wording a bit.
svn path=/trunk/; revision=33069
Display the fsid (filesystem ID) in decimal as well as hex in the "attributes"
section of the header in NFSv3/v4 replies.
svn path=/trunk/; revision=33068
Currently parsing of the Exchange_Id is technically correct but hard to read.
This patch updates display inline with data structures specified in RFC 5661.
svn path=/trunk/; revision=31805
Dynamically register callback dissector based on the NFSv4.0 SETCLIENTID args
(the equivalent of what had already been done for NFSv4.1 CREATE_SESSION).
Fix CB_LAYOUTRECALL dissecting: the recall type wasn't getting parsed, so some
of the layout recall info wasn't being displayed.
Parse CB_SEQUENCE's referring call lists.
svn path=/trunk/; revision=31804
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
Guy Harris