https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213
--- Comment #11 from Parav Pandit <paravpan...@yahoo.com> --- 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. <addr A, addr B, -1, dest QPN B> <addr B, addr A, -1, dest QPN A> > 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 <wireshark-bugs@wireshark.org> 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
