Crash due to a g_snprintf() incorrect (too large) "max number of bytes" parameter.
Note that g_snprintf() apparently writes to (initializes ?) bytes beyond the
actual string written.
Fixes Bug #7948: (To be confirmed by the user)
See: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7498
svn path=/trunk/; revision=44111
offset returned from dissect_nfs_open_claim4, dissect_nfs_openflag4 were different
when we were building tree and where we didn't.
Fix other similar cases.
svn path=/trunk/; revision=43576
Followup to r42283: the loop which allocates operation summaries may not run
to completion, so don't try to free all the operation summaries.
svn path=/trunk/; revision=42303
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7209 :
Followup to r42283: the loop which allocates operation summaries may not run
to completion, so don't try to free all the operation summaries.
svn path=/trunk/; revision=42302
While developing SP4_MACH_CRED support for the linux nfs client, I noticed that
wireshark was displaying these bitmasks incorrectly (as fattrs instead of NFS
operations).
I also noticed that BACKCHANNEL_CTL (a required value in the mask for
SP4_MACH_CRED) wasn't in names_nfsv4_operation[], so I added it and verified
that we're not missing any other ops.
svn path=/trunk/; revision=41851
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