Ensure that tcpdump is stopped before copying pcap file to GCS in the event of a SIGTERM is received

[thomasmburke]

Users have encountered The capture file appears to have been cut short in the middle of a packet when trying to look at pcaps we flushed at the time a SIGTERM is received in Wireshark

tcpdump writes the pcap file in blocks of a certain size. This means that during the capturing, the file ends in the middle of a packet. This is because we copy the file while tcpdump is still capturing, the last packet in the file will not be completely written yet, hence the error message in Wireshark.

If we stop tcpdump before copying the file, the remaining buffer will be written to disk and all packets will be complete.

The solution in #16 flushes bytes upon receiving SIGTERM, but currently fails to stop tcpdump before doing so. We should ensure tcpdumpw stops the tcpdump capture before we attempt to flush bytes to GCS in pcapfsn

[gchux]

fixing with the following changes: d6d0404

important parts:

• in tcpdumpw wait for currently executing task before creating a signal file TCPDUMPW_EXITED:
  • waitDone https://github.com/gchux/cloud-run-tcpdump/blob/v1.0.60-RC6/tcpdumpw/main.go#L387-L401
    • https://github.com/gchux/cloud-run-tcpdump/blob/v1.0.60-RC6/tcpdumpw/main.go#L459
    • https://github.com/gchux/cloud-run-tcpdump/blob/v1.0.60-RC6/tcpdumpw/main.go#L542
• in pcap_fsn wait for the signal file created by tcpdumpw before flushing PCAP files:
  • https://github.com/gchux/cloud-run-tcpdump/blob/v1.0.60-RC6/pcap-fsnotify/main.go#L328
  • https://github.com/gchux/cloud-run-tcpdump/blob/v1.0.60-RC6/pcap-fsnotify/main.go#L396-L412
  • STOP waiting after 3s from receiving SIGTERM if the signal file has not been detected: https://github.com/gchux/cloud-run-tcpdump/blob/v1.0.60-RC6/pcap-fsnotify/main.go#L485-L489

---

IMPORTANT NOTES:

• tcpdump will be immediately stopped ( this is what we want for wireshark )
• jsondump will be immediately stopped but it may be delayed if there are too many packets queued/pending to be translated (which is specially noticeable with low CPU allocations), so it is VERY IMPORTANT to define well scoped BPF filters to capture only the required traffic and nothing else; i/e: tcp or udp or tcp are, in general, SLOW filters.

---

• here's a sample using the BPF filter tcp or udp where packets captured from ipvlan-eth0 were not done being translated after 3s, and so pcap_fsn flushed without waiting for the signal from tcpdumpw:

• and here's a sample using BPF filter tcp port 8080 where all engines ( tcpdump and gopacket/jsondump ) were stopped immediately:

[gchux]

available at ghcr.io/gchux/cloud-run-tcpdump:v1.0.60-RC6

[gchux]

fixed with: https://github.com/gchux/cloud-run-tcpdump/releases/tag/v1.0.60