pjhtech Tools
Ubiquiti · UniFi

UniFi Packet Capture: Where to Capture and What to Filter

A useful capture starts with a question: did the request reach this point, and did its reply come back? Choose an interface that the test flow must cross. Capturing on the gateway cannot explain two devices communicating entirely inside the same switched VLAN if their frames never reach the gateway.

Scope: UniFi AP and gateway SSH environments that provide tcpdump. Ubiquiti documents separate AP and gateway invocation. Interface naming is model- and firmware-dependent; no universal br0, eth8 or switch-port mapping is asserted. Not an over-the-air monitor-mode guide.

For a wireless client's DHCP problem, compare the AP's relevant uplink or bridge view with the DHCP-facing gateway interface. For a routed DNS failure, inspect the client-side gateway interface first. For a published service, compare the ingress WAN side with the server-facing network. Note that destination NAT changes the address you need to match on the inside.

Start with a bounded capture #

Replace <interface> with the actual interface identified for this device and flow. These examples use standard tcpdump filters; they are not UniFi interface names.

Start with a bounded capture
UniFi · Supported UniFi device SSH shell

Diagnostic state

Replace these example values: <interface>.

tcpdump -ni <interface> -c 100 'udp port 67 or udp port 68'

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.
Diagnostic state

Replace these example values: <interface>, 192.0.2.10.

tcpdump -ni <interface> -c 100 'host 192.0.2.10 and port 53'

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.
Diagnostic state

Replace these example values: <interface>, 192.0.2.10.

tcpdump -ni <interface> -c 100 'host 192.0.2.10 and tcp port 443'

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.

The documentation addresses above are placeholders. Use your actual test client or server. A packet-count limit ends the capture only after that many matching packets arrive; if the test is quiet, stop it manually with Ctrl+C. These commands display packet summaries rather than writing an unrestricted full-payload capture to flash.

Read the result as a comparison #

ObservationNext question
No matching packetsCorrect interface, address, test timing and filter?
DHCP discovery without an offer hereDoes the server see the request and generate a reply?
DNS request without a reply hereDoes the resolver receive it, and is the return path valid?
Repeated TCP connection attemptsWhere is the first missing response?
Request and response at the gatewayDoes the endpoint receive and accept the response?

An empty capture is not sufficient proof that a firewall dropped traffic. The interface may be wrong, the flow may be switched elsewhere, or the capture point may not expose the forwarding path you expected. For switch-only traffic, choose an appropriate mirrored observation point rather than assuming a switch management-shell capture sees every port.

Keep one test client and one test action per capture. Record the start time, endpoint addresses, VLAN and capture interface. If a support engineer needs a saved PCAP, agree a size and duration first and transfer it privately. For RF retries, channel use or 802.11 management exchanges, use an appropriate wireless capture workflow; an Ethernet-side capture answers a different question.

Sources

Documentation reviewed: 8 October 2026