NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: Tools → Packet Sniffer → set *Interface* and filters on the Filter tab → Apply → Start → watch the Packets tab.
2. CLI quick view: /tool sniffer quick interface=ether1 ip-address=8.8.8.8
3. To a file: /tool sniffer set file-name=cap.pcap filter-interface=ether1 then /tool sniffer start, later /tool sniffer stop and fetch cap.pcap from Files.
4. Live to Wireshark: set *Streaming Server* to your PC's IP with *Filter Stream* enabled, then capture TZSP on UDP/37008 in Wireshark.

Gotchas & notes

• /tool sniffer quick prints to your terminal and saves nothing — great for a fast yes/no, useless for evidence. Use the file or streaming mode when you need to keep it.
• The capture file is written to RAM on most models. A busy interface fills memory-limit fast and the capture silently stops; set file-limit/memory-limit deliberately.
• Filters on the Filter tab are AND-ed, and leaving a stale filter set is the usual reason 'the sniffer shows nothing'. Check /tool sniffer print before trusting an empty result.
• The TZSP streaming mode is the hidden gem here — no other vendor in this list streams live into Wireshark this easily.

Steps

1. GUI: Network → Diagnostics → Packet Capture → Create New → pick interface, packet count, and optional filter → start → Download the .pcap.
2. CLI: diagnose sniffer packet any 'host 8.8.8.8 and icmp' 4 0 a
3. Stop with Ctrl+C. Narrow to one interface by replacing any with e.g. port1.

Changed across versions

• 6.x – 7.0.xGUI path is Network → Packet Capture — there is no *Diagnostics* submenu yet.
• 7.2+Moved under Network → Diagnostics, as a *Packet Capture* tab alongside the other diagnostic tools. Path is unchanged through 7.6.

Gotchas & notes

• Decode the CLI arguments, because nobody remembers them: any = interface, '...' = BPF filter, 4 = verbosity, 0 = packet count (0 means unlimited), a = absolute timestamps. Verbosity 4 prints headers plus the interface name, which is what you almost always want.
• Hardware-offloaded sessions do not appear in the sniffer at all. On NP6/NP7 models an established session gets pushed to the ASIC and goes invisible. Set set auto-asic-offload disable on the relevant firewall policy while troubleshooting, then put it back.
• The GUI capture is limited to physical/VLAN interfaces and a bounded packet count — the CLI can capture on any, which the GUI cannot.
• To turn CLI output into a pcap, capture at verbosity 3 or 6 and pipe the log through Fortinet's fgt2eth.pl converter. Verbosity 4 output cannot be converted.
• Set your terminal to log to a file *before* starting — the output is not stored on the FortiGate, so scrolled-off packets are gone.

Steps

1. No packet capture in the UniFi Network UI.
2. Enable device SSH (Settings → System → Advanced → Device SSH Authentication), then SSH to the gateway.
3. On a UDM/UDM-Pro/UXG: tcpdump -i eth8 -n host 8.8.8.8 (substitute the real interface — check with ip -br addr).
4. Write a file you can pull off with scp: tcpdump -i eth8 -n -w /tmp/cap.pcap

Gotchas & notes

• Interface names on UniFi gateways are not the labels shown in the UI. VLANs appear as br0.20-style sub-interfaces and the WAN varies by model — always run ip -br addr first instead of guessing eth0.
• UniFi APs and switches run a stripped BusyBox; tcpdump may be missing entirely, and there is nowhere persistent to write a capture.
• Anything you install or change on-device can be wiped by the next controller provision or a firmware update. Treat the gateway shell as read-only troubleshooting, not configuration.
• For wireless problems the controller's per-client Insights and the AP's *RF Environment* view are often more useful than a capture, since you cannot capture the air from the AP shell.

Steps

1. Embedded Packet Capture (EPC), four commands: define, attach, start, look.
2. monitor capture CAP interface GigabitEthernet1/0/1 both
3. monitor capture CAP match ipv4 any any
4. monitor capture CAP start … then monitor capture CAP stop
5. View: show monitor capture CAP buffer brief — or export: monitor capture CAP export flash:cap.pcap

Gotchas & notes

• A capture with no match clause attached never captures anything and gives no warning. The match line is the step people skip.
• EPC is not on every platform or license tier; on older IOS you may only have SPAN/RSPAN (monitor session) to mirror traffic to a laptop running Wireshark.
• The buffer is in DRAM and defaults to a few megabytes with linear mode, meaning it stops when full rather than overwriting. Add buffer size 10 circular for long soaks.
• Remember to monitor capture CAP stop and then delete the capture point — a forgotten running capture is a real CPU drain on a busy switch.

Steps

1. GUI: Monitor → Packet Capture → add filters under *Configure Filtering* → define capture stages → toggle *Packet Capture* on → download the files.
2. Define a file per stage: receive, transmit, firewall, drop.
3. CLI equivalent: debug dataplane packet-diag set filter match destination 8.8.8.8, debug dataplane packet-diag set capture stage receive file rx.pcap, debug dataplane packet-diag set capture on

Gotchas & notes

• PAN-OS is the only vendor here with a four-stage capture, and the stages are the whole point: a packet in receive but not transmit with something in drop tells you the firewall discarded it, which no single-point capture can show.
• Turn hardware offload off first (set session offload no in configure mode) or you will only capture the first few packets of each session and wrongly conclude traffic stopped.
• You must set a filter and enable *Filtering*, otherwise you capture everything on a production firewall and hurt performance. Verify with debug dataplane packet-diag show setting.
• The capture keeps running until you explicitly turn it off, and files persist on disk. Always finish with debug dataplane packet-diag set capture off and debug dataplane packet-diag clear all.
• For a quick allow/deny answer, Monitor → Traffic logs or show session all filter ... are faster than a capture.

Steps

1. GUI: Diagnostics → Packet Capture → choose *Interface*, *Address Family*, *Protocol*, host/port filters, and *Level of Detail* → Start → Stop → Download Capture.
2. CLI: shell → tcpdump -i em0 -n -s 0 -w /root/cap.pcap host 8.8.8.8

Gotchas & notes

• The most frictionless capture of the six: real BPF filtering in a web form and a .pcap download with no conversion step.
• *Level of Detail* only affects what the web page prints, not what the downloaded pcap contains — always download the file rather than reading the page.
• Pick the interface carefully: capturing on the parent NIC of a VLAN shows tagged frames, while capturing on the VLAN interface shows them untagged.
• Captures write to the firewall's disk/RAM. On low-storage appliances a long capture on a busy link can fill the filesystem — set a packet count.

Steps

1. Go to Investigate > Tools & Monitors > Packet Monitor (on some firmware builds/models this is under Device > Diagnostics > Packet Monitor) — SonicOS's built-in capture tool, not a raw tcpdump shell.
2. Click Configure and set a Monitor Filter — source/destination IP, port, protocol, and/or interface. Leaving it wide open on a busy appliance fills the capture buffer within seconds.
3. Optionally enable Notification so packets that get dropped are tagged inline with the reason (e.g. which rule/policy dropped them), not just shown as raw frames.
4. Click Start Capture, generate the traffic you care about, then Stop.
5. Use Export to download the capture as a .pcap for Wireshark, or read the decoded packet grid directly in the GUI.

Changed across versions

• 7.0Packet Monitor moved from System > Packet Monitor (6.5) into the Investigate tab / Device > Diagnostics area in the 7.0 GUI reorganization.

Gotchas & notes

• Packet Monitor is genuinely one of SonicOS's stronger diagnostics — closer to PAN-OS/pfSense's full GUI capture with pcap export than to FortiGate's CLI-only text dump, and it needs no SSH access.
• There is no CLI packet-capture command on SonicOS — capture is a GUI/Investigate-tab-only feature.
• The capture buffer is small and RAM-resident. On a loaded interface without a tight filter it wraps or fills almost immediately, so set the filter before clicking Start, not after you've already missed the traffic.
• 'Monitor' mode only sees traffic transiting the firewall. To see packets to/from the SonicWall's own management IP (e.g. debugging GUI/SSH reachability itself) you need 'Intercept' mode enabled in the filter — easy to miss and a common source of 'the capture shows nothing' confusion.

Steps

1. Insight-managed routers and Orbi Pro APs: not supported, GUI or CLI — there is no capture capability of any kind on these.
2. Switches under an Insight Premium/Pro subscription: Insight portal > device > Utilities (or Diagnostics) > Packet Capture — pick the port(s), set duration/filter, run. Insight uploads the resulting .pcap for download once the capture completes.
3. Switches on the free Insight tier or fully local (unclaimed) switches: the packet-capture menu option is unavailable — the fallback is configuring port mirroring (Switching > Mirroring in the local GUI, or monitor session on the M4300 CLI) to a spare port and running Wireshark on a laptop plugged into it.
4. Neither the Lite CLI nor the M4200/M4300 CLI has a native capture/monitor capture-to-file command — the CLI path to anything capture-like is configuring a mirror session, not an on-box capture engine.

Gotchas & notes

• This is the platform's biggest gap in the whole diagnostics matrix. Unlike PAN-OS or pfSense, there is no on-box capture engine you can pull a pcap from via CLI on any NETGEAR device — the closest thing to a real capture is the cloud-driven Insight tool, and that only exists for switches, and only on a paid Insight tier.
• The Insight Packet Capture menu item is easy to write off as 'missing' because on the free Insight tier it's hidden or grayed out with an upgrade prompt — if you don't see it, check the subscription tier on that switch before assuming the feature doesn't exist.
• Port mirroring is not a capture, it's a copy-to-a-port — if you need to see traffic on a router or Orbi Pro AP, the device itself is a dead end and you have to capture on whatever switch sits upstream of it instead.