[show][generate_dump] Add optional tcpdump packet capture to "show techsupport"

[vaishnav-nexthop]

What I did

Added an optional, opt-in tcpdump packet capture to show techsupport.

show techsupport collects a rich snapshot of device state, but it is a
point-in-time view with no visibility into the traffic that was on the wire
while the dump was taken. For a large class of troubleshooting, packet-level
evidence is exactly what is needed, and today it has to be gathered out of band
with a separate tcpdump invocation and then manually correlated with the
techsupport archive.

This makes packet capture a first-class, optional part of techsupport: when
enabled, traffic is captured for the duration of the collection and the
resulting pcap is bundled into the same techsupport tarball, so a single command
produces both the device state and a matching capture taken over the same
window. An optional BPF filter lets the operator scope the capture to just the
traffic of interest (e.g. a protocol, port, or host).

The feature is disabled by default — existing show techsupport /
generate_dump behavior is unchanged unless --with-tcpdump is passed.

New options:

Option	Range / default	Notes
--with-tcpdump	off by default	Enables capture
--tcpdump-duration <seconds>	1–300, default 60	Capture window
--tcpdump-packet-limit <count>	1–100000, default 10000	Caps pcap size
--tcpdump-filter <bpf>	none	BPF expression, e.g. udp port 3784

The tuning options require --with-tcpdump; supplying them without it fails fast
with a clear error rather than being silently ignored.

How I did it

show/main.py

• Adds the four Click options and forwards them to generate_dump as
  -T/-P/-L/-F. --tcpdump-duration and --tcpdump-packet-limit use
  click.IntRange, so out-of-range values are rejected at the CLI; documented
  defaults are applied when --with-tcpdump is given without explicit values.

scripts/generate_dump

• start_tcpdump_capture() launches tcpdump -i any in the background at the
  start of collection so the capture overlaps data gathering. The capture is
  self-bounding via tcpdump's native -G/-W (wall-clock duration) and -c
  (packet count), whichever is reached first; -s 0 keeps full-length packets.
  tcpdump availability is checked first and the capture is skipped gracefully
  (without failing techsupport) if it is absent.
• wait_tcpdump_capture() waits for the capture to finish, and is invoked
  before save_to_tar. save_to_tar archives the dump directory by file
  content, so awaiting the capture first guarantees the completed pcap is on disk
  and included in the archive rather than a truncated snapshot. In the common
  case (data collection outlasts the capture) the wait returns immediately.
• handle_exit() kills any still-running capture so an interrupt or timeout
  cannot leave an orphan tcpdump process behind.
• getopts gains -T/-P/-L/-F, with validation that -P/-L/-F
  require -T.

The pcap is written as tcpdump_<duration>s_<timestamp>.pcap inside the dump
directory and therefore appears in the final techsupport archive.

How to verify it

Unit tests (tests/techsupport_test.py):

• CLI-to-generate_dump option mapping, for both defaults and explicit values.
• The tuning options require --with-tcpdump (usage error otherwise).
• IntRange bounds are enforced for duration and packet limit.
• Regression test asserting wait_tcpdump_capture runs before save_to_tar.

Manual:

# Capture during a techsupport run, scoped to BFD traffic
show techsupport --with-tcpdump --tcpdump-duration 30 --tcpdump-filter 'udp port 3784'

# The resulting /var/dump/sonic_dump_*.tar.gz contains:
#   .../dump/tcpdump_30s_<timestamp>.pcap
tar tzf /var/dump/sonic_dump_*.tar.gz | grep tcpdump_

Error path:

# Tuning option without --with-tcpdump is rejected
show techsupport --tcpdump-duration 30
# -> Error: --tcpdump-duration requires --with-tcpdump to be specified

New command output (if the output of a command-line utility has changed)

$ show techsupport --help
Usage: show techsupport [OPTIONS]

  Gather information for troubleshooting

Options:
  ...
  --with-tcpdump                  Capture traffic with tcpdump during
                                  techsupport
  --tcpdump-duration INTEGER RANGE
                                  Duration in seconds for tcpdump capture
                                  (default: 60, range: 1-300). Requires
                                  --with-tcpdump  [1<=x<=300]
  --tcpdump-packet-limit INTEGER RANGE
                                  Maximum number of packets to capture
                                  (default: 10000, range: 1-100000). Requires
                                  --with-tcpdump  [1<=x<=100000]
  --tcpdump-filter TEXT           BPF filter expression for tcpdump (e.g.,
                                  'port 179', 'udp port 3784'). Requires
                                  --with-tcpdump
  --help                          Show this message and exit.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: vaishnav-nexthop / name: vaishnav-nexthop (86015ee)

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

Hi, there are workflow run(s) waiting for approval, you may be first-time contributor. I will notify maintainers to help approve once PR is approved. Thanks!

_{---Powered by SONiC BuildBot}