A range filter can retain an unexpected packet when separate comparisons match different occurrences of the same field.

Use an authorised practice capture with identifiable source and destination port pairs. Prepare a small expected-results table before entering a filter. The purpose is to verify selection, not to decide whether an unfamiliar port is suspicious.

Test the same-occurrence requirement

Wireshark’s tcp.port includes source and destination occurrences. With tcp.port >= 5000 && tcp.port <= 5005, one occurrence can satisfy the lower bound while another satisfies the upper. Membership expresses the intended range in one test:

tcp.port in {5000..5005}

For source/destination pairs (60000,80), (60000,5002) and (5006,5007), only the second has a port in that range. The two-comparison expression can also admit the first: 60000 meets its lower comparison and 80 meets its upper comparison. Neither port is actually within the requested interval.

Apply both expressions to the same sample. Membership should retain only the second pair. Compare identities and keep the first pair as the counterexample explaining the change.

Preserve the question being asked

Write whether the investigation concerns either endpoint or a particular direction. If the question changes, revise its expected-results table before adapting the expression. A filter that is correct for one question should not be copied into another report without that check.

For a larger capture, inspect several known matching and non-matching records as well as the counterexample. This catches a result that happens to have a plausible total while retaining the wrong identities.

The final handover should contain the intended range, the accepted expression and the three-pair witness. That gives the next reader a concrete reason for using membership rather than an unexplained syntactic preference.

Sources: Wireshark official guide.