All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Andre Heider <a.heider@gmail.com>,
	Rick Macklem <rmacklem@uoguelph.ca>,
	linux-nfs@vger.kernel.org
Subject: Re: Error writing to nfs4 with 3.11-rc1
Date: Fri, 19 Jul 2013 12:33:11 -0400	[thread overview]
Message-ID: <85DF5611-5C53-4B65-AA05-8436C9F00680@oracle.com> (raw)
In-Reply-To: <20130719161313.GA20026@fieldses.org>


On Jul 19, 2013, at 12:13 PM, "J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Wed, Jul 17, 2013 at 04:54:59PM -0400, Chuck Lever wrote:
>> By the way, the NFSv4 OPEN request parsing in Wireshark 1.10.0 is totally screwed up.  Has anyone reported this to the Wireshark community?  Wireshark 1.8.8 appears to parse OPEN requests correctly, and is able to handle the 3-word bitmask correctly.
> 
> What exactly is screwed up?

For example, if you undisclose all of the parsed elements of an OPEN reply, the parsing of the XDR is wrong and the following replies in the compound become unparsable "data".

I've reproduced this for every installation of 1.10.0, Linux and Mac OS, that I've done.

I'm looking at a trace where the client sends an unchecked create OPEN via this compound:

PUTFH, OPEN, GETFH, ACCESS, GETATTR

And here is the reply, as parsed by Wireshark.  The replies after the OPEN are rendered as 216 bytes of unparsed "data".  The Delegation Type is 2950154659.  fattr4_mode looks wrong as well, the requested mode was 644.

Close examination of the actual bytes in this reply shows that the reply sent by the server was correct XDR and a plausible result, and the client continues normal and correct operation.

Network File System, Ops(5): PUTFH OPEN
    [Program Version: 4]
    [V4 Procedure: COMPOUND (1)]
    Status: NFS4_OK (0)
    Tag: <EMPTY>
        length: 0
        contents: <EMPTY>
    Operations (count: 5)
        Opcode: PUTFH (22)
            Status: NFS4_OK (0)
        Opcode: OPEN (18)
            Status: NFS4_OK (0)
            stateid
                [StateID Hash: 0xaf36]
                seqid: 0x00000001
                Data: 01db0fb0ac64000000000000
            change_info
                Atomic: Yes
                changeid (before): 5901652787232948527
                changeid (after): 5901653255478300828
            results_flags: Unknown (0x00000006)
                .... .... .... .... .... .... .... ...0 = mlock: Unknown (0)
                .... .... .... .... .... .... .... ..1. = confirm: OPEN4_RESULT_MLOCK (1)
            Attr mask[0]: 0x00000010 (SIZE)
                reqd_attr: SIZE (4)
                    size: 42949672960
            Attr mask[1]: 0x00000002 (MODE)
                reco_attr: MODE (33)
                    fattr4_mode: 044
                        .... .... .... .... 000. .... .... .... = Name: Unknown (0)
                        .... .... .... .... .... 0... .... .... = Set user id on exec: No
                        .... .... .... .... .... .0.. .... .... = Set group id on exec: No
                        .... .... .... .... .... ..0. .... .... = Save swapped text even after use: No
                        .... .... .... .... .... ...0 .... .... = Read permission for owner: No
                        .... .... .... .... .... .... 0... .... = Write permission for owner: No
                        .... .... .... .... .... .... .0.. .... = Execute permission for owner: No
                        .... .... .... .... .... .... ..1. .... = Read permission for group: Yes
                        .... .... .... .... .... .... ...0 .... = Write permission for group: No
                        .... .... .... .... .... .... .... 0... = Execute permission for group: No
                        .... .... .... .... .... .... .... .1.. = Read permission for others: Yes
                        .... .... .... .... .... .... .... ..0. = Write permission for others: No
                        .... .... .... .... .... .... .... ...0 = Execute permission for others: No
            Delegation Type: Unknown (2950154659)
    [Main Opcode: OPEN (18)]
    Data (216 bytes)

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com





  reply	other threads:[~2013-07-19 16:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 18:55 Error writing to nfs4 with 3.11-rc1 Andre Heider
2013-07-17 19:10 ` Chuck Lever
2013-07-17 19:35   ` Andre Heider
2013-07-17 20:54     ` Chuck Lever
2013-07-19 16:13       ` J. Bruce Fields
2013-07-19 16:33         ` Chuck Lever [this message]
2013-07-19 17:55           ` J. Bruce Fields
2013-07-19 18:03             ` Chuck Lever
2013-07-24 14:26             ` J. Bruce Fields
2013-07-17 21:59     ` Myklebust, Trond
2013-07-18 14:57       ` Andre Heider

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85DF5611-5C53-4B65-AA05-8436C9F00680@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=a.heider@gmail.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rmacklem@uoguelph.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.