v0.2.1 - Ploss: Per-hop Packet Loss Detection

CLI tool parses mtr output to identify specific hops dropping packets and generates ISP support evidence files
packet-loss network-diagnostics mtr traceroute isp-support cli python

April 22, 2026 – Version 0.2.1. Production release.

Can a CLI tool turn raw mtr output into actionable ISP evidence?

Ploss parses my traceroute output, identifies per-hop packet loss, pinpoints bottleneck routers by IP address, and generates structured evidence files. Rather than providing raw traceroute data, the goal was to create ISP-ready diagnostics that document exactly where packets drop.

The project began with basic mtr integration and evolved through real network testing from Malmö, Sweden to Google’s public DNS server.

The finding: Hop-level analysis with JSON/CSV export solves the “ISP says no issues” problem.

Added

mtr Output Parser: Complete parsing of my traceroute output for per-hop loss percentages, latency statistics, and IP addresses. Handles variable hop counts and malformed lines.

Bottleneck Detection Engine: Identifies highest loss hop with specific IP address and loss percentage. Provides actionable “BAD Hop X” classification.

ISP Evidence Export: JSON structured diagnostics + CSV spreadsheet format. Files contain complete hop analysis with timestamps for support tickets.

Production CLI Interface: ploss [target] [--mtr] [--json=proof.json] [--csv=hops.csv] [--watch]

Zero Runtime Dependencies: Pure Python 3 implementation, cross-platform compatible.

Improved

Output Formatting: Clean console summary with “OK Hop” vs “BAD Hop” classification and actionable recommendations. To keep it simple

Robustness: Handles real-world mtr output variations including partial hops, rate limiting artifacts, and variable response patterns.

Export Quality: JSON follows structured schema for diagnostics. CSV formatted for direct Excel analysis. Thereby statistical models can be applied to get a distribution and graph the downtime, cost per hour, cost per minute, etc etc..

Tested and Validated

Real Network Path: 8.8.8.8 test from Malmö, Sweden (Telenor ISP):

  • 12 hops total, 5.8% path loss
  • Hop 4 failure confirmed: 81.228.84.95 = 70.0% loss
  • Final hop validation: 8.8.8.8 = 0.0% loss ✓
  • Average latency: 9.9ms end-to-end

Platform Testing: macOS primary development environment. Linux structure validated.

Export Validation: Both JSON and CSV files generated correctly with complete hop data and analysis summary.

CLI Reliability: All flag combinations tested: --mtr, --json, --csv, --watch, and combinations.

What We Learned

ISP Rate Limiting Common: 70% loss on Hop 4 (81.228.84.95) while final destination was clean indicated, that deliberate ICMP filtering was at play and not path failure.

JSON/CSV Essential: Structured exports solve the evidence problem. ISPs require documented proof beyond screenshots. And sometimes in order to strengthen our complaints we need it documented.

mtr Parsing Complexity: Real traceroute output varies significantly from documentation. Robust parsing required extensive edge case handling on a few fronts. It also constituted two rewrites.

CLI Expectations: Network engineers expect zero dependencies and instant usability. 15KB binary size meets this standard. Which should prevent being overcharged, and keep the costs low.

Key Findings

Bottleneck Localization:

  • Hop 4: 81.228.84.95 → 70.0% loss (ISP router)
  • Final: 8.8.8.8 → 0.0% loss

Pattern: Single hop failure, clean destination = ISP issue

Evidence Generation: proof.json → Structured diagnostics hops.csv → Excel analysis table (downtime/cost modeling)

Both files contain timestamps, hop-by-hop metrics, and bottleneck analysis

Production Readiness: Zero runtime dependencies + pyproject.toml packaging = instant pip install ploss

Technical Architecture

Core Implementation:

1
2
3
4

# mtr parsing → loss analysis → evidence generation
hops = parse_mtr_output(raw_mtr)
bottleneck = find_highest_loss(hop)
generate_evidence(hops, bottleneck, "proof.json", "hops.csv")

Test Coverage:

  • Real network path: 8.8.8.8 from Sweden ✓
  • Export validation: JSON+CSV structure verified ✓
  • Platform testing: macOS+Linux structure ✓
  • CLI flags: All combinations functional ✓

Implementation Status

Ploss demonstrates that mtr parsing + structured analysis + ISP-ready exports can be delivered in a 15KB zero-dependency CLI.

The key insight is that network diagnostics succeed when they provide specific IP addresses and documented evidence rather than aggregate statistics.

No existing CLI tool combines per-hop analysis with ISP-ready export formats while maintaining zero runtime dependencies.

Next Steps

  • Cloud provider endpoint testing (AWS/GCP/Azure paths)
  • Multi-target path comparison (google.com vs github.com vs cloud)
  • Agent deployment for distributed monitoring
  • UDP probe integration for ICMP-blind path testing
  • Historical analysis (compare today’s path vs yesterday)

Current Limitations

mtr Dependency: Requires mtr binary installed on system (standard on Linux/macOS)

ICMP Only: Current implementation uses ICMP probes. UDP testing planned.

Single Target: Tests one destination at a time. Multi-target comparison is planned.

Honest Assessment

This project successfully solves the consumer ISP debugging problem with a production-ready CLI that identifies specific router failures and generates ISP-ready evidence files. The zero-dependency approach and 15KB binary size meet professional standards.