As packet-heads, we all enjoy digging through trace files and finding the hidden gems that lead to resolving a problem. If most of our capturing experience is from a single network or enterprise, it can be hard to grow in new areas and pick up new tricks in packet analysis. Sharkfest is an excellent way to hone our skills and bring our art of analysis to a new level.
The group packet challenge at Sharkfest is designed to bring together Wireshark users from all skill levels in a timed team event. Participants are given several trace files and a question sheet, then as a team they race to find the answers. Typically, the packet challenge will require them to use areas of Wireshark that they may not be as familiar with, which can teach them new things about the analyzer in a fun setting.
Packets don’t lie – well, most of the time.
They tell the truth unless they have been captured incorrectly. In those cases, packets can tell bold-faced lies.
When digging through trace files, we can come upon symptoms in the packets that may raise an eyebrow. These are events that look strange on the surface and may even divert our troubleshooting focus for a time. In fact, some of these issues have misdirected engineers for hours, if not days, causing them to chase down issues and events that simply did not exist on the wire.
For years now we all have read about the difference between data capture off a span/mirror port and an inline network TAP. In fact, many of those comments have come from one of the great moderators of lovemytool.com, Tim O'Neill, the @OldCommGuy who loves the TAP side of the ring.
Packet Pioneer was interested to see the difference between a data stream captured on a network TAP versus a SPAN port. So they set up a test with a few PCs, a TAP, a SPAN port, a couple of hardware network analyzers, and a healthy stream of data.
The results were interesting, to say the least: The study showed that Tim O’Neill is correct!