[PATCH] LIBNDR_FLAG_NOALIGN support in wireshark and PIDL

[Jelmer Vernooij]

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. 

Cheers,

Jelmer

> On Tue, Jan 19, 2010 at 1:25 AM, Julien Kerihuel
> <j.kerihuel at openchange.org> 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 at openchange.org
> > OpenChange Project Manager
> >
> > GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79
> >
> >
> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100119/be57a6c6/attachment.pgp>