[Jeff Morriss <morriss@xxxxxxxxx>]

Ugh--please ignore this resubmit.  I think I did a "cvs update" in one 
source tree and looked in an older one (where I didn't see the 
change)...  <sigh>

Jeff Morriss wrote:

> Resubmitting...
>
> Note that the attached patch does the same thing as what Michael Tuexen 
> has done with the rest of the SS7 dissectors's COL_PROTOCOL fields.
>
> -------- Original Message --------
> Subject: Re: [Ethereal-dev] ISUP patch
> Date: Tue, 14 Oct 2003 10:52:39 -0400
> From: Jeff Morriss <morriss@xxxxxxxxx>
> Organization: Ulticom, Inc.
> To: ethereal-dev@xxxxxxxxxxxx
> References: <PNEOJBIEBDKKJFKMKKJLGEKNCKAA.mlum@xxxxxxxxxxxx>
>
>
> I just thought of this issue the other day--here is a very small patch
> that should avoid confusion about the fact that the ISUP dissector only
> does ITU (for the moment).
>
> Michael Lum wrote:
>
> > Yes, thanks.
> >
> > OK, to summarize:
> >
> > 1.  the snoop trace has M2UA from an older draft, the data 1 parameter is
> > 0x000e
> > 2.  the ISUP is ANSI and thus has no trailing 0x00 indicating "no 
> > optional
> > parameters"
> >
> > The end result (aside from me causing confusion) is that the ANSI RLC 
> > will
> > show up as [Malformed Packet: ISUP].
> >
> > My patch prevents the malformed by not consuming the extra octet.
> >
> > But thanks to Jeff I now know that the patch is NOT correct.
> >
> > It is an ANSI/ITU problem, for the ANSI RLC no optional parameters are
> > allowed and
> > therefore the fix would have to occur further up in the function where 
> > the
> > "opt_part_possible" boolean was set.
> >
> > Thanks, sorry for the mess.
> > I will make it up.
> >
> >
> > -----Original Message-----
> > From: Jeff Morriss [mailto:morriss@xxxxxxxxx]
> > Sent: Wednesday, August 20, 2003 6:44 AM
> > To: Guy Harris
> > Cc: Michael Lum; ethereal-dev@xxxxxxxxxxxx
> > Subject: Re: [Ethereal-dev] ISUP patch
> >
> >
> >
> > Guy Harris wrote:
> >
> > > On Fri, Aug 15, 2003 at 11:31:37AM -0700, Michael Lum wrote:
> > >
> > >
> > > > I believe the ISUP dissector has a bug when decoding the
> > > > optional parameter pointer.
> > >
> > >
> > >
> > > So what is the added check doing?  It looks as if it's checking whether
> > > the optional parameter pointer is present in the packet.
> >
> >
> >
> > It depends.  I think I read that this was an ANSI RLC.  The ISUP
> > dissector as it stands now was written for ITU ISUP.  (It appears to
> > "mostly work" for ANSI, though.)
> >
> > In ITU ISUP, the RLC message can have optional parameters (and thus a
> > pointer to optional).
> >
> > In ANSI ISUP, the RLC message does not have any optional parameters (and
> > thus no pointer to optional).
> >
> > (Porting the ISUP dissector to also do ANSI ISUP has been on my hit-list
> > for a very long time...)
>
>
>
>
> ------------------------------------------------------------------------
>
> Index: packet-isup.c
> ===================================================================
> RCS file: /cvsroot/ethereal/packet-isup.c,v
> retrieving revision 1.33
> diff -u -r1.33 packet-isup.c
> --- packet-isup.c	10 Oct 2003 10:04:19 -0000	1.33
> +++ packet-isup.c	14 Oct 2003 14:44:32 -0000
> @@ -5392,7 +5392,7 @@
>  
>  /* Make entries in Protocol column and Info column on summary display */
>  	if (check_col(pinfo->cinfo, COL_PROTOCOL))
> -		col_set_str(pinfo->cinfo, COL_PROTOCOL, "ISUP");
> +		col_set_str(pinfo->cinfo, COL_PROTOCOL, "ISUP (ITU)");
>  
>  /* Extract message type field */
>  	message_type = tvb_get_guint8(tvb, CIC_OFFSET + CIC_LENGTH);