I have a capture file on which it drops core.
The problem is that in the "add all data fragments" part of
"fragment_add()", "fd_i->len" is less than 'dfpos - fd_i->offset" for
one TCP segment, so the argument to "memcpy()" is negative.
Yes, forgot to check fd_i->len+fd_i->offset > dfpos. It was going to fail in
a complete overlap. I'm attaching a diff file w/ the "if" in it.
The list of fragments (TCP segments) is:
(gdb) print fd_head
$1 = (fragment_data *) 0x83af9d4
(gdb) print *$1
$2 = {next = 0x83af9f0, frame = 4022250974, offset = 0, len = 0,
datalen = 32916, flags = 2, data = 0x8446000}
(That's the item for the reassembled packet, hence the bogus frame
number.)
(gdb) print *$2.next
$3 = {next = 0x83afa7c, frame = 1351, offset = 0, len = 1460,
datalen = 4022250974, flags = 0, data = 0x0}
(gdb) print *$3.next
$4 = {next = 0x83afab4, frame = 1359, offset = 0, len = 664,
datalen = 3203391149, flags = 2, data = 0x83a5c00}
The offending "fd_i" is 0x83afa7c, and it points to
$4 = {next = 0x83afab4, frame = 1359, offset = 0, len = 664,
datalen = 3203391149, flags = 2, data = 0x83a5c00}
"dfpos" is 1460, and "dfpos - fd_i->offset" is also 1460.
Yes, frame 1359(offset=0, len=664) was a complete overlap of frame
1351(offset=0, len=1460) and so memcpy size was neg
It may be that the reassembly code isn't dealing with retransmissions,
out-of-order transmissions, and overlaps as well as it should.
*fragment_add() should handle retrans, overlaps and out-of-order.
*The problem is w/ desegment_tcp(), right now it's not ready for handling
out-of-order segments.
Thanks,
Ricardo.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
Attachment:
diff.reassemble.c.gz
Description: Binary data