Jeff Morriss
changed
bug 8816
Comment # 3
on bug 8816
from Jeff Morriss
There are several issues going on here.
1) The first SCTP chunk in frame 26 is a retransmission of that in frame 24.
2) You don't have SCTP's TSN Analysis feature enabled (it's off by default) so
SCTP doesn't realize this. Because SCTP does not realize this it dissects the
payload of the retransmitted message.
3) SCCP (the protocol) expects fragments to be delivered in order and without
duplication. SCCP (the dissector) more or less assumes this too because we
haven't tried to hack up the reassembly code to work with SCCP's style of
reassembly.
The result of all of that is that the reassembly that happens in frame 26
creates a bogus message: it has the first 230 octets of the MSU twice (and no
octets from the 2nd fragment).
4) Then as TCAP dissects this bogus message it gets into the BER dissector
which sometimes sets the actual and reported TVB lengths separately (I'm not
sure why). In this case the reported length is greater than the actual length
so when the dissection fails (because the reassembly is hosed) you get a
misleading error message.
So: if you want the dissection to work, enable SCTP's TSN Analysis feature.
#3 is arguably a bug in Wireshark's reassembly stuff (SCCP stacks can detect
duplication like this so Wireshark should be able to too).
I would suspect #4 is also a bug but I don't know the BER's intentions here...
Finally:
5) The SCTP dissector is trying to catch "nonfatal" exceptions so it can
process subsequent chunks, even if an earlier chunk threw an exception. But
the exception thrown in this case (BoundsError) is not in the list so SCTP does
not attempt to process the next chunk. The question here is: should
BoundsError be in the "nonfatal" exception list or should the BER dissector not
be (ab?)using the reported length the way it is?
You are receiving this mail because:
- You are watching all bug changes.