Skip to content

SRT values are wrong if you use time shift

Preben Guldbergrequested to merge
prebeng/wireshark:time-shift-with-srt into master

SRT values are incorrect when applying a time shift.

This is a follow up to Issue #18999 (closed).

The isue affects fields that calculate a time difference for service response time (SRT) or similar deltas, as well as the GUI SRT tables.

The general problem is how the often used idiom relies on pinfo->abs_ts not changing over time - but it does when a time shift is applied. With this calls to nstime_delta() using pinfo->abs_ts does not give the desired result.

I have confirmed this issue in several dissectors and set up a frame work to address it. Please see the first commit for the details. I have deliberately (for now at least) included multiple commits to ease review:

  • First commit setup up the frame work and fixes a few dissectors.
  • Second commit fixes the simplest application of the common idiom.
  • Further commits addresses more complicated uses.
  • Regenerate ASN1 dissectors
  • Update documentation.

The taps in ui/cli have not been updated (diameter and rpc) as time shift is not possible with tshark.

Calls to e.g add_conversation_table_data() that reference pinfo->abs_ts have been left as is. The table handles the delta well, and I feel it is desirable to include the time shift in start times.

For the 50+ dissectors I have fixed, I have includes a summary including which dissector fields have been confirmed fixed and status of SRT tables. In almost all cases, I could confirm using a trace, which I referenced as well.

The following dissectors I suspect to be affected, but I could not confirm the validity of attempts to fix them:

  • bpv7: Based on Issue #18479 (closed), dtn_tcpclv4_bpv7_transfer.pcapng, the bpv7.bundle.seen_time_diff field is affected, but I cannot tell if the fix influences bpv7.primary.lifetime_exp or how.
  • btavdtp: I am missing a trace to confirm.
  • sbc: No trace to confirm. Also interactis with btavdtp.
  • ipmi: No trace to confirm.
  • signal-pdu: Works OK, but agg_data->sum_time_value_products might be wrong.

The following dissectors I do not understand well enough to fix without having a reference trace that:

  • ptp: More complicated than I can confirm (Samples/ptpv2.pcap).
  • sctp: Need a trace exposing relevant fields.

The following dissectors do not seem affected in their use of nstime_delta():

  • bthci_cmd: Based on Bluetooth1.cap from Samples.
  • bthci_evt: Based on Bluetooth1.cap from Samples.
  • esl: Based on Issue #3677 (closed), ethercat_with_esl_trailing_header.pcap
  • gsm_osmux: Based on Issue #18337 (closed), osmux_call_bts_bsc_filtered.pcapng
  • netflow: Based on https://weberblog.net/the-ultimate-pcap/ (v20221220), tested with printf() for value comparison.
  • tcpcl: Based on (Issue #18479 (closed), dtn_tcpclv4_bpv7_transfer.pcapng
  • transum: Based on smbtorture.cap.gz
  • umts_rlc: Based on UMTS_FP_MAC_RLC_RRC_NBAP.pcap from Samples (filter on rlc.duplicate_of - not susceptible to time shift and ignored frames). The use of nstime_delta() is for duplicate detection that seems based on a single pass on each reload (ignore a packet). This turns out OK.

Merge request reports