Attend the www.COREITPROS.com conference with Laura Chappell, Mike Pennachi, Tony Fortunato August 22 - 26, 2022
In this next step, I connected the camera to a Profishark tap, then to a switch to capture bootup packets.
To be clear, the purpose of this exercise is not only to capture the packets, but to document how you captured the packets. As I mentioned in the video, documenting how you captured the packets is critical for many reasons. For example, if you want to perform this same exercise with other devices, you want consistency. Or more realistically, if others want to do the same thing you just did, it would be helpful if they did it the same way.
Explaining how you captured the packets can be very simple and for the purposes of this article, I will focus on wired capture. You can use a 10/100 hub since we are not measuring performance and just want the packets. If you do decide to use a hub, ensure that the switch it connects to properly detects that it is a half-duplex connection.
Another way to capture the packets is to configure a port for port mirroring, span, monitor, conversational steering or whatever your vendor calls it. Taps are also a great option if you have one. Ensure that when you use wither method, you captured bidirectional traffic.
The last option is to configure your computer as a bridge and capture from your computer. This last option requires a higher degree of technical skill and 2 network adapters.
After you captured the packets, resist the urge to jump in and analyze the packets. Concentrate more on documenting what you captured, what the goal of this exercise is and how you captured the packets. Depending on the reason for the capture, you will focus on different parts for the trace.
Examples
- Document the IP, TCP and UDP connection pairs to block or allow communication.
- Document the bootup process to ensure that DHCP and other network services don’t interfere with the device starting up properly.
- Determine what IP, UDP, TCP, Multicast and Broadcast is required for communication.
- Confirm and validate that device configuration changes actually do what they claim, like disable SSDP, UPNP, IPV6, casting, etc.
There is nothing wrong with not being able to figure out the purpose of every packet initially. I find it more helpful to cover the packets you can figure out and see what’s left. Another example of something you would document, like “DHCP process not compatible with our IP DHCP helper address”.
In the effort to keep these articles, short, concise and informative, I will analyze the packets in future articles.
Cheers
Commenti