Packet Capture Basics for Yacht Network Faults

This article applies when yacht technical teams need to collect packet-level evidence for network faults, application failures, Wi-Fi issues, DNS/DHCP faults, VPN problems, remote-support escalations, AV-over-IP behaviour, or suspected cyber events.

Applicability depends on the network zone being inspected, whether traffic includes guest, owner, crew, CCTV, access control, bridge-adjacent, or engineering OT data, and whether the capture will be shared with a vendor, management company, insurer, incident responder, or equipment manufacturer.

A packet capture is powerful because it shows what actually crossed the wire. That is also why it needs care. It can reveal IP addresses, device names, DNS lookups, authentication flows, unencrypted content, guest browsing behaviour, and system relationships that should not be casually collected or emailed around.

A packet capture is a recording of network traffic visible from a chosen capture point. Tools such as Wireshark, tcpdump, firewall packet-capture utilities, switch diagnostics, or cloud-managed network platforms can collect this traffic and save it as a file, often in `.pcap` or `.pcapng` format.

For yacht troubleshooting, a capture is useful because it can answer questions that dashboards often hide:

• Did the device send a request?
• Did the gateway reply?
• Did DNS return an answer?
• Did the TCP connection complete?
• Did the application reset the session?
• Did the packet leave one VLAN but fail to reach another?
• Did latency, retransmission, or loss appear at a specific point?

This is not the first tool for every problem. Start with the basics: IP address, gateway, DNS, VLAN, firewall rule, switch port, wireless association, logs, and recent changes. Use packet capture when those checks do not explain the behaviour or when a vendor needs evidence that proves where the failure occurs.

Bad packet captures usually start with a vague request: "capture the network." That is too broad for a yacht.

Start with a specific question:

• Why does this TV fail to reach the media server?
• Is this DNS resolver replying to guest clients?
• Does the camera reach the NVR?
• Is the firewall dropping the VPN handshake?
• Does the AV-over-IP encoder send multicast on the expected VLAN?
• Does a cloud controller fail because of DNS, TLS, routing, or authentication?

The question decides the capture point, filter, duration, and privacy risk. A five-minute capture of an entire owner-office VLAN is rarely appropriate. A short filtered capture between one device and one service is usually more useful and safer.

The capture point determines what you can see. If you capture in the wrong place, the file may be technically correct but operationally useless.

Useful capture points include:

• the affected device itself,
• the switch port serving the device,
• a mirror or SPAN port on the access switch,
• the firewall interface for the affected VLAN,
• the server or NAS receiving the connection,
• the VPN or WAN edge during remote-access faults,
• a temporary tap or diagnostic appliance where approved.

For example, if a guest device cannot resolve DNS, a capture on the laptop may show that DNS requests are leaving the device. A capture on the firewall guest interface may show whether the requests arrive at the gateway. A capture on the DNS server may show whether the service receives and answers them. Those three views tell different stories.

Do not assume that one capture point proves the whole path. Yacht networks often include VLANs, wireless controllers, firewalls, SD-WAN routers, satellite terminals, AV switches, cloud services, and vendor gateways. The fault may sit between those layers.

Filtering is not only about making the file smaller. It also reduces privacy exposure.

Use capture filters where possible so unwanted traffic is never collected. Use display filters later to analyse traffic already captured. The difference matters: a display filter hides packets from view, but the capture file may still contain them.

Practical capture filters might focus on:

• one host IP address,
• one server IP address,
• DNS traffic for a specific device,
• DHCP traffic during a lease failure,
• one TCP or UDP port,
• traffic between two endpoints,
• one VLAN or interface.

Keep the filter simple enough that the next person can understand it. If the capture is going to a vendor, include the filter used and why it was chosen.

Packet captures can contain personal data and sensitive operational information. On a yacht, that may include guest device names, browsing lookups, crew systems, owner-office traffic, CCTV endpoints, access-control systems, network diagrams in device names, or remote-support destinations.

Treat capture files as controlled evidence:

• get approval for the capture scope,
• collect only the network needed,
• avoid broad guest or owner-office captures unless justified,
• do not capture passwords or unencrypted sessions if avoidable,
• store the file in a restricted location,
• share only with named support parties,
• delete or archive according to the yacht's evidence policy,
• record who received the file.

If the issue touches personal data, cyber incident response, legal exposure, insurance, or owner-office systems, involve the right management or privacy decision-maker before distributing packet files externally.

A packet capture without context is hard to use. A packet capture with accurate time, a clear fault window, and matching logs is much more useful.

Before capturing, record:

• local yacht time and time zone,
• UTC if used in logs,
• affected device,
• affected network or VLAN,
• capture point,
• expected behaviour,
• exact test performed,
• start and stop time,
• recent network changes.

Make sure the laptop, firewall, switch, server, and monitoring tools have sensible time settings. If Wireshark shows one time, the firewall log shows another, and the vendor ticket uses a third, the investigation slows down quickly.

Packet capture helps most when it is tied to a real fault.

For DNS and DHCP, captures can show whether requests are leaving the device and whether replies come back. This is useful when guest Wi-Fi says connected but applications fail.

For firewall policy, captures can show whether traffic reaches the firewall, leaves the correct interface, or receives resets. Pair this with firewall logs; do not rely on packet capture alone.

For VPN and remote support, captures can show whether the handshake starts, whether NAT or routing is wrong, or whether the remote endpoint is unreachable. Be careful here because vendor remote-access evidence can expose support architecture.

For AV-over-IP and multicast, captures can show whether multicast streams, discovery packets, or control messages are present on the expected VLAN. This is useful when a room works locally but fails across a routed boundary.

For Wi-Fi issues, a normal wired packet capture may not show the radio-layer problem. It may still help after association, but roaming, interference, retries, and airtime issues usually need Wi-Fi controller data or wireless-specific capture tools.

For suspected cyber incidents, capture only under an approved response process. Live capture can be useful, but it can also disturb systems, expose sensitive data, or create evidence-handling questions.

Remote support works better when the yacht sends a small, clean evidence pack instead of a large unexplained file.

Include:

• fault summary in plain language,
• affected device and IP address,
• expected destination or service,
• network/VLAN involved,
• capture point,
• filter used,
• exact test performed during capture,
• start and stop time,
• relevant firewall, switch, DNS, DHCP, or application logs,
• recent changes,
• what has already been ruled out.

Do not send vendors a broad capture and ask them to "find the problem." That wastes time and may disclose more than they need. Give them the question the capture is meant to answer.

A yacht has an intermittent issue where the owner-office printer works from crew laptops but not from the owner's workstation. The printer, workstation, and laptops are on different VLANs. The firewall rules look correct, and the printer web interface is reachable from the crew network.

A broad capture of the whole owner network would collect too much. A better approach is to capture a short test from the owner workstation to the printer, then compare it with a successful test from a crew laptop.

The evidence shows that the owner workstation sends traffic to the printer, the firewall forwards it, and the printer replies. The reply returns to the firewall but is not passed back to the owner VLAN because the return policy is tied to an old address object. The packet capture does not replace the firewall logs, but it confirms where the conversation breaks.

The fix is not "restart the printer." The fix is to update the firewall object, document the change, and test both directions.

Do not capture more than needed. Big files slow analysis and increase privacy risk.

Do not forget the capture point. A file named `fault.pcapng` is almost useless if nobody knows where it was collected.

Do not rely on display filters as privacy controls. If the packet is in the file, it may still be shared.

Do not send captures to vendors without recording who received them and why.

Do not ignore time. If timestamps do not line up with logs, the support path becomes guesswork.

Do not treat packet capture as proof of permission. Just because a technician can capture traffic does not mean every network zone is appropriate to inspect without approval.