If you have captured packets with tcpdump while IoT Inspector is running, you'll see duplicate packets to and from the Inspector-running host. Here's an example of what you would expect:

Let's say you're running IoT Inspector on a host with the mac address H. You're capturing packets between a device with mac address D and the Internet. The gateway has a mac address of G. On H, you're running tcpdump. You will NOT see packets between D and G. If there's a packet from D to G, you'll see two packets in the capture:

• From D to H (in the Ethernet header)
• From H to G (in the Ethernet header)

Currently, this parser cannot handle the situation above. Users of this parser would have to manually identify and de-duplicate these packets.

I think @Rameen-Mahmood is one of the primary users of this script. Just make sure to handle this issue.

The current version labels IPs with hostnames obtained from DNS and SNI (assuming TLS 1.2). However, there are still cases where the src_hostname or dst_hostname fields are empty, because the parser didn't see any corresponding IP-hostname mappings from DNS and SNI.

Here's one thing the user (say @Rameen-Mahmood) can do to mitigate this issue: Instead of parsing one pcap at a time, you can capture a bunch of pcaps (e.g., repeated experiments from the same app, or running tcpdump on multiple apps) and run this parser on the pcaps at the same time (e.g., python parser.py output.csv *.pcap). In this way, the parser can use DNS/SNI information extracted from one pcap and apply this IP-hostname mapping to other pcaps.

Still, I'd expect a number of IPs with no hostname labels. What I can do to mitigate this situation would be:

• query against a private passive DNS API to turn these IPs into hostnames (although this process could be error-prone especially if the IPs are on shared infrastructure)
• find the reverse DNS data (i.e., PTR records) for unlabeled IP addresses (although this process is moot in cases where the PTR records simply correspond to the IP address, e.g., the PTR record of 54.156.150.34 is ec2-54-156-150-34.compute-1.amazonaws.com, which is not useful and you could have used the IP address instead)