Dear all,
I agree that it is a bug that the same portion of the packet is
reported multiple
times and that needs to be fixed.
But it is another point if you want only information of one protocol in
the Info
Column. Currently it can happen that the SCTP dissector puts a SACK in
that and
than several upper layer append its information. I think this is useful
on the
one hand, sometimes irritating on the other. But this is a general
problem with
SCTP being able to hold quite different upper layer packets in one SCTP
packet.
So I think it IS intentional that the information from SCTP and M3UA
remains in
the Info Column when ISUP appends also something. It is only a bug that
M3UA
puts in DATA and that ISUP dissects it.
Best regards
Michael
On Friday, Apr 11, 2003, at 23:00 Europe/Berlin, Jeff Morriss wrote:
Jeff Morriss wrote:
Jeff Morriss wrote:
Guy Harris wrote:
On Fri, Apr 11, 2003 at 03:29:14PM -0400, Jeff Morriss wrote:
This is useful in M2PA and M3UA because it's possible to have
multiple ISUP messages in a single SCTP message. Currently the
Info column reflects only the last ISUP message in an SCTP message
(and the current text is too verbose to include it multiple times
in a single Info column).
Your new code doesn't clear the Info column out, so whatever stuff
SCTP
and MTP3 or M3UA put there put there will remain there; is that
intentional?
Actually, yes: SCTP, M2PA, MTP3, and (hopefully--I haven't checked)
M3UA don't put anything in the Info column if a subdissector was
called.
Hmmm, (as Murphy would have us expect) I should have checked before
sending that last email...
Currently M3UA does put the message type in the Info column even if a
subdissector is called.
This behavior does lead to "double entries" in the Info column when
using SCCP or ISUP over M3UA (e.g., "DATA IAM DATA IAM DATA IAM" or
"DATA UDT DATA UDT DATA UDT").
I'll see if I can work up a patch to M3UA so that it only puts stuff
in the Info column if no subdissector was called.
Attached is a patch that does this. (Of course it relies on global
variables, but I don't think there's a way around that.)
Unless someone can think if a better way (or disagrees in principle),
please consider for inclusion.
--
Jeff Morriss
Senior Software Support Engineer
Ulticom, Inc.
Helpdesk: +1-856-787-2765
Fax: +1-856-222-9947
<packet-m3ua.patch.gz>