Both deviceid4 and sessionid4 are currently decoded as rpc_opaque_data - this
means their values are never displayed in the "Packet Detail" section and to
see them you have to select the name in the "Packet Detail" section and look at
the byte range in the "Packet Bytes" section.
The attached patch (against today's SVN) adds dissectors for both so these
values are displayed in the "Packet Detail" section.
svn path=/trunk/; revision=41417
Essentially: generate tvbuffs as needed; don't save them for later reuse
with the result they are never freed.
Also:
- move a struct from packet-nfs.h to packet-nfs.c since it's only used locally;
- reformat some long lines.
svn path=/trunk/; revision=40205
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
Add some missing code: improves display of "main_opcode" field: Coverity 991, 993 & 994;
Fix bug introduced a while back: "changeinfo4" field details aren't displayed: Coverity 992;
Add missing code so READDIR (V4) details are shown in a subtree (as presumably was originally intended);
Fix some indentation.
svn path=/trunk/; revision=36525
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