On 11/23/13 04:08, Ariel Burbaickij wrote:
Hello all,
as far as I understand from packet-sccp.c DT1 reassembly is supported by
now, SLR is used for look up in the hash table, segmentation/reassembly
mask is used for deciding whether there will be more segments or not.
packet-sccp.c is more or less piece of cake to understand, reassembly.c,
of course, in its generality, not quite so. So, it would be great if
somebody could help me to understand following aspect:
How wireshark discerns following two possibilities:
1) first AND last DT1 segment (no more segments in the
segmentation/reassembly mask)
In this case "more_frags" argument to fragment_add_seq_next() will be 0
so the reassembly code will know that the message is complete.
2) last DT1 segment (also no more segments in the
segmentation/reassembly mask)
Here again "more_frags" tells us that the reassembly is done.
what I mean in particular with discerning is how wireshark "knows" not
to attempt to dissect/decode isolated last DT1 segment (no more data are
announced here too, after all!), in particular with corner case of the
last segment arriving first in mind?
You may be assuming that out-of-order assembly works; it does not (with
SCCP). If Wireshark sees a fragment out of sequence the reassembly will
simply fail. This matches SCCP (the protocol)'s behavior since SS7
messages may be lost (e.g., due to congestion) but must never be
delivered out of order. Wireshark behaves like that primarily because
the reassemble.c code isn't designed to handle SCCP's style of fragment
counters. I imagine it could be modified to handle out-of-order
reassembly but I can't imagine it being worth the effort (and anyway it
would be a bit misleading to users if Wireshark could reassemble the
message but the receiving node couldn't).