746839 – NFS v4.1 Traffic not shown

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 746839 - NFS v4.1 Traffic not shown

Summary: NFS v4.1 Traffic not shown

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	wireshark
Sub Component:
Version:	6.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Jan Safranek
QA Contact:	BaseOS QE Security Team
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	750914
TreeView+	depends on / blocked

Reported:	2011-10-17 22:05 UTC by Steve Dickson
Modified:	2018-09-25 07:49 UTC (History)
CC List:	3 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-12-06 19:04:33 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
The Patch that enables 4.1 traffic to be seen... (5.68 KB, application/octet-stream) 2011-10-17 22:05 UTC, Steve Dickson	no flags	Details
tshark capture of NFS4.1 traffic (5.84 KB, application/x-gzip) 2011-10-31 06:55 UTC, Karel Srot	no flags	Details
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHEA-2011:1772	0	normal	SHIPPED_LIVE	wireshark enhancement update	2011-12-06 01:01:32 UTC

Description Steve Dickson 2011-10-17 22:05:19 UTC

Created attachment 528663 [details]
The Patch that enables 4.1 traffic to be seen...

Description of problem:
NFS v4.1 is technical preview in RHEL6.2. The current wireshark
does not show v4.1 traffic. The attached patch enables 4.1 traffic
to be seen..

Comment 2 Steve Dickson 2011-10-18 14:12:51 UTC

(In reply to comment #1)
> @Devel, we need you to provide following missing information for this bug:
> 
>  * bug reproducer / testing instructions
Create an pNFS server:
    1) Install the following rpms on a F16 box
        http://people.redhat.com/steved/pNFS/kernel-3.1.0-0.rc9.git0.3.pnfsdv31rc8.fc17.x86_64.rpm
        http://people.redhat.com/steved/pNFS/nfs-utils-1.2.4-10.pnfs.fc16.x86_64.rpm
     2) Add the 'pnfs' option to an export in /etc/exports
     3) start the server 'service nfs-server start'
On the client
     1) enable the pNFS code
         echo "alias nfs-layouttype4-1 nfs_layout_nfsv41_files" > /etc/modprobe.d/dist-nfs41.conf
     2) reboot
     3) mount -o minorversion=1 server:/export /mnt
     4) start wireshark
     5) generate nfs traffic and make sure wireshark displays the 
        traffic.

>  * all other testing instructions which would have to be executed for a 6.2
> errata
See above.

>  * update bug priority and severity
Will do... 
> 
> Without these information it is not possible to review it for qa_ack. 
> 
> Thanks!

Comment 13 Jan Safranek 2011-10-21 12:39:41 UTC

What is upstream status of this patch? Upstream NFS code is quite different and parts of this patch (e.g. the last chunk) are not there. Are you pushing it there? What's the Wireshar's bug number?

Comment 14 Jan Safranek 2011-10-21 13:24:45 UTC

The changes are tracked upstream as https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6462

Comment 16 Karel Srot 2011-10-24 11:59:22 UTC

Hi,
here are my observations from comparing tshark ouput.

1)
There are few changes in NFS opcodes, such as

DESTROY_SESSION is replaced with EXCHANGE_ID
FREE_STATEID -> CREATE_SESSION
TEST-STATEID -> SEQUENCE
SECINFO_NO_NAME -> LAYOUTGET
LAYOUTCOMMIT -> GETDEVINFO

These seems to be fixed because now they matches opcodes 
the rest of the packet, e.g.

Network File System, Ops(3): TEST-STATEID PUTFH GETATTR
      [Program Version: 4]
      [V4 Procedure: COMPOUND (1)]
      Tag: <EMPTY>
          length: 0
          contents: <EMPTY>
      minorversion: 1
      Operations (count: 3)
          Opcode: SEQUENCE (53)

became

Network File System, Ops(3): SEQUENCE PUTFH LAYOUTGET
      [Program Version: 4]
      [V4 Procedure: COMP (1)]
      Tag: <EMPTY>
          length: 0
          contents: <EMPTY>
      minorversion: 1
      Operations (count: 3)
          Opcode: SEQUENCE (53)

2)
In the short log descriptions like
NFS V4 COMP Call <EMPTY> SEQUENCE TEST-STATEID;RECLAIM-COMPLETE
becomes
NFS V4 COMP Call RECLAIM-COMPLETE

3)
Every <EMPTY> SEQUENCE TEST-STATEID; string is omitted but also
string <EMPTY> SEQUENCE TEST-STATEID;PUTFH; is omitted.
so
NFS V4 COMP Call <EMPTY> SEQUENCE TEST-STATEID;PUTFH;GETATTR GETATTR
becomes
NFS V4 COMP Call GETATTR

4)
Moreover opcodes are not doubled.

Steve, could you please confirm that all these changes are intentional. 
I am not sure with the 3rd one.

Comment 17 Steve Dickson 2011-10-24 13:26:08 UTC

(In reply to comment #16)
> Hi,
> here are my observations from comparing tshark ouput.
> 
> 1)
> There are few changes in NFS opcodes, such as
> 
> DESTROY_SESSION is replaced with EXCHANGE_ID
> FREE_STATEID -> CREATE_SESSION
> TEST-STATEID -> SEQUENCE
> SECINFO_NO_NAME -> LAYOUTGET
> LAYOUTCOMMIT -> GETDEVINFO
> 
> These seems to be fixed because now they matches opcodes 
> the rest of the packet, e.g.
> 
> Network File System, Ops(3): TEST-STATEID PUTFH GETATTR
>       [Program Version: 4]
>       [V4 Procedure: COMPOUND (1)]
>       Tag: <EMPTY>
>           length: 0
>           contents: <EMPTY>
>       minorversion: 1
>       Operations (count: 3)
>           Opcode: SEQUENCE (53)
> 
> became
> 
> Network File System, Ops(3): SEQUENCE PUTFH LAYOUTGET
>       [Program Version: 4]
>       [V4 Procedure: COMP (1)]
>       Tag: <EMPTY>
>           length: 0
>           contents: <EMPTY>
>       minorversion: 1
>       Operations (count: 3)
>           Opcode: SEQUENCE (53)
> 
> 2)
> In the short log descriptions like
> NFS V4 COMP Call <EMPTY> SEQUENCE TEST-STATEID;RECLAIM-COMPLETE
> becomes
> NFS V4 COMP Call RECLAIM-COMPLETE
> 
> 3)
> Every <EMPTY> SEQUENCE TEST-STATEID; string is omitted but also
> string <EMPTY> SEQUENCE TEST-STATEID;PUTFH; is omitted.
> so
> NFS V4 COMP Call <EMPTY> SEQUENCE TEST-STATEID;PUTFH;GETATTR GETATTR
> becomes
> NFS V4 COMP Call GETATTR
> 
> 4)
> Moreover opcodes are not doubled.
> 
> Steve, could you please confirm that all these changes are intentional. 
> I am not sure with the 3rd one.
Yes all these changes are intentional. WRT 3, The  <EMPTY> and TEST-STATEID
are invalid opts, basically garbage... Plus both SEQUENCE and PUTFH
are part of every packet so they are only shown in the packet detail window.

Comment 18 Karel Srot 2011-10-26 08:56:16 UTC

Hi Steve,
one more question. I have noticed that opcodes 'RECLAIM-COMPLETE' is missing in the ops summary (in verbose ouput), e.g. 

Network File System, Ops(2): SEQUENCE
    [Program Version: 4]
    [V4 Procedure: COMP (1)]
    Tag: <EMPTY>
        length: 0
        contents: <EMPTY>
    minorversion: 1
    Operations (count: 2)
        Opcode: SEQUENCE (53)
            sessionid: <DATA>
                contents: <DATA>
            seqid: 0x00000002
            slot ID: 0
            slot ID: 0
            cache this?: No
        Opcode: RECLAIM-COMPLETE (58)
    Data (4 bytes)

In the non-verbose ouput I can see this code
18   0.014900 192.168.122.26 -> 192.168.122.16 NFS V4 COMP Call RECLAIM-COMPLETE
but it is missing in the answered packet
20   0.061409 192.168.122.16 -> 192.168.122.26 NFS V4 COMP Reply (Call In 18)

All other opcodes are listed in the summary, e.g.
21   0.061614 192.168.122.26 -> 192.168.122.16 NFS V4 COMP Call PUTROOTFH GETFH GETATTR
23   0.062862 192.168.122.16 -> 192.168.122.26 NFS V4 COMP Reply (Call In 21) PUTROOTFH GETFH GETATTR

Is this something that should be fixed? I think this opcode should be listed.

Comment 19 Steve Dickson 2011-10-27 17:11:53 UTC

Can you post a binary capture of the trace in Comment 18? I would
like take a closer look with wireshark....  

Note, the SEQUENCE should not displayed in the non-verbose since
its part of every compound. But I not sure why the RECLAIM-COMPLETE
is being displayed..

Comment 20 Karel Srot 2011-10-31 06:55:56 UTC

Created attachment 530906 [details]
tshark capture of NFS4.1 traffic

Attached.

Comment 23 Steve Dickson 2011-11-01 18:52:49 UTC

(In reply to comment #18)
> Hi Steve,
> one more question. I have noticed that opcodes 'RECLAIM-COMPLETE' is missing in
> the ops summary (in verbose ouput), e.g. 
> 
> Network File System, Ops(2): SEQUENCE
>     [Program Version: 4]
>     [V4 Procedure: COMP (1)]
>     Tag: <EMPTY>
>         length: 0
>         contents: <EMPTY>
>     minorversion: 1
>     Operations (count: 2)
>         Opcode: SEQUENCE (53)
>             sessionid: <DATA>
>                 contents: <DATA>
>             seqid: 0x00000002
>             slot ID: 0
>             slot ID: 0
>             cache this?: No
>         Opcode: RECLAIM-COMPLETE (58)
>     Data (4 bytes)
> 
> In the non-verbose ouput I can see this code
> 18   0.014900 192.168.122.26 -> 192.168.122.16 NFS V4 COMP Call
> RECLAIM-COMPLETE
> but it is missing in the answered packet
> 20   0.061409 192.168.122.16 -> 192.168.122.26 NFS V4 COMP Reply (Call In 18)
> 
> All other opcodes are listed in the summary, e.g.
> 21   0.061614 192.168.122.26 -> 192.168.122.16 NFS V4 COMP Call PUTROOTFH GETFH
> GETATTR
> 23   0.062862 192.168.122.16 -> 192.168.122.26 NFS V4 COMP Reply (Call In 21)
> PUTROOTFH GETFH GETATTR
> 
> Is this something that should be fixed? I think this opcode should be listed.
Yes... we need to bring in the patch for 
    https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4469
to fix the problem you are seeing.

So lets do this... Let open another bz against this problem and
fix it in 6.3. OK?

Comment 24 Karel Srot 2011-11-02 08:44:26 UTC

filed as 750712
Thank you.

Comment 26 errata-xmlrpc 2011-12-06 19:04:33 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2011-1772.html

Note You need to log in before you can comment on or make changes to this bug.