Lumra · Interference analysis
When a site won't load, most tools say it's "down." Lumra tells you how and where it's being interfered with — DNS tampering, SNI filtering, injected resets, self-identifying block pages — from packets it measures itself, never a third-party block list.
What it tells you
The same symptom has very different causes. Lumra separates deliberate interference from an ordinary fault — and pins where in the path it happens — so you act on the real problem, not a guess.
| Site won't load | Real outage vs. state-level block vs. local network fault |
|---|---|
| Wrong / missing DNS answer | DNS poisoning or tampering vs. NXDOMAIN vs. misconfiguration |
| TLS handshake fails | SNI-based filtering vs. certificate error vs. MITM interception |
| Connection reset | Injected RST from an in-path filter vs. a genuine server reset |
| Slow / stalling | Deliberate throttling vs. ordinary congestion |
How it works
Every diagnosis runs from your own vantage point and compares against control baselines — so the answer reflects your network, not a stale block list someone else published.
Lumrawarning.or.kr → KCSC — not left as an anonymous failure.{type, cause, confidence, evidence[]} — a labeled result with the signals behind it.What it detects
Each probe isolates one class of interference. Together they separate a deliberate block from a broken link — and say who and where.
warning.or.kr → KCSC — the strongest attribution signal there is.Every run resolves to one labeled verdict
The output
Every verdict ships with the signals that produced it and a confidence score. Human-readable by default, --json for pipelines — or a self-contained HTML page you can share as proof.
target news.example.kr (203.0.113.24) verdict SNI_FILTERING confidence 0.94 cause in-path reset keyed on the TLS SNI evidence ▸ control baseline reaches target on port 443 ▸ handshake with target SNI reset after ClientHello ▸ handshake with benign SNI to same IP succeeds ▸ RST TTL places injector ~6 hops out (dest ~14) ▸ no block page served — silent drop attribution injected on-path, upstream of destination not a local network fault · not an outage
Where it runs
Diagnosis has to run where the interference is — your own network. One binary, no account, no data leaves the host.
--json for CI and dashboards.Install · v0.1.0 · open source
A single static binary, no account. Deep RST/TTL attribution needs a raw socket (run elevated); every other signal works unprivileged.
$ brew install croc100/tap/lumra $ lumra diagnose example.com
# Scoop > scoop bucket add croc100 https://github.com/croc100/scoop-bucket > scoop install lumra # or without a package manager (PowerShell) > irm https://raw.githubusercontent.com/croc100/lumra/main/install.ps1 | iex
$ go install github.com/croc100/lumra/cmd/lumra@latest $ lumra diagnose example.com
$ git clone https://github.com/croc100/lumra $ cd lumra && go build ./cmd/lumra $ ./lumra diagnose example.com
When it matters
No packet-content logging. Analysis is metadata- and behavior-based, in line with CRODE's no-log stance. Lumra diagnoses interference — it does not route around it. Circumvention is Warren's job.
Part of CRODE
Bring us a target you can't reach, and we'll show you exactly how — and where — it's being interfered with.
Get started →