Follow up on my own message, I now know what happened!
There were retransmissions, don't know why, but they were there...
Matthijs Melchior wrote:
Hi,
My dissector has a problem with desegmentation. I have been
using captures created by text2pcap, and everything worked OK.
That were capture files that started on a PDU boundary and have
only one direction of dataflow in it. Now I have a capture from
a real tcp session, which does not start at a PDU boundary and
contains ack packets as well.
This capture causes the desegmentation to behave very strange.
There were retransmissions in this capture, I did not expect they
would be and I did not recognize it at first. I now have
"Preferences:TCP:Analyse TCP sequence numbers" on, and ethereal
tells me about it....
The very first packet appears to be desegmented and built from
Frame 15 payload 0-28 and Frame 17 payload 29-1499
It has 105 bytes TCP segment data at the end.
Yes, this is correct, Frame 17 was a retransmission of frame 1.
somehow, etereal decides to get earlier data from a later,
apparantly retransmitted, packet....
The capture has 14 packets with data, 13 are 1514 in length and the
last is 517 bytes. Frames 15 and 17 are data packets 9 and 10.
The next data packet, frame 3, is a continuation of packet 1:
Frame 17 payload 0-104 and Frame 19 payload 105-1564 and 3 bytes
TCP segment data at the end.
same as for the first packet.
The third data packet, frame 5, is not reassembled, and has 7 bytes
TCP segment data at the end.
The fourth data packet, frame 7, seems to be correct, it is built
from frame 5 payload 0-6 and frame 7 payload 7-1466 with 3 bytes
TCP segment data at the end.
These were packets marked as retransmission because their seq-number
is lower than that of the first packet...
My dissector handles desegmentation like this:
[non essential code removed...]
void dissect_asn1(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
// set COL_PROTOCOL and clear COL_INFO
// reset asn1 decoder and get info about first entity
// use this to set COL_INFO
if (tree) {
TRY {
while(tvb_length_remaining(tvb, offset) > 0) {
// reset asn1 decoder
// dissect first entity
ti = proto_tree_add_protocol_format(tree, .... );
asn1_tree = proto_item_add_subtree(ti, ett_asn1);
if (!def) len++; /* make sure we get an exception if we run
off the end! */
offset = decode_asn1_sequence(tvb, offset, len, asn1_tree, 1);
proto_item_set_len(ti, offset - boffset);
}
CATCH(BoundsError) {
RETHROW;
}
CATCH(ReportedBoundsError) {
if (ti)
proto_item_append_text(ti, " (incomplete)");
if (asn1_desegment) {
pinfo->desegment_offset = boffset;
pinfo->desegment_len = 1;
);
} else {
RETHROW;
}
return;
This is wirng!!!! No return is allowed in a CATCH block!!
}
ENDTRY;
}
Sometimes when I was working with this capture, ethereal would crach
in the exeption handling routines. ddd tels me it was in except.c:246
There, in routine except_pop(), variable top seems to have a random value.
Yes, ethereal does not crach anymore now that I have removed the return
from the CATCH blok!
--
Regards.
---------------------------------------------------------------- -o)
Matthijs Melchior Maarssen /\\
mmelchior@xxxxxxxxx Netherlands _\_v
---------------------------------------------------------------- ----
