Wireshark · Wireshark-users: Re: [Wireshark-users] understanding DT1 reassembly

[Ariel Burbaickij <ariel.burbaickij@xxxxxxxxx>]

Hello Jeff,
thank you for your detailed answer. Re-reading of Q.711  helped  me here, indeed :-). Class 1 is indeed the one with guaranteed in-sequence delivery, so in this case it is all clear.

/wbr

Ariel Burbaickij

On Tue, Nov 26, 2013 at 9:03 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:

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).

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe