Inconsistent filter results

edit

If you compare the frames that are filtered in the first case but not the second, do they appear as dissected as TCP-only frames, with payload that is indicated as a TCP segment being reassembled and dissected in another frame?

I'm not sure this is the issue, I just tried with a pcap file with one http request/response where the response is reassembled from two TCP segments and the issue does not occur. I think there must be a different mechanism causing this issue, but a pcap of the issue would be needed to investigate.

Another possibility that can cause different dissection in two passes is something like another heuristic dissector claiming the packet before the SIP dissector on the second pass but not the first pass, because that second dissector is normally later in the list of heuristic dissectors, but matched a later packet and then got moved up the list of heuristic dissectors to try. I saw some issues related to that recently (not on 4.4) with the HiPerConTracer heuristic dissector being too eager and messing up QUIC

Interesting case, must be something like that. @Mick B Are you able to share (part) of the file or would that expose sensitive data?

Hi @SYN-bit, at the moment I cannot share any of the capture files as they do contain sensitive data. I will attempt to find a way to anonymise an example trace.

@johnthacker, it is very difficult to see which frames are additional. The capture files that I am comparing are large captures, e.g. the smallest varies between 11065 and 11946 packets matching the "sip" filter. I know that I should be able to trim a small part where the issue occurs, but there's still sensitive data present. So far I can confirm that, at least in one case, the extra captured packet is a TCP segment with SIP content, however, there are many instances of that found in both cases of filtering so I don't know why that one is different to other similar ones.