Thanks for the 2.0 info. That will be a background task.
Back to the immediate problem of decoding GIOP replies. Looking at 1.12 & 2.0 code the problem looks to be the same. It is the bit of code that works out a
MFN (matching frame number?) from a FN and request ID. This is done by get_mfn_from_fn_and_reqid. A comment in this function says….
/* Loop back from current end of complete_request_list looking for */
/* a FN with the same reqid -- TODO enhance with port/address checks -- FS */
The TODO is the bit I’m missing.
So far as I can see nothing in this function has access to the IP addresses and port numbers of the frames being checked.
Presumably this would require comp_req_list_entry extending to include src & dest (or maybe just dest) addresses and port numbers and the get_mfn function extending
to take the address and port number of the request being searched for.
I assume this information is the src/dst/srcport/dstport entries in the packet_info structure.
Any thoughts? Does this look like the way forward.
Thanks for any help
Regards
Andy Ling
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Graham Bloice
Sent: Mon 02 November 2015 12:37
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] GIOP dissector reply decode
The Windows build for 2.0 has moved to CMake. I'm in the process of submitting a change for the Developers Guide docs, but for now README.cmake in the top level source tree should have enough to get you going,
On 2 November 2015 at 12:10, Andy Ling <Andy.Ling@xxxxxxxxx> wrote:
> Couple of thoughts from a quick skim of the code/git history:
> 1. I presume giop_complete_request_list is for matching request/reply.
> Grepping its use will probably give you some clues as to where to look.
Thanks for the pointer. Rummaging in packet-giop.c it looks like requests and replies are stored
in a hash table giop_complete_reply_hash and the key used for this is packet_info->fd->num
Does that look right, am I on the right track?
If so, then I guess I need to look at where this number comes from and if it is
used for anything else. Any help anyone?
> 2. I'd recommend using the latest dev branch (master or at least master-2.0).
> Any fixes you find would need to be applied there (master) first and then backported to 1.12 (and 2.0)
I had a quick look at 2.0. So far I've fallen over at the first hurdle. I tried following
the build instructions and the first nmake -f Makefile.nmake verify_tools fails
with a file win32.mak not found error. So I guess I'm looking at the wrong instructions.
Can someone point me at how to build 2.0 for Windows.
Thanks
Andy Ling
--
