Wireshark-bugs: [Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with R

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Thu, 08 Dec 2016 16:30:30 +0000

Comment # 7 on bug 13213 from 
(In reply to Parav Pandit from comment #6)
> (In reply to Chuck Lever from comment #5)
> > The destination port for the client-to-server conversation does not match
> > either the source port or the destination port for the server-to-client
> > conversation. This defeats the RPC dissector's conversation-based XID
> > matching mechanism.
> 
> Its IP over IB.

To be clear, NFS/RDMA is not the same as NFS on TCP on IPoIB.

> so TCP/NFS dissector would look for src and dest port of TCP?

Yes, NFS on TCP on IPoIB uses the port information established by the TCP
layer.

> While infiniband.c would do conversations based on src and dest qp.

Correct. Note, however, that the dest QPN for the client-to-server conversation
is not the same as the dest QPN for the server-to-client conversation.

> Thats what I see in the logs and in trace as below.
> 
> > update_sport frame=13 updating sport = 546, dport=525
> > get_conversation_for_call frame=13 sport=55562 dport=111 conv=0x7f205dab1830

Neither of the dport values is 20049, which is the standards-designated TCP
port used for NFS/RDMA. So I would conclude from your log that these are not
TCP ports.

> Do packet-rpc.c find conversation based on IB srcport, destport or TCP ports?

The current logic in packet-rpc.c treats PT_TCP and PT_IBQP the same, and
expects that the pinfo will be set up so that:

  In the client-to-server direction: < addr A, port A, addr B, port B >

  In the server-to-client direction: < addr B, port B, addr A, port A >

But for PT_IBQP, we have:

  In the client-to-server direction: < addr A, -1, addr B, dest QPN B >

  In the server-to-client direction: < addr B, -1, addr A, dest QPN A >

packet-rpc.c's XID-matching mechanism doesn't work with those tuples. Just
setting up the src port in the pinfo doesn't help because "dest QPN A" != "dest
QPN B" .

To make PT_IBQP work like PT_TCP, maybe you'd need:

  In the client-to-server direction: < addr A, dest QPN A, addr B, dest QPN B >

  In the server-to-client direction: < addr B, dest QPN B, addr A, dest QPN A >

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