I see networks being attacked all the time through tiny glitches in their setup. I wanted to make a few common problems easier to spot, so I could warn friendly network operators about issues in their own networks too. Pinglet grew out of that, and I decided to make it open source so others could use it as well.
The name comes from “Piglet”, my three-year-old’s pet name for her six-year-old brother.
Pinglet focuses on exposing vulnerable network echoes: route loops that create traffic amplification risks, and “noisy neighbours” that reply to simple probes where I expect silence. I want to turn those small, easily missed behaviours into evidence I can share with the people running the network.
Looking for unwanted echoes
A network can appear healthy while still doing something strange at its edges. A packet sent towards an unused address may get caught in a routing mistake; a device may answer a basic request from somewhere it was never meant to be reachable. I’m interested in what comes back from those small probes, and what that response tells me about the network behind it.
The current work brings together three checks: possible routing loops, unexpected web-service responses, and changes in the path to a destination. Together, they give me a way to look beyond whether a target is simply up or down.
When traffic gets stuck
A routing loop can send a packet around the same links repeatedly, consuming bandwidth and router effort until its lifetime runs out. That is the amplification risk I’m interested in: a small amount of incoming traffic causing repeated work inside the core.
The loop detector probes configured address ranges and looks for TTL-expired replies. It records the destination being tested and, when available, the router reporting the expiry. Known cases can be silenced so that an understood condition does not keep filling the alert channel.
A TTL-expired reply tells me the probe exhausted its hop budget. It flags a possible loop for follow-up; confirming the loop and its impact takes further investigation.
Noisy neighbours
There is another kind of echo I want to find: a device answering a minimal request when I would expect silence. The web-service check asks configured addresses and ports for a basic HTTP response, then records the status code and any server or device clues in the headers.
That can bring an overlooked router web interface or another unexpectedly exposed service into view. The useful question for the operator is simple: is this meant to be reachable here? An HTTP reply shows that a service is responding; whether that exposure is a fault depends on what the network is intended to allow.
Watching the route change
The path monitor uses MTR to follow the route towards a destination and keeps a record of the last good path. It adds network numbers and operator names using RIPE’s prefix data, making a trace easier to relate to the networks involved.
It compares a simplified sequence of the networks seen along that trace, grouping consecutive hops in the same network and allowing for routers that do not answer. That helps avoid treating a less talkative router as a meaningful route change. It is a view of the observed forwarding path, useful for noticing a change in transit or where replies stop.
The monitor also distinguishes a failed probe from a destination that appears unreachable, and reports recovery. If the monitoring tool itself has failed, I want that stated clearly rather than presented as evidence that a remote network has gone down.
Making the findings useful
The checks are small PHP command-line tools with configured targets, timeouts, local logs and Slack notifications. They can sit alongside my existing monitoring without needing a large dashboard first.
A loop alert identifies the target and the router reporting the expiry. A path-change alert puts the old and new network sequence side by side. When a destination appears unreachable, the report includes the last responding hop and, where a saved baseline is available, the next hop it expected.
That gives me something concrete to investigate and a clear finding to share with a friendly operator. Making Pinglet open source means other people can inspect the checks, adapt them to their own networks and help each other catch the little problems before they become much bigger ones.