Capture probes

A capture probe records traffic on a device and sends capture evidence and telemetry to PacketSafari. Probe enrollment is separate from using the operator CLI to upload a local PCAP or start an investigation.

Add a probe with the guided installer

1. Open Capture → Capture probes.
2. Select Add probe.
3. Enter the PacketSafari address that the target device can reach. Production and on-prem installations require HTTPS.
4. Choose Linux, macOS, or Windows; select ARM64 or x86-64; then choose a run mode.
5. Select Generate installer command and copy it.
6. Run the command in a terminal on the target device. Windows requires an Administrator PowerShell.
7. Keep the target terminal running. Return to PacketSafari and approve the sensor when Approval required appears.
8. Open the sensor and confirm its enrollment, connection, and last-seen status.

The generated command expires after 15 minutes. It downloads and verifies its artifacts, creates the private device key on the target, enrolls the sensor, and waits for approval when required. Generate a new command if it expires.

Choose Foreground for a temporary test. Ctrl+C stops that sensor and it will not start after reboot. Choose Background service to install the platform's native startup job and keep the sensor running after reboot.

If the one-line command cannot be used, open Manual downloads for the binary, bootstrap, provider catalog, and full shell or PowerShell installer. Keep these files together and verify them as directed by the generated installer.

Understand probe credentials

Open the Probe credentials tab to create named probe accounts and manage their credentials.

Select Add probe account to create an account. Use Create probe key or Issue enrollment token only when you need manual credential handling. Each secret is displayed once; copy it immediately and store it as a device secret.

For normal setup, prefer Add probe. It creates the installation command and guides approval, so you do not need to assemble enrollment flags yourself.

Probe credentials cannot upload an operator's PCAP or submit an AI investigation. For those workflows, create a personal or team API key.

Approve and monitor the sensor

New sensors may authenticate successfully but remain blocked until an operator approves them. In the Probes tab:

• select Approve for a pending sensor;
• check Enrollment, Connection, and Last seen;
• select Capture to work with live capture controls;
• select Settings to inspect or change device administration.

If the target reports that it is waiting for approval, leave it running while you approve it in the UI. If it never appears, verify that the target can reach the exact PacketSafari address used to generate the command and that HTTPS trust is valid.

Update or reconnect a probe

Open the probe's Settings tab to inspect software state, connection health, and device diagnostics. Use the update action shown there when a newer approved probe build is available. A completed server update acknowledgement does not by itself prove the new process is healthy; confirm the displayed version, restart/health state, and fresh telemetry.

If a manually started probe reports missing persisted device credential or one-time enrollment bootstrap, it has neither a saved enrolled identity nor a usable enrollment token. Return to Add probe and run a newly generated installer command, or issue an enrollment token from Probe credentials for your manual workflow.

Rotate, revoke, or remove access

Open Probe credentials, select the probe account, and review its issued probe keys and enrollment tokens. Delete a credential to prevent further use. Create the replacement before deleting a probe key that an active sensor still needs, then update or reenroll that sensor through the guided installer.

Deleting a device record removes that probe and its related capture records from PacketSafari and cannot be undone. Deleting a captured session also removes its linked PacketSafari PCAPs and analysis, but does not remove copies retained on the sensor. These are destructive data actions; review the confirmation text before proceeding.

PacketSafari does not present a remote OS uninstall action in this screen. Remove the installed startup job and files on the target with the platform-specific installer or service controls used for that deployment. Deleting the server-side device record alone does not uninstall software from the target.

CLI jobs do not require a probe

You can investigate a PCAP already on your workstation without enrolling a sensor:

packetsafari investigate "$HOME/Desktop/incident/capture.pcap" --goal troubleshoot --tui

That command uses an operator API key and uploads the selected file. See the CLI overview for complete workflows.

Inspect browser traffic

Open a captured PCAP from the probe's captured sessions, then choose HTTP. Browser captures made with an approved application plan show the application name and capture method. Proxy captures can contain both proxy legs, so the same request may appear as separate exchanges on different connections.

Browser, curl and wget captures now default to preparing HTTP directly after upload, without waiting for full Triage. For a web service, container or interface, choose Options → After capture → HTTP only. Choose Full Triage when you want the broader analysis. HTTP-only captures open directly in the HTTP workspace; preparing HTTP does not run security checks or complete an Agent investigation. You can run full Triage later.

The HTTP workspace provides a compact request table with sorting, column controls, search, content-type filters, and packet timing. Select an exchange to inspect Headers, Payload, Preview, Response, Cookies, Timing, or Evidence. View packets opens the corresponding packet evidence.

New Core runs retain a generation-scoped HTTP index. Search, content-type filters, sorting, and counts run server-side; request and connection lists show 100 rows per page. The overview covers matching indexed requests across all pages using at most 128 time or packet-frame bins. Per-page timing uses exact packet anchors. The index retains up to 50,000 exchanges from at most 200,000 source observations; source limits remain visible as partial coverage. These are exchange limits, not a guarantee of 50,000 distinct connections.

Older captures keep their bounded preview until Core is rerun. Paging does not recover evidence discarded by an earlier analysis. Request bodies are not stored in the browsing index.

Request and response details start at selected packet anchors and inspect bounded later-packet or reassembly evidence. Body previews are bounded to 64 KiB; larger or incomplete bodies may still require packet or stream inspection. HTML and scripts are shown as text, never executed. A 304 Not Modified response has no message body: the browser reuses its cached resource. Timing is derived from packet observations, not the browser's JavaScript initiator, scheduling, or cache timeline.

Capture provenance is saved as PacketSafari metadata. The application and method come from the approved plan; decryption outcomes and embedded-secret availability are explicitly sensor-reported. This metadata does not assert that every connection was decrypted and does not modify the downloaded PCAP.

Drag across the HTTP overview to filter the request list while moving the selection. Drag either handle to resize it, or choose Reset interval to show all matching requests. The axis uses time when complete timestamps are indexed, otherwise it is labelled by packet frame. Right-click a column header to sort, show or hide columns, or reset the table. These filters operate on the retained capture, not on a live browser network stream.

Use Waterfall for individual request lanes and Activity for capture-wide request volume. The legend distinguishes successful responses, redirects, errors, and unpaired requests. Timing measures the request to response headers, not the browser’s full download lifecycle.

Selecting an exchange also checks bounded later-packet and reassembly evidence for its body. Preview formats JSON where possible; Response preserves decoded text. Binary data is shown as hex. Missing, partial, or truncated bodies remain labelled; captured scripts are never executed.

Live capture workspace

Starting capture opens a dedicated full-screen workspace. Stop and save asks the sensor to stop recording and then finish delivery; it does not discard the packets already saved. Saving and upload can continue after recording stops. Open packets opens the imported PCAP. After completion, Capture again returns to setup.

Pause view, search, and application chips filter only the live display. On macOS, Apply to recording sends the selected process IDs and BPF expression to the sensor. A change takes effect only after the sensor acknowledges its revision. It narrows the original capture selection; it cannot recover earlier excluded traffic or remove earlier saved packets. Clearing the additional filter restores the original selection. Unattributed traffic cannot be selected as a recording PID. Unsupported sensors and invalid filters reject the change.

The capture URL identifies the exact session. Reloading it reconnects to that session and restores its status, recent preview, and Stop control. A browser reload does not restart recording. Reconnect restores the last sensor-acknowledged recording filter and revision; unacknowledged changes remain unconfirmed. A sensor restart ends active recording; it does not seamlessly resume the same capture.

Native macOS and Linux capture sample at most 40 headers per second before preview decoding. The browser displays up to 120 recent rows, retains at most 500, and the server retains at most 2,000 preview rows per probe. Slow preview delivery may skip rows. Preview sampling does not discard packets from the PCAP; capture limits and capture-engine drops still apply and remain part of the capture result.

On macOS PKTAP captures, Process · PID shows kernel-supplied attribution when available. Unattributed packets remain explicit. Saved flow metadata preserves process attribution separately from portable packet bytes.

Segments and decryption

With segmented storage enabled, the macOS probe closes independently readable PCAPNG sections at the configured size or after approximately two seconds when the next packet arrives. Closed sections enter the existing durable upload spool while recording continues. Slow uploads leave sections pending rather than blocking the recording loop. The single upload worker retries pending sections during capture and drains queue overflow when recording stops. Failures remain in the durable spool for subsequent retry and startup recovery. The segment drain has a 30-second finalization budget; undelivered segments remain retained for recovery. The final assembled capture is imported for full inspection.

Recording stops at its configured storage budget rather than silently overwriting earlier packets. Disk use also includes temporary assembly and retained upload copies. These bounds and sampled preview keep browser work independent of traffic volume; they are not a qualification for 100-Gbit/s lossless capture.

For authorized embedded-key captures, closed sections receive the complete session-key records available at sealing time. The running application's key log is preserved. A section can still lack a handshake or a key produced later. Proxy socket observations and final decryption checks are completed when the capture finishes. Split-custody keys are not embedded automatically.

The live table is a header preview, not a live decrypted HTTP view. Use the final imported capture to inspect requests and responses and verify actual decryption. Key availability alone does not prove that all encrypted traffic is decryptable. Other capture backends may save packets without providing a live preview; live recording-scope changes are currently macOS-only.