McastTool

IPTV, IP video, market data or a paging system has just been deployed. The sender reports that it is sending, the receivers hear nothing, and the network team, the platform team and the vendor each have a reason why it is not their equipment. What is needed is not another opinion but proof of whether the traffic actually crosses the path — and proof has to be produced from wherever you happen to be standing.

Why I built it

Because the instrument the diagnosis needed did not exist at the place the diagnosis had to happen. Settling a multicast fault takes a known-good sender and a known-good receiver at two arbitrary points on the network, and most of the time neither is available. The real application cannot be installed on a laptop in a comms room, and packet capture on its own tells you what did not arrive, not why.

The other constraint is the machine. It is usually one you do not control, in a room you are visiting, often an old Windows build with no runtime installed and no permission to install one. That rules out anything that has to be installed first, which is most of the tooling that would otherwise do the job, and it is the entire reason this one is a single plain Windows application with no dependencies and no installer: copy it, run it, delete it.

The problem

Multicast fails quietly. There is no error anywhere, and the fault could be IGMP snooping on a switch, a missing querier on the segment, PIM not running on the router, an RPF check failing because the route back to the source takes a different path, a VLAN where the group was never joined, or a firewall discarding the group silently. Every one of those looks identical from the application: sent, and not received.

Without a way to test the path independently, the fault gets settled by elimination and by seniority. Configurations are changed speculatively, some of those changes are never undone, and the deployment slips while three parties exchange screenshots. The cost is rarely the fault itself — it is the time spent establishing whose fault it is.

What I did

• Sends and receives. The same tool at both ends of a path, so one engineer can test a segment from either side without arranging a second person.
• Multicast and unicast. Testing both isolates whether the problem is the path or the group, which is the first fork in the diagnosis and the one most often skipped.
• Chosen group, port and interface. Which matters on a multi-homed machine, where the operating system will otherwise pick an interface for you and mislead you.
• Configurable TTL, so you can prove whether packets are being dropped by hop count rather than by policy.
• Live counters on both sides, showing sent and received, so the result is immediate rather than inferred from a capture afterwards.
• One file, no runtime, no installer. A deliberate constraint rather than a limitation: anything that has to be installed will not be, on the machine where the test is needed.

The result

Used in pairs, one instance sending to a group on one VLAN and another receiving on a second, the question stops being whose equipment is at fault and becomes which hop stopped forwarding the group. That is a question a switch or router can be asked directly. Because the tool itself is known-good, anything that goes wrong is the network — which is the entire point.

It also makes a fix provable. The same test is repeated after each change, so a configuration that is said to have solved the problem either shows a rising counter at the far end or does not. Nothing is left behind on the borrowed machine, and no runtime has to be installed on it.

Like the other tools here, it exists because a network problem needed measuring and the available options answered a different question. The value is in the diagnosis; the software is just the instrument that made it possible.