Bug 746839
| Summary: | NFS v4.1 Traffic not shown | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Steve Dickson <steved> | ||||||
| Component: | wireshark | Assignee: | Jan Safranek <jsafrane> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.2 | CC: | ebenes, ksrot, rwheeler | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-12-06 19:04:33 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 750914 | ||||||||
| Attachments: |
|
||||||||
(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! 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? The changes are tracked upstream as https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6462 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.
(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. 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.
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.. Created attachment 530906 [details]
tshark capture of NFS4.1 traffic
Attached.
(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? filed as 750712 Thank you. 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 |
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..