Ethereal-dev: Re: [Ethereal-dev] MAPI
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Todd Sabin <tsabin@xxxxxxxxxxxxx>
Date: 23 May 2002 18:52:09 -0400
Guy Harris <guy@xxxxxxxxxx> writes: > On Fri, May 24, 2002 at 07:48:04AM +1000, Ronnie Sahlberg wrote: > > I checked in an initial DCERPC MAPI stub dissector. Cool. Are you planning to look at MAPI in depth? > > Perhaps we should now remove packet-mapi.c ? > > Sounds good to me. Yes. > The only issue I can think of is that MAPI uses connection-oriented RPC, > so I think that means that MAPI traffic won't be identified as such > unless a bind request was captured. However, I have the impression MAPI > might always use port 1065; Not true. It just uses a dynamic port. It's probably the case that a given exchange server will initially grab the same port every boot, provided the same services start in the same order, etc. It sounds like your exchange server gets 1065 that way, but, e.g., mine is listening on 1045. And if you just stop the exchange services and restart them, they'll be on different ports. > if so, perhaps there should be a mechanism to > explicitly indicate that a particular port number is used for a > particular DCE RPC service? The Decode as... option? or would there need to be a special "Decode as DCERPC <foo>" so that DCERPC would get it first? Along the same lines, I had an idea a while back which I haven't implemented. Basically, the DCERPC dissector would do heuristic handoffs for packets for which it hasn't seen a Bind, and subdissectors could register if they wanted to try to recognize stuff. I'm not sure how well that would work in practice, as stub data can be interpreted in a variety of ways, but it may be worth a try. Todd p.s. attached is a skeleton for the NSPI interface, which often accompanies MAPI stuff. The function names are from using NetMon on some generated traffic. Too bad NetMon doesn't have a MAPI dissector. p.p.s. This is really just a nitpick, but does it make sense to have separate .h files for dcerpc subdissectors? Currently, the only thing in them is #defines which are used in exactly one place (the dcerpc_sub_dissector struct). And it's hard to see where else they'd be used. I'd just as soon see the raw number, myself. Anyway, not a big deal...
/* packet-dcerpc-nspi.c * Routines for dcerpc nspi dissection * Copyright 2001, Todd Sabin <tsabin@xxxxxxxxxxxxx> * * $Id: $ * * Ethereal - Network traffic analyzer * By Gerald Combs <gerald@xxxxxxxxxxxx> * Copyright 1998 Gerald Combs * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #ifdef HAVE_CONFIG_H #include "config.h" #endif #ifdef HAVE_SYS_TYPES_H #include <sys/types.h> #endif #include <string.h> #include <glib.h> #include "packet.h" #include "packet-dcerpc.h" static int proto_nspi = -1; static gint ett_nspi = -1; static e_uuid_t uuid_nspi = { 0xf5cc5a18, 0x4264, 0x101a, { 0x8c, 0x59, 0x08, 0x00, 0x2b, 0x2f, 0x84, 0x26 } }; static guint16 ver_nspi = 56; static dcerpc_sub_dissector nspi_dissectors[] = { { 0, "NspiBind", NULL, NULL }, { 1, "NspiUnbind", NULL, NULL }, { 2, "NspiUpdateStat", NULL, NULL }, { 3, "NspiQueryRows", NULL, NULL }, { 4, "NspiSeekEntries", NULL, NULL }, { 5, "NspiGetMatches", NULL, NULL }, { 6, "NspiResortRestriction", NULL, NULL }, { 7, "NspiDNToEph", NULL, NULL }, { 8, "NspiGetPropList", NULL, NULL }, { 9, "NspiGetProps", NULL, NULL }, { 10, "NspiCompareDNTs", NULL, NULL }, { 11, "NspiModProps", NULL, NULL }, { 12, "NspiGetHierarchyInfo", NULL, NULL }, { 13, "NspiGetTemplateInfo", NULL, NULL }, { 14, "NspiModLinkAttr", NULL, NULL }, { 15, "NspiDeleteEntries", NULL, NULL }, { 16, "NspiQueryColumns", NULL, NULL }, { 17, "NspiGetNamesFromIDs", NULL, NULL }, { 18, "NspiGetIDsFromNames", NULL, NULL }, { 19, "NspiResolveNames", NULL, NULL }, { 0, NULL, NULL, NULL }, }; void proto_register_nspi (void) { static gint *ett[] = { &ett_nspi, }; proto_nspi = proto_register_protocol ("NSPI", "NSPI", "nspi"); proto_register_subtree_array (ett, array_length (ett)); } void proto_reg_handoff_nspi (void) { /* Register the protocol as dcerpc */ dcerpc_init_uuid (proto_nspi, ett_nspi, &uuid_nspi, ver_nspi, nspi_dissectors); }
- Follow-Ups:
- Re: [Ethereal-dev] MAPI
- From: Guy Harris
- Re: [Ethereal-dev] MAPI
- From: Guy Harris
- Re: [Ethereal-dev] MAPI
- From: Ronnie Sahlberg
- Re: [Ethereal-dev] MAPI
- From: Ronnie Sahlberg
- Re: [Ethereal-dev] MAPI
- References:
- [Ethereal-dev] MAPI
- From: Ronnie Sahlberg
- Re: [Ethereal-dev] MAPI
- From: Guy Harris
- [Ethereal-dev] MAPI
- Prev by Date: Re: [Ethereal-dev] MAPI
- Next by Date: Re: [Ethereal-dev] MAPI
- Previous by thread: Re: [Ethereal-dev] MAPI
- Next by thread: Re: [Ethereal-dev] MAPI
- Index(es):