Unsolved Mysteries: The time Wireshark actually *solved* the problem

We just got back from a ticket for an issue to do with a new lighting control system for one of the theaters on campus. The system includes a layer-3 switch, and the setup process involves assigning a static IP to a laptop that is directly connected via Ethernet to the switch. The theater techs followed the steps in the setup guide to the letter, but no matter how much they would adjust the settings, and even after 45 minutes on the phone with the vendor's tech support, the laptop still could not ping the switch. That's when they called us.

We repeated the setup process, and did our normal network troubleshooting - verifying IP addresses, switching to another network cable, even switching to another laptop - but we didn't have any better luck than they did. Even Nmap couldn't see anything. So, we opened up Wireshark to try to see what the computer and switch may have been trying to send to each other.

Lo and behold, as soon as Wireshark began capturing packets, the laptop and switch could connect to each other, and we were able to use the lighting control program to send configurations to the switch and other equipment. As soon as we stopped the Wireshark capture, though, the problem returned. The only way that these two pieces of hardware can communicate is if Wireshark is running.

This works well enough for what the theater techs need it for, as once the program is uploaded to the equipment, it operates as a self-contained unit. We forwarded our findings on to the vendor's support, and advised the techs to make sure Wireshark is capturing packets if they ever need to connect to the system.

There's no way that Wireshark should help in this way, right?