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