Lab: capturing and analysing IoT traffic
In short: IoT devices cannot run capture tools, so you capture on the path their traffic takes. This lab shows three capture points and a repeatable way to find out who a device talks to, whether it encrypts and what firewall rules it actually needs.
Aim and what you need
The aim is to answer three questions about a device you own: which servers does it contact, does it encrypt its traffic, and does it try to reach anything on your local network? The answers help you write tight firewall rules and spot risky devices.
- A smart device you own, such as a plug, bulb or camera, ideally on an IoT VLAN. Example device address: 192.168.30.20.
- One capture point: a Linux-based router or firewall with tcpdump, a managed switch with port mirroring (SPAN, Switched Port Analyzer) and a laptop, or a Raspberry Pi acting as the device's Wi-Fi access point.
- Wireshark on your laptop (see the Wireshark lab).
Legal note: capture only your own devices on a network you control. Captures can contain personal data such as names, locations and camera images, so store them securely and delete them when finished. Capturing other people's traffic without permission is illegal in many countries.
Steps
- Choose a capture point and set it up (commands below).
- Start the capture, then power-cycle the device so you record its start-up behaviour.
- Use the device's app for one action, such as switching it on, and note the time.
- Leave it idle for ten minutes to see background traffic, then stop the capture.
- Open the file in Wireshark and work through the analysis filters.
# on a Linux router or Pi access point
sudo tcpdump -i wlan0 -n host 192.168.30.20 -w plug.pcap
# Cisco switch mirror: device on gi0/5, laptop on gi0/24
monitor session 1 source interface gi0/5 both
monitor session 1 destination interface gi0/24
show monitor session 1
# summaries with tshark
tshark -r plug.pcap -q -z conv,ip
tshark -r plug.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.name | sort | uniq -c | sort -rn
tshark -r plug.pcap -Y "tls.handshake.type == 1" -T fields -e tls.handshake.extensions_server_name | sort -u
# useful Wireshark display filters
ip.addr == 192.168.30.20
dns
tls.handshake.type == 1
mqtt || http
ip.dst == 192.168.10.0/24
udp.port == 5353 || udp.port == 1900
!(tls) && tcp.len > 0What to look for
| Check | Healthy sign | Warning sign |
|---|---|---|
| Destinations | A few vendor or cloud names | Many unknown hosts or direct IPs |
| Encryption | TLS for cloud traffic | Plain HTTP or MQTT with readable data |
| Local traffic | Only replies to your phone | Scanning or connecting to other LAN hosts |
| Time and DNS | NTP and DNS to expected servers | Hard-coded DNS that ignores your resolver |
Write a short findings list: each destination, protocol, port and whether you will allow it. Encrypted TLS content cannot be read, but the server name in the handshake (SNI, Server Name Indication) and the timing still tell you a lot.
Troubleshooting and clean-up
- Empty capture: wrong interface (
tcpdump -Dlists them) or the device is on a different network. - Only broadcast traffic on a laptop: switches send unicast only to the right port, so you need SPAN or a capture on the path.
- Too much data: filter on the device address and capture for a set time.
Remove the SPAN session with no monitor session 1, return the Pi access point to normal use, and securely delete captures you no longer need. Turn findings into firewall rules and document them.
Practice
Why can a laptop on a normal switch port not see a smart plug's traffic?
Traffic is encrypted with TLS. What can you still learn?
Why power-cycle the device at the start of a capture?
Key takeaways
- Capture on the path: router, SPAN port or Pi access point.
- Only capture devices and networks you own or are authorised to test.
- Start with conversations, DNS names and TLS server names.
- Plain-text protocols and LAN scanning are warning signs.
- Turn findings into tighter firewall rules, then delete captures.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.