| Bug ID |
12361
|
| Summary |
Make MPA a desictor
|
| Product |
Wireshark
|
| Version |
1.12.3
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Enhancement
|
| Priority |
Low
|
| Component |
Capture file support (libwiretap)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Version 1.12.3 (v1.12.3-0-gbb3e9a0 from master-1.12)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Jan 7 2015),
with
AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz, with 8097MB of physical memory.
Built using Microsoft Visual C++ 10.0 build 40219
--
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.
You are receiving this mail because:
- You are watching all bug changes.