Wireshark capture playbooks for AV/UC

Capture by MAC address

Capture every frame where a known MAC address appears as source or destination. Use this when you know the physical device but not its IP, or when investigating an unfamiliar device on the network.

Prerequisites

• Capture interface configured for promiscuous mode.
• Connection to a SPAN/mirror port, inline tap, or a hub-equivalent device that sees the target's traffic.
• The target MAC address (12 hex characters).

Procedure

1. Start Wireshark and select your capture interface.
2. Apply the capture filter shown below to limit the trace to traffic involving the MAC. This is optional — you can also capture broadly and filter later with the display filter.
3. Run the capture for at least 30 seconds (longer if the device is idle).
4. Apply the display filter and review the resulting frames.

eth.addr == aa:bb:cc:dd:ee:ff

ether host aa:bb:cc:dd:ee:ff

tshark -i any -f "ether host aa:bb:cc:dd:ee:ff"

The filter generator can produce this scoped to your device: wireshark-filter#mac

What to look for

• Source IP in any ARP reply — reveals the IP address the device is currently using.
• VLAN tag in 802.1Q frames — confirms switch port configuration.
• Broadcast/multicast traffic the device is sending or receiving — useful for service-discovery diagnostics.

Common issues

Capture returns no frames despite the device being active:

• Interface is not in promiscuous mode.
• You're on an access port instead of a SPAN/mirror port. Switch only sends frames destined for your MAC.
• The target device is on a different VLAN than what your mirror is capturing.
• For wireless networks: only the AP sees client MAC traffic — capture there if possible.

Trace DNS queries from a device

Identify hostnames that a device resolves during operation. This is the foundation for firewall whitelisting work, identifying unexpected outbound connections, and verifying cloud-service reachability.

Prerequisites

• Capture interface with visibility into the device's outbound traffic (SPAN, inline tap, or local capture).
• The device's IP address (or subnet if multiple devices).
• Plan to capture during boot, sign-in, and idle periods — cached resolutions can mean a steady-state capture misses queries.

Procedure

1. Apply the capture filter to limit volume.
2. Reboot the device or trigger the workflow you want to observe.
3. Capture for 10–20 minutes.
4. Apply the display filter, then open Statistics → DNS for a deduplicated query summary.
5. Export the unique-name list via File → Export Packet Dissections → as CSV if you need it for a ticket.

dns and ip.src == 10.0.0.50

host 10.0.0.50 and port 53

Scoped generator: wireshark-filter#firewall (firewall discovery covers DNS plus TCP SYN and TLS SNI).

Key fields to inspect

Field	Description
dns.qry.name	Hostname being resolved.
dns.qry.type	Record type (A, AAAA, CNAME, SRV, etc.).
dns.flags.rcode	Response code. 0 = success; 3 = NXDOMAIN; anything else = problem.
dns.resp.addr	Resolved IP address in the response.
dns.time	Time from query to response. >1 sec suggests a slow resolver.

Common issues

• Empty result set — device may use a non-standard DNS server or DoH. Confirm via the device's configuration page or use the TLS SNI playbook.
• All queries returning NXDOMAIN — DNS server is misconfigured or unreachable; the device will be effectively offline for cloud services.
• Queries succeed but no subsequent TCP traffic — DNS works but firewall is blocking the destination. Cross-check with tcp.flags.syn == 1 and ip.src == <device>.

Identify outbound destinations (firewall discovery)

Combined workflow to identify everything a device needs to reach. Use when whitelisting a new device on a restricted egress firewall, validating an existing policy, or auditing what an unfamiliar device is reaching out to.

Prerequisites

• SPAN/mirror port visibility into the device's traffic.
• Target device IP or subnet (e.g. 10.0.0.50 or 10.0.0.0/24).
• Time to observe a boot + sign-in + idle cycle (typically 15–30 minutes).
• Vendor documentation of expected endpoints (Microsoft Learn, Cisco Help Hub, etc.) as a reference baseline.

Procedure

1. Start capture with a broad filter that catches DNS, TCP setup, and HTTPS:

host 10.0.0.50 and (port 53 or tcp[tcpflags] & tcp-syn != 0 or tcp port 443)

2. Reboot the device. Sign in. Trigger any workflows (test call, share content, idle for 10 min).
3. Apply each display filter below in turn to extract the four destination lists.
4. Cross-reference the lists. Gaps between DNS and TLS SNI usually indicate hardcoded IPs or hostname pinning — these are the most interesting findings.
5. Build the firewall ticket from the deduplicated FQDN list (preferred) plus any standalone destination IPs.

Display filters

DNS queries (primary — hostnames to whitelist)

dns and ip.src == 10.0.0.50

Use Statistics → DNS → Queries by Name for a deduplicated list.

Outbound TCP connection attempts

tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.src == 10.0.0.50

Use Statistics → Endpoints to extract unique destination IPs. Sort by destination address.

TLS SNI (hostnames in HTTPS handshakes)

tls.handshake.extensions_server_name and ip.src == 10.0.0.50

The Server Name Indication is visible even in encrypted traffic. Often catches endpoints DNS missed.

Internet-bound only (exclude RFC1918)

ip.src == 10.0.0.50 and not (ip.dst == 10.0.0.0/8 or ip.dst == 172.16.0.0/12 or ip.dst == 192.168.0.0/16)

Generator with subnet support: wireshark-filter#firewall

SIP signalling and RTP media

Capture call setup signalling and the media streams it negotiates. Use to investigate one-way audio, codec negotiation issues, registration failures, and call quality complaints.

Prerequisites

• Capture visibility into the SIP endpoint and (ideally) the SIP server's network path.
• Endpoint IP address.
• Plan to capture during call setup — signalling completes in a few seconds, then is silent.

Procedure

1. Start the capture with the BPF filter below.
2. Place a test call from the endpoint.
3. Apply the display filter, then use Telephony → VoIP Calls to reassemble call legs.
4. For media-only analysis: Telephony → RTP → RTP Streams — shows packet loss, jitter, and lets you play back captured audio.

(sip or rtp or rtcp) and ip.addr == 10.0.0.50

host 10.0.0.50 and (port 5060 or port 5061 or (udp portrange 16384-32767))

Generator entries: wireshark-filter#sip · wireshark-filter#rtp

Key fields and what they tell you

Field	Indicates
sip.Method	INVITE / REGISTER / ACK / BYE — overall call state.
sip.Status-Code	SIP response code. 200 = OK; 401 = auth challenge; 403 = forbidden; 487 = cancelled.
sdp.media_attr	SDP attributes including codec negotiation.
rtp.payload_type	Codec in use (0 = PCMU/G.711, 8 = PCMA, 9 = G.722, etc.).
RTP Streams report	Packet loss percentage, max jitter, and stream duration.

Common issues

• SIP completes (200 OK + ACK) but only one RTP stream visible — one-way audio. Far end is sending media to an IP/port the network doesn't deliver. Common with NAT without ICE/TURN.
• SDP shows mismatched codecs — call connects but no audio because both ends fall back to incompatible codecs.
• High packet loss in RTP Streams report — investigate QoS marking and switch port stats with the network errors playbook (RTP loss often mirrors TCP retransmit patterns on the same path).

Dante audio and PTP clock sync

Capture Dante discovery, audio media flows, and PTPv2 clock-sync traffic. Use when investigating audio dropouts, glitches, channel loss, or clock instability.

Prerequisites

• SPAN/mirror port on the audio VLAN. Dante is L2-sensitive — a routed capture point may miss multicast.
• Dante device IP (or audio VLAN subnet).
• Dante Controller open in another window for cross-reference (Clock Status tab in particular).

Procedure

1. Mirror the audio VLAN to your capture port.
2. Start the capture during a period of audio activity.
3. Capture for 5–10 minutes including a known-bad period if the issue is intermittent.
4. Apply filters below to isolate each protocol layer.

(udp.port == 4321 or (udp.port >= 4440 and udp.port <= 4459) or ptp) and ip.addr == 10.50.0.0/24

port 4321 or portrange 4440-4459 or port 319 or port 320

Generator entry: wireshark-filter#dante

PTP analysis (clock stability)

Filter for PTP Announce messages and confirm a single master:

ptp.v2.messagetype == 0x0b

Expected output: one source IP sending Announce messages consistently. Multiple sources = grandmaster election storm = the most common cause of Dante dropouts.

Common issues

• Missing multicast Dante flows — IGMP snooping enabled without a querier on the VLAN. See the IGMP playbook.
• Sporadic packet drops — switch port speed/duplex mismatch or output discards. Check show interfaces counters errors on the switch.
• Inconsistent PTP — multiple grandmasters or BMCA flapping. Set explicit priority on the intended master device in Dante Controller.

mDNS / Bonjour discovery

Capture multicast DNS service-discovery traffic. Used by AirPlay, NDI, Sonos, Spotify Connect, Apple devices, many AV control protocols, and printers.

Prerequisites

• Capture visibility on the VLAN where the device is announcing.
• mDNS multicast runs on 224.0.0.251:5353 (IPv4) and FF02::FB (IPv6).

Procedure

1. Apply the capture filter.
2. Trigger the discovery (boot a device, refresh a service list in the controller app).
3. Filter by service-name fragment in the display filter to isolate one protocol.

mdns

mdns and dns.qry.name contains "_ndi"

udp port 5353

Generator entry: wireshark-filter#mdns

Common service names

Service	Used by
_airplay._tcp	Apple TV, AirPlay-enabled speakers, screen mirroring.
_raop._tcp	Remote Audio Output Protocol (AirPlay audio).
_googlecast._tcp	Chromecast and Google-cast-enabled devices.
_ndi._tcp	NewTek NDI senders and receivers.
_sonos._tcp	Sonos speakers.
_spotify-connect._tcp	Spotify Connect targets.
_workstation._tcp	Generic device announcement.

IGMP multicast diagnostics

Validate IGMP querier presence, group memberships, and snooping behaviour. Essential for any multicast-dependent service: Dante audio, NVX / NAV / SDVoE video, NDI, and AVB.

Prerequisites

• Capture on the VLAN carrying multicast traffic.
• If possible, capture from the switch's CPU or a SPAN that includes the IGMP querier's port.

Procedure

1. Capture for at least 2 minutes — IGMP queries are typically sent every 60-125 seconds.
2. Use the filters below to break down by message type.

igmp

igmp.type == 0x11

igmp.type == 0x16 or igmp.type == 0x22

igmp

Generator entry: wireshark-filter#multicast

What to verify

Check	Expected
Querier presence	At least one IGMP General Query every 125 seconds (default).
Querier source	Should be a router or the switch with the lowest IP if no router.
Membership reports	One per group your device wants to receive.
Leave messages	Sent when devices stop receiving a group. Common to see during reboots.

DHCP transactions

Capture the DISCOVER / OFFER / REQUEST / ACK exchange. Useful for diagnosing IP assignment failures, slow boot due to DHCP retries, and vendor-class fingerprinting (Microsoft Teams Rooms, Cisco IP phones).

Prerequisites

• Capture during a cold boot or DHCP renewal.
• Capture visibility on the client's VLAN — DHCP relay traffic is unicast and may not appear if you're capturing from a different segment.

Procedure

1. Start the capture.
2. Power-cycle the client (or run dhclient -r && dhclient on Linux clients).
3. Apply the display filter and trace the four-message exchange.

bootp

bootp and bootp.hw.mac_addr == aa:bb:cc:dd:ee:ff

port 67 or port 68

Generator entry: wireshark-filter#dhcp

Key DHCP options to inspect

Option	Field	Purpose
12	bootp.option.hostname	Hostname advertised by client.
50	bootp.option.requested_ip_address	IP the client wants to keep (re-lease).
53	bootp.option.dhcp	Message type (1=DISCOVER, 2=OFFER, 3=REQUEST, 5=ACK, 6=NAK).
55	bootp.option.request_list_item	Parameter request list — what options the client wants.
60	bootp.option.vendor_class_id	Vendor class — used to trigger MTR-specific configs.
61	bootp.option.client_id	Client identifier (often the MAC).

LLDP-MED for PoE diagnostics

Capture Link Layer Discovery Protocol advertisements to confirm device PoE class negotiation, port assignment, and VLAN configuration.

Prerequisites

• Physical access to the device's switch port or a configured SPAN of that port.
• Allow up to 60 seconds for the next LLDP advertisement after plugging in (default TX interval is 30 sec).

Procedure

1. Set up port mirroring or insert the capture device inline.
2. Start capture with the LLDP filter.
3. Wait at least 60 seconds for two advertisement cycles.
4. Inspect the LLDP-MED Power TLV in the packet detail pane.

lldp

ether host 01:80:c2:00:00:0e

Generator entry: wireshark-filter#cdp-lldp

Key LLDP-MED TLVs to inspect

TLV	What it tells you
System Name	Switch hostname.
Port Description	Switch port the device is plugged into.
Port VLAN ID	Configured VLAN.
LLDP-MED Extended Power-via-MDI	Negotiated PoE class, requested power, and actual allocation. The key TLV for PoE issues.
LLDP-MED Network Policy	Voice VLAN / DSCP advertisement (used by IP phones).

TCP retransmits and resets

Identify packet loss, connection problems, and latency-driven issues using Wireshark's built-in TCP analysis. Run this first when users report degraded performance, drops, or intermittent connectivity.

Prerequisites

• Capture visibility on the affected endpoint (SPAN or local capture).
• Capture during a known-bad period if the issue is intermittent.

Procedure

1. Start capture (broad — TCP analysis depends on seeing both directions of the stream).
2. Apply one of the display filters below.
3. For deeper analysis: Statistics → Conversations → TCP shows per-flow throughput, retransmit counts, and round-trip times.
4. For visual diagnostics: Statistics → TCP Stream Graphs → Round Trip Time per conversation.

tcp.analysis.flags

tcp.analysis.retransmission

tcp.flags.reset == 1

(tcp.analysis.flags or tcp.flags.reset == 1) and ip.addr == 10.0.0.50

Generator entry: wireshark-filter#errors

What the TCP analysis flags mean

Flag	What Wireshark detected
Retransmission	A previously-seen segment was re-sent — usually the receiver didn't ACK in time.
Fast Retransmission	3+ duplicate ACKs triggered an immediate retransmit. Indicates a single lost packet.
Duplicate ACK	Receiver got an out-of-order segment and is signalling the gap.
Out-Of-Order	A segment arrived earlier than its sequence number suggests.
Previous segment not captured	Wireshark inferred a gap from sequence numbers but didn't see the missing segment — could be a capture gap or a real loss.
Zero Window	Receiver advertised a window of 0 — it's not ready for more data.

Common issues

• High retransmit rate on a single endpoint — check switch port stats for errors, replace cable, confirm PoE class isn't underpowered.
• Bursty retransmits across many endpoints — investigate WAN saturation or QoS misconfiguration.
• Frequent RST flags from one peer — often a stateful firewall or load balancer tearing connections it doesn't recognise.