Wireshark-bugs: [Wireshark-bugs] [Bug 13202] RPC-over-RDMA dissector no longer identifies any va

Date: Thu, 08 Dec 2016 15:28:21 +0000

Comment # 14 on bug 13202 from
(In reply to Parav Pandit from comment #13)
> (In reply to Chuck Lever from comment #12)
> > 
> > Before changing anything, only the raw InfiniBand traffic appeared.
> > 
> > After removing the find_or_create_conversation() call site from
> > packet-rpcrdma.c as 19107 does, RPC Calls were properly decoded as NFS
> > requests, but RPC Replies appeared as "RPC ### V0 proc-0 Reply". This means
> > the RPC dissector was not able to match the XID of each Reply to a previous
> > Call message.
> > 
> > Though this is still broken, this is the until-now normal behavior for
> > RPC-over-RDMA, up until the "remove duplicate conversations from
> > packet-infiniband.c" patch. In a capture of NFS on IPoIB or NFS on TCP, you
> > will see the proper expected way NFS Replies are supposed to appear.
> > 
> > After I applied the packet-infiniband.c hunk of 19107, nothing changed.
> > 
> > Thus my humble conclusion is that the packet-rpcrdma.c hunk of 19107 is the
> > part that fixes the regression introduced by "remove duplication
> > conversations" . The packet-infiniband.c hunk does not appear to change the
> > behavior of either the RPC or RPC-over-RDMA dissector.
> > 
> > 
> > > > I've filed bug 13213 to separately document the RPC reply dissection failure.
> > 
> > I'll attach my fix to 13213, and we can compare and discuss both approaches.
> > I see why fixing packet-infiniband.c might affect more ULP dissectors, and
> > thus it might be a more broad fix. Getting PT_IBQP and PT_TCP conversations
> > to behave more alike is probably a desirable long-term goal. 
> 
> Yes. This is required at minimum.
> 
> > But 19107 is
> > either not quite right, or somehow it is not enough for RPC. (Probably the
> > latter).
> I think its later. Without reading the code of packet-rpc.c I added few
> debug prints as below and I can see why it might not work for rpc as rpc
> might want to work on TCP level ports from portmap vs qp number?
> 
> update_sport frame=13 updating sport = 546, dport=525
> get_conversation_for_call frame=13 sport=55562 dport=111 conv=0x7f205dab1830
> 
> I am not able to comprehend how would ignoring src_qp in your patch fixes it.

The problem is how packet-infiniband.c sets the destination port fields in the
conversation's pinfo.

Let's take this conversation to bug 13213.


You are receiving this mail because:
  • You are watching all bug changes.