Small packets can work while larger transfers stall. When that happens, a timeout alone does not tell you whether a packet was too large, filtered, lost, or whether the reply failed on its way back. I built TunnelScope, an MIT-licensed Python CLI, to collect more useful evidence on a controlled Linux path.
It sends bounded UDP payloads to a cooperating receiver. The sender records acknowledgements, explicit size errors, timeouts and optional Linux ICMP size feedback. The receiver can save the probe IDs it actually saw. Reports are JSON, with an offline HTML view for browsing the results.
Here is the simplest loopback test using the published v0.5.0 package:
python3 -m venv .venv source .venv/bin/activate python -m pip install tunnelscope # Terminal 1 tunnelscope receive --max-packets 2 --output receiver.json # Terminal 2, after the receiver says it is listening tunnelscope probe 127.0.0.1 --sizes 64,1200 --count 1 --output probe.json tunnelscope show probe.json tunnelscope html probe.json --output probe.html On the development branch, a new diagnose command combines three sequential, one-direction experiments: DF probes, the same sizes with source fragmentation permitted, and a bounded adaptive size search. It saves the underlying runs together in JSON and HTML. It is not in the v0.5.0 PyPI release yet.
In an isolated 1280-byte IPv4 link lab, the DF search observed a 1252/1253-byte UDP payload boundary (1280 minus 20 bytes of IPv4 and 8 bytes of UDP headers). That is a controlled direct-link result, not a claim that the tool discovers the exact MTU on arbitrary networks. A missing ACK remains inconclusive; observed ICMP can also be untrusted. Real VPN and Kubernetes path validation is still on the roadmap.
The code, a short terminal demo and reproducible labs are here: TunnelScope on GitHub. The diagnose guide explains the new workflow.
If you troubleshoot VPN or overlay MTU issues, I would value feedback on which observations would make a report more useful in practice.
