[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

Jaap Keuter  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|INCOMPLETE  |RESOLVED

--- Comment #20 from Jaap Keuter  ---
With the primary issue resolved, closing this bug. If handling of missing CREQ
is crucial this can be handled through a separate bug.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #19 from Chuck Lever  ---
The problem seems to occur only when a CREQ exchange does not appear in the
capture.

I have some captures that start during ongoing traffic. The first CREQ exchange
happens before packet capture was started.

During the initial portion of the capture data, Wireshark (the RPC dissector)
is not able to match RPC replies to RPC calls. If a disconnect / CREQ exchange
occurs during the capture, subsequent RPC traffic in the capture is properly
dissected.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #18 from Chuck Lever  ---
(In reply to Michael Mann from comment #17)
> Wireshark always does 2 passes over every packet (first pass is every packet
> in order, 2 pass isn't guaranteed to be in that order).
> TShark defaults to a single pass before output, which can affect dissectors
> that have state processing involving multiple packets, because not all
> packets are guaranteed to arrive in order.  So when you want
> request/response data, always pass -2 to TShark.

I'll give that a try next time I use tshark. The problems I see occur with
wireshark.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #17 from Michael Mann  ---
(In reply to Chuck Lever from comment #16)
> (In reply to Michael Mann from comment #15)
> (In reply to Chuck Lever from
> comment #13)
> > I may have prematurely confirmed this fix. I'm finding that
> this is still a
> > problem in TShark (Wireshark) 2.3.0
> (v2.3.0rc0-1823-gef92e9f).
> 
> Did you ensure you used -2 option in TShark
> (request/reply data typically
> needs 2 passes to work)?

I've never had to
> use -2 with NFS/TCP, didn't even know that option was there. However, the
> problem seems to be intermittent. Still investigating.

Wireshark always does 2 passes over every packet (first pass is every packet in
order, 2 pass isn't guaranteed to be in that order).
TShark defaults to a single pass before output, which can affect dissectors
that have state processing involving multiple packets, because not all packets
are guaranteed to arrive in order.  So when you want request/response data,
always pass -2 to TShark.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #16 from Chuck Lever  ---
(In reply to Michael Mann from comment #15)
> (In reply to Chuck Lever from comment #13)
> > I may have prematurely confirmed this fix. I'm finding that this is still a
> > problem in TShark (Wireshark) 2.3.0 (v2.3.0rc0-1823-gef92e9f).
> 
> Did you ensure you used -2 option in TShark (request/reply data typically
> needs 2 passes to work)?

I've never had to use -2 with NFS/TCP, didn't even know that option was there.
However, the problem seems to be intermittent. Still investigating.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

Michael Mann  changed:

   What|Removed |Added

 CC||mman...@netscape.net

--- Comment #15 from Michael Mann  ---
(In reply to Chuck Lever from comment #13)
> I may have prematurely confirmed this fix. I'm finding that this is still a
> problem in TShark (Wireshark) 2.3.0 (v2.3.0rc0-1823-gef92e9f).

Did you ensure you used -2 option in TShark (request/reply data typically needs
2 passes to work)?

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

Chuck Lever  changed:

   What|Removed |Added

 Status|CONFIRMED   |INCOMPLETE

--- Comment #14 from Chuck Lever  ---
When a CREQ/CREP exchange appears in the capture, RPC XID matching continues to
work as expected. Change 19190 addressed this issue correctly.

When there is no CREQ/CREP exchange in the trace, RPC XID matching fails, and
RPC replies appear as "V0 proc-0 Reply".

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

Chuck Lever  changed:

   What|Removed |Added

 Status|RESOLVED|CONFIRMED
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #13 from Chuck Lever  ---
I may have prematurely confirmed this fix. I'm finding that this is still a
problem in TShark (Wireshark) 2.3.0 (v2.3.0rc0-1823-gef92e9f).

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #12 from Gerrit Code Review  ---
Change 19190 merged by Michael Mann:
packet-infiniband: Update conversation src port for exact lookup

https://code.wireshark.org/review/19190

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

Gerrit Code Review  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #11 from Parav Pandit  ---
Hi Chuck,

I didn't get chance yesterday to debug this further. I did now.

(In reply to Chuck Lever from comment #10)
> (In reply to Parav Pandit from comment #9)
> > (In reply to Chuck Lever from comment #7)
> > > 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 >
> > > 
> > 
> > My patch has src_qp instead of -1 for srcport.
> 
> I assume "My patch" == the packet-infiniband.c hunk from change 19107
> 
Yes.

> I don't know what "src_qp" is. Only destination QPNs appear on the wire.
> Perhaps we should stick with calling these destination QPNs. Where are you
> getting these QPNs?
> 
Yes. only one Destination QPN appears on the wire out of 2 (one in each
direction). So below two look up cannot map to same conversation, unless we
ignore both the ports using NO_PORT_A, NO_PORT_B, which will just make it
network loop and not L4 lookup, which won't work.



> How does 19107's packet-infiniband.c hunk behave with packet-rpc.c and, say,
> the sample wire capture excerpt attached to this bug?

I tested this further and found the bug in packet-infiniband.c where
bididirectional entry has typo.
I fixed it and with that now packet-rpc.c doesn't need to deviate lookup for
TCP and Infiniband transport.

I tested attached patch excerpt.pcap of this bug and I can see frame 54's
response is in 56. 58th frames response in 60 without changes. Both match up to
same conversation without applying patch of Comment 4.
Instead of proc0 entry, I can see now "call in 58" and "reply in 56" for those
frames.

I am going to resubmit the patch with hunk of 19107 for infiniband.c along with
additional fix with this bug id. You can possibly drop the hunk to diverge code
for tcp and infiniband of packet-rpc.c

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #10 from Chuck Lever  ---
(In reply to Parav Pandit from comment #9)
> (In reply to Chuck Lever from comment #7)
> > 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 >
> > 
> 
> My patch has src_qp instead of -1 for srcport.

I assume "My patch" == the packet-infiniband.c hunk from change 19107

I don't know what "src_qp" is. Only destination QPNs appear on the wire.
Perhaps we should stick with calling these destination QPNs. Where are you
getting these QPNs?

How does 19107's packet-infiniband.c hunk behave with packet-rpc.c and, say,
the sample wire capture excerpt attached to this bug?

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #9 from Parav Pandit  ---
(In reply to Chuck Lever from comment #7)
> (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 >
> 

My patch has src_qp instead of -1 for srcport.

> 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.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #8 from Parav Pandit  ---
(In reply to Chuck Lever from comment #7)
> (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 >

find_conversation() in conversation.c first performs exact lookup on tuple
.
I was hoping that it finds it for packet-rpc.c.

I was able to confirm that it finds when I tested with nvme dissector.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #7 from Chuck Lever  ---
(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.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #6 from Parav Pandit  ---
(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. so TCP/NFS dissector would look for src and dest port of TCP?
While infiniband.c would do conversations based on src and dest qp.

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


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

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #5 from Chuck Lever  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #4 from Chuck Lever  ---
Created attachment 15113
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15113=edit
Possible fix for 13213

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

Parav Pandit  changed:

   What|Removed |Added

 CC||paravpan...@yahoo.com

--- Comment #3 from Parav Pandit  ---
Wouldn't this work once you create rpc level conversation based on pinfo
(saddr, daddr, sport, dport)?

Because my change 19107 does have all 4 of them in pinfo.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #2 from Chuck Lever  ---
The RPC dissector uses conversations to track XIDs. For TCP, one conversation
exists per socket. The XIDs for Calls and Replies are associated with this
conversation.

IB RC connections appear to be unidirectional; and their source port is set to
-1. Thus the XID matching scheme used by packet-rpc.c does not work for IB
connections.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #1 from Chuck Lever  ---
Created attachment 15112
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15112=edit
Sample capture to confirm proper dissection of RPC frames

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe