Re: understanding DT1 reassembly

[Ariel Burbaickij <ariel.burbaickij () gmail com>]

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 () gmail com>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 () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org?subject=
> unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe