[Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>]

Since I think it is important for an application to be
consistent for the user I always (in the SCTP, SIGTRAN and
SS7 dissectors I wrote) to go the exception way...
But SCTP and SIGTRAN all use the TLV principle, so I
can 'just' continue except the the packet/chunk/parameter
is too short. But I can even test for this to avoid raising
an exception. Currently I thought that there is this mechanism
and it is the easiest to use it. Testing for this to avoid
the exceptions is like programming for the pre-tvb API... It
can be done. This would mean that every 'malformed frame' exception
is due to some not intra-dissector handling of packets and
therefore is something which should be done better.

So if the 'common' way for error handling is to avoid exceptions
I'll update the SCTP und SIGTRAN dissectors. But you should see in
the uppermost pane that a packet has a formatting problem, so
possible a hidden field *.packet_error or so should be set. Then
one can define a color rule for that.

Best regards
Michael

On Mar 27, 2005, at 13:31 Uhr, Ulf Lamping wrote:

> Michael Tuexen wrote:
>
> > Well, I have now a trace file which shows the dissector bug message in
> > the
> > INFO field...
> >
> > So how are other protocols handling malformed packets: Raising an
> > exception
> > or handling it by itself?
>
> Well, if the protocol provides enough information so the dissector can
> handle the data in a way (maybe able to continue with next data block 
> or
> alike), it could handle it by adding an "invalid data" (or alike) into
> the tree.
>
> If the dissector cannot continue, e.g. it don't know where to continue,
> it should raise an exception.
>
> We should add a more detailed description how to handle such cases in
> the README.developer.
>
>
> I currently fix some dissectors using tvb_ensure_bytes_exist() from 
> bugs
> reported by buildbot randpkt problems. As this might not be the most
> elegant solution (performance), this should do the job for now.
>
> Regards, ULFL
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev