static guint
get_sabp_pdu_len(packet_info *pinfo _U_, tvbuff_t *tvb, int offset)
{
guint32 type_length;
int bit_offset;
asn1_ctx_t asn1_ctx;
asn1_ctx_init(&asn1_ctx, ASN1_ENC_PER, TRUE, pinfo);
/* Length should be in the 3:d octet */
offset = offset + 3;
bit_offset = offset<<3;
/* Get the length of the sabp packet. offset in bits */
dissect_per_length_determinant(tvb, bit_offset, &asn1_ctx, NULL, -1,
&type_length);
/*
* Return the length of the PDU
* which is 3 + the length of the length, we only care about length up
to 16K
* ("n" less than 128) a single octet containing "n" with bit 8 set to
zero;
* ("n" less than 16K) two octets containing "n" with bit 8 of the
first octet set to 1 and bit 7 set to zero;
*/
if (type_length < 128)
return type_length+4;
return type_length+5;
}
/* Note a little bit of a hack assumes length max takes two bytes and that the
length starts at byte 4 */
static int
dissect_sabp_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void*
data)
{
tcp_dissect_pdus(tvb, pinfo, tree, gbl_sabp_desegment, 5,
get_sabp_pdu_len, dissect_sabp, data);
return tvb_length(tvb);
}
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Vishnu Bhatt
Sent: den 10 februari 2014 08:40
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] TCP Reassembly in wireshark
Thanks for the information. So you mean to say that the upper layer tells TCP
about its size. Could you please tell me how SABP does this?
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Guy Harris
Sent: Friday, February 07, 2014 3:54 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] TCP Reassembly in wireshark
On Feb 7, 2014, at 12:06 AM, Vishnu Bhatt <[email protected]> wrote:
> How does wireshark know when to reassemble the TCP segments? How TCP gets to
> know in wireshark that whether to send the payload to the upper layer or to
> reassemble it in some other frame?
It gets told by the dissector for the upper layer.
> Is there any header field?
Not in TCP. The service offered by TCP is a byte stream, with no packet
boundaries visible; a TCP implementation can divide up the bytes handed to it
by the upper-layer protocol in any way that it chooses.
This means that if the protocol running atop TCP has message boundaries, that
protocol must somehow arrange to determine when a message begins or ends.
Many protocols do this by putting a message length field into the message
header; for example, that's how DNS-over-TCP, ONC RPC-over-TCP, and
SMB-over-TCP work. Wireshark has a routine tcp_dissect_pdus(), which a
dissector for a protocol running on top of TCP and using a message length field
can use.
For HTTP, the header for a request or response continues up to a blank line,
and the entity-body for a request or response might be indicated by the
connection on which it's being sent closing, by the length of the entity-body
being specified in the header with a Content-Length: header field, or in
various other fashions.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe