[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wireshark-dev
Subject:    [Wireshark-dev] Fwd: understanding DT1 reassembly
From:       Ariel Burbaickij <ariel.burbaickij () gmail ! com>
Date:       2013-11-25 7:29:19
Message-ID: CANeJNHrg-z2ScnBkXRTFk52JLZBCo62UPc22wP479Vys7wWzDA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


OK, maybe wireshark-users was a wrong list with little in terms of overlap
with wireshakr-dev. So, could you, please, shed some light on the topic
raised?

---------- Forwarded message ----------
From: Ariel Burbaickij <ariel.burbaickij@gmail.com>
Date: Sat, Nov 23, 2013 at 10:08 AM
Subject: understanding DT1 reassembly
To: Community support list for Wireshark <wireshark-users@wireshark.org>


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)
2) last DT1 segment  (also no more segments in the segmentation/reassembly
mask)

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?

/wbr
Ariel Burbaickij

[Attachment #5 (text/html)]

<div dir="ltr">OK, maybe wireshark-users was a wrong list with little in terms of \
overlap with wireshakr-dev. So, could you, please, shed some light on the topic \
raised?<br><div><br><div class="gmail_quote">---------- Forwarded message \
                ----------<br>
From: <b class="gmail_sendername">Ariel Burbaickij</b> <span dir="ltr">&lt;<a \
href="mailto:ariel.burbaickij@gmail.com">ariel.burbaickij@gmail.com</a>&gt;</span><br>Date: \
                Sat, Nov 23, 2013 at 10:08 AM<br>Subject: understanding DT1 \
                reassembly<br>
To: Community support list for Wireshark &lt;<a \
href="mailto:wireshark-users@wireshark.org">wireshark-users@wireshark.org</a>&gt;<br><br><br><div \
dir="ltr"><div><div><div><div><div><div><div><div>Hello all,<br></div>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.<br>

</div>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:<br></div>How wireshark discerns following two \
possibilities:<br>

</div>1) first AND last DT1 segment (no more segments in the segmentation/reassembly \
mask)<br></div>2) last DT1 segment  (also no more segments in the \
segmentation/reassembly mask)<br><br></div>what I mean in particular with discerning \
is how wireshark &quot;knows&quot; 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?<br>

<br></div>/wbr<span class="HOEnZb"><font \
color="#888888"><br></font></span></div><span class="HOEnZb"><font \
color="#888888">Ariel Burbaickij  <br></font></span></div> </div><br></div></div>



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

[prev in list] [next in list] [prev in thread] [next in thread]