Wireshark-dev: Re: [Wireshark-dev] [PATCH] LIBNDR_FLAG_NOALIGN support in wireshark and PIDL
I have checked in the wireshark patch in anticipation for the pidl patches.
One nice thing that this allows is that we may soon be able to use
pidl to describe a whole lot of additional, normal,
protocols, just like the samba project already does.
I would like to experiment creating such a dissector and document the
process later for the wireshark project for use.
One nice thing is that PIDL is an actively supported and maintained
tool to do exactly that. A single language to describe several types
of protocols.
On Wed, Jan 20, 2010 at 10:33 AM, Julien Kerihuel
<j.kerihuel@xxxxxxxxxxxxxx> wrote:
> On Wed, 2010-01-20 at 08:50 +1100, ronnie sahlberg wrote:
>> Can you send me your new di->no_align patch and Ill check it in right
>> now.
>>
>> I started applying it yesterday but modified it (to ensure we always
>> initialize di->no_align in get_next_di(), but will reverse these local
>> changes
>> so they wont collide with your patch.)
>>
>>
>> This patch can be applied right now, in anticipation of adding the
>> pidl patches later.
>
> Ronnie,
>
> Thanks I was looking for a correct place to initialize the variable.
> The new version of the patch is attached to this e-mail.
>
> Cheers,
> Julien.
>
>>
>>
>>
>>
>> On Wed, Jan 20, 2010 at 1:58 AM, Julien Kerihuel
>> <j.kerihuel@xxxxxxxxxxxxxx> wrote:
>> On Tue, 2010-01-19 at 13:44 +1300, Jelmer Vernooij wrote:
>> > On Tue, 2010-01-19 at 11:13 +1100, ronnie sahlberg wrote:
>> > > The wireshark patch for this is fine.
>> > >
>> > > I can apply these two patches to wireshark if you want me to.
>> >
>> > > Is the pidl patch ok with the upstream pidl maintainer (jelmer?) ?
>> > It's mostly ok, but it should be looking at the alignment information in
>> > the level table rather than looking at IDL properties directly.
>> Looks OK for me, I'll rework the patch to fetch information
>> there rather than within properties directly. It may however
>> require some time (few days). I'm currently trying to
>> implement other things within wireshark/pidl for string
>> support.
>>
>> FYI, similarly to the nstring/astring patch, I have added a
>> wireshark/pidl implementation for ascstr3
>> [size(16bit)][string] based on the same logic - in this case
>> we look whether we have .*LIBNDR_FLAG_STR_SIZE2.* flag or not
>> associated to the IDL element - type being obviously string.
>>
>> Finally I have found a couple more functions where I forgot to
>> propagate the di->no_align fix in packet-dcerpc.c (including
>> the dissect_nastring one).
>>
>> It tends to be a little difficult to maintain all the patches
>> properly and I'm not very good at svn diff and diff
>> editing ... Anyway will do the necessary changes and come with
>> an updated version here.
>>
>> Cheers,
>> Julien.
>>
>>
>>
>> > > On Tue, Jan 19, 2010 at 1:25 AM, Julien Kerihuel
>> > > <j.kerihuel@xxxxxxxxxxxxxx> wrote:
>> > > > Hi Lists,
>> > > >
>> > > > Prior submitting the wireshark's part of this patch onto the wireshark
>> > > > bugzilla, I thought it might be worthwhile to have feedback from
>> > > > developers first.
>> > > >
>> > > > MAPI content is non-NDR compatible. It can be dissected using the
>> > > > existing NDR layer functions in epan/dissectors/packet-dcerpc-ndr.c but
>> > > > it requires offsets to be left intact prior effective dissection, which
>> > > > means there shouldn't be any offset adjustment when LIBNDR_FLAG_NOALIGN
>> > > > flag is used in PIDL.
>> > > >
>> > > > The following patches implement such behavior:
>> > > > 1. It adds a no_align gboolean variable to dcerpc_info structure
>> > > > (default set to FALSE)
>> > > > 2. when pidl generates the code and LIBNDR_FLAG_NOALIGN flag is used, it
>> > > > sets the no_align gboolean to TRUE which turns offste adjustment off in
>> > > > wireshark.
>> > > >
>> > > > I couldn't come up with a nicer solution so far, but these tiny patches
>> > > > truly improves the overall development effort for the MAPI dissector. It
>> > > > basically prevents from writing hand-written code for most of the MAPI
>> > > > calls. This also means this may help keeping the conformance files - in
>> > > > particular request.cnf.c and response.cnf.c - readable and prevent them
>> > > > from exponentially growing up.
>> > > >
>> > > > Another advantage is that it becomes conceivable to generate code for
>> > > > structures or others some non-dceprc dissectors using pidl. You would
>> > > > only have to describe the structures, specify LIBNDR_FLAG_NOALIGN flag
>> > > > and you would have automatic dissection code generated which you can
>> > > > refer to (or cut and paste).
>> > > >
>> > > > Cheers,
>> > > > Julien.
>> > > >
>> > > > ---
>> > > >
>> > > > Julien Kerihuel
>> > > > j.kerihuel@xxxxxxxxxxxxxx
>> > > > OpenChange Project Manager
>> > > >
>> > > > GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
>> > > >
>> > > >
>> > > >
>> >
>>
>>
>> Julien Kerihuel
>> j.kerihuel@xxxxxxxxxxxxxx
>> OpenChange Project Manager
>>
>> GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F
>> 1F79
>>
>>
>>
>>
> --
> Julien Kerihuel
> j.kerihuel@xxxxxxxxxxxxxx
> OpenChange Project Manager
>
> GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
>
>
