Re: TCP reassembly and Return value of a new-style dissector

[Peter Wu <peter () lekensteyn nl>]

On Wednesday 10 December 2014 16:56:30 Anders Broman wrote:
> > > I think the ultimate solution would be for the TCP dissector to call 
> > > the SIP dissector again with the next incomplete PDU after receiving 
> > > the number of bytes "accepted" by the SIP dissector e.g using the 
> > > "new-style dissector interface.
> > > also see http://seclists.org/wireshark/2014/Jun/289
>
> > It would indeed be nice if the dissector core could be improved to
> > handle this situation. As I mentioned before, the HTTP dissector has
> > no problems with this because it tries to dissect all data until more
> > data is >needed.
>
> > This is from dissect_sip:
> >
> >    remaining_length = tvb_reported_length(tvb);
> >    len = dissect_sip_common(tvb, 0, remaining_length, pinfo, tree, FALSE, FALSE);
> >    if (len < 0)
> >        return 0;   /* not SIP */
> >    else
> >        return len;
>
> > dissect_http instead always returns tvb_captured_length ("all data in
> > the PDU is part of the HTTP protocol") while returning 0 means "I
> > know for sure that this is not SIP".
> >
> > dissect_sip_common returns -1 meaning "need more data", but then
> > dissect_sip return 0 meaning "no, not SIP, try a different
> > dissector!".
>
> I'm not sure the TCP dissector cares about the return value I think it
> only looks at pinfo. 

The TCP dissector indeed ignores the return value of the new-style
dissector.

> I think part of my problem is that the SIP dissector mixes the
> heuristics and 'common' functionality. I'm actually looking at SIP
> over TCP currently, e.g dissect_sip_tcp(). I have also run into a
> problem where reassembly fails When there is duplicated packets but
> works if the dupes are marked as ignored... ( dupes due to the way
> mirroring is set up).

There are known issues with dissection when duplicate or out-of-order
packets exist (see bugzilla).
-- 
Kind regards,
Peter
https://lekensteyn.nl

___________________________________________________________________________
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