Wireshark-bugs: [Wireshark-bugs] [Bug 12361] Register iwarp_mpa dissector by name (or make it wo
Michael Mann
changed
bug 12361
| What |
Removed |
Added |
| CC |
|
mmann78@netscape.net
|
Comment # 5
on bug 12361
from Michael Mann
> Today the DDP/RDMAP are registered as a dissector while the
> MPA doesn't. The problem we're trying to solve is that when we have a big
> trace that the MPA request/reply is not part of it (was override by newer
> packets) the Wireshark is not able to parse it since it expects to see the
> MPA request/reply.
> We want to write a plugin that will give the ability to
> the user to decode the TCP packets as iWARP.
> The thing is that since MPA is
> not a dissector we can't use it from the plugin, so we should parse the MPA
> by ourselves and then call the DDp/RDMAP dissector.
> Having MPA as a
> dissector will make the plugin be very simple.
p1.pcapng shows
TCP
IWARP MPA
DDP/RDMA
Are you looking for
TCP
IWARP (Lua plugin)
MPA or DDP/RDMA (determined by IWARP Lua plugin)
If so, it's a simple 1 line addition to the MPA dissector
Or just
TCP
IWARP MPA
DDP/RDMA
(when request/response not seen)
This won't work with the MPA dissector as currently constructed because the MPA
dissector has pretty strict heuristics. I did try this by registering the
current dissector with tcp.port dissector table and using Decode As on
p1WithoutMPA.pcap. The MPA heuristics failed and the dissection didn't look
any different. Not sure what the MPA dissector is supposed to look like
without those heuristics.
https://code.wireshark.org/review/15199 allows
TCP
DDP/RDMA
But that doesn't look right in p1WithoutMPA (no malformed packets, but DDP/RDMA
dissector isn't "claiming" all of the bytes)
You are receiving this mail because:
- You are watching all bug changes.
