http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1453
sake@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Out Of Order TCP-Segments |GIOP reassembly fails when
|are recognized as Previous |first packet of a PDU is
|Segment lost |received Out-of-Order
------- Comment #3 from sake@xxxxxxxxxx 2007-11-03 12:28 GMT -------
[I received a private mail containing a trace showing the problem, here is my
reply after some analysis of the tcp-dissector]
Hi Wolfgang,
> unfortunately I cannot attach a cap file to bugzilla, but I'll attach a
> cap file showing the behaviour as zip file (password is 'wireshark') to
> this mail.
>
> In the cap-file you'll find frames 153-157
> with 'previous segment lost in frame 155, DUP ACK in frame 156 but
> processed correctly in frame 157.
>
> Frames 1563 to 1565 have a similar scheme:
> 1563 segment lost, 1565 reassembled segment but afterwards no GIOP
> request is decoded anymore only the responses.
>
> The only difference I can see is:
>
> #153 is first in chain
> #155 is last in chain (segment lost or out of order)
> #157 is middle in chain
> Which is processed properly.
>
> But
> #1563 last in chain (segment lost or out of order)
> #1564 DUP ACK (#1563)
> #1565 first in chain
> is not properly decoded and no follow up request is decoded anymore,
> only responses.
> The proper decode seems to depend on whether there was a valid frame
> (sequence no) to start with or not.
> I looked into the code of packet-tcp.c but did not find the code section
> to change.
Indeed the proper dissection is dependant on the data it has been given.
When frame #1563 is handed to the giop-dissector, it does not contain
the GIOP header. The giop-dissector does not check if it received a
header, it just assumes it did. Therefore it calculates the pdu-length
from the non-header (bytes e5 fe cc 7d). This results in trying to
collect this much data by the desegmentation routines.
I looked into a way to solve this generally in the tcp-dissector, but
unfortunately I don't see a good way to do that. This is mainly because
the tcp-dissector is not capable of determining whether the lost frame
was the beginning of a multiple-segment-pdu or a full pdu on it's own.
This information is needed to determine how to handle the out-of-order
packets.
Could you change the giop-dissector so that it will check whether it
recieved a valid GIOP header *before* calculating the pdu-length and
asking for that much data?
> I will also append a modified packet-giop.c which is able to decode
> compressed corba requests/responses. You may find it useful reading the
> attached dump. Please let me know, if you think this modified version is
> worth while to be incorporated into the official source tree of
> wireshark.
A quick glance shows that it has been developed against an older SVN
version, but apart from that I think it looks OK (but I'm no GIOP
expert). Could you make a diff against the current SVN (hopefully
including the above mentioned enhancement) and attach it to this
bug?
> Thanks for looking into the problem
You're welcome :-) Cheers,
Sake
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
