Zero shared mutable state, no I/O -- behavior-preserving, verified via the
smoke-test harness (28/28 endpoints match baseline).
- server/data/*: CITY_COORDS, RIR_DELEGATION_URLS, TIER1_ASNS, IX_CITY_MAP,
RIR country-code sets, UA constant
- server/aspa-verification/engine.js: the RFC ASPA verification engine
(hopCheck, verifyUpstream, verifyDownstream, detectValleys, etc.)
- server/resilience-score.js, server/route-leak.js: pure scoring/heuristic
functions
server.js: 6838 -> 6454 lines. Part of the module-split plan at
~/.claude/plans/linked-riding-newell.md.
Follow-up from live testing the 2026-07-16 deploy: bogonDataUnavailable
only checked '!prefixData'/'!neighbourData' (falsy/null), but
local-db-client.js's DB-error signal is a truthy {status:'error', ...}
object, not null (server.js's own fabricated-success fix from earlier
today). So when the Postgres-backed prefix/neighbour source is what's
actually degraded, this check showed status:'pass' at 0 checked prefixes
instead of the more honest 'info' -- data wasn't fabricated (0 was
visible), just the status label didn't reflect it. Fixed with an explicit
isSourceUnavailable() check for both falsy and status:'error'.
2026-07-16 deep-dive audit (server.js, local-db-client.js, src/aspa/validator.ts)
found the flagship ASPA path verification producing wrong results, and a
recurring pattern where an upstream API or the local Postgres DB failing
would present as "checked, clean" instead of surfacing failure. All fixes
in this commit are empirically or textually verified against primary
sources (the IETF draft's actual algorithm text, RFC 5735/6890 bogon
ranges, and hand-built controlled test cases with known-correct answers)
-- not just read-and-guessed.
CRITICAL: ASPA hop-check direction was reversed
--------------------------------------------------
verifyUpstream/verifyDownstream/detectValleys called
hopCheck(collapsed[i-1], collapsed[i]) -- checking the PROVIDER-side AS's
ASPA object for the CUSTOMER, the opposite of
draft-ietf-sidrops-aspa-verification section 5.3's authorized(A(I), A(I+1))
(A(I) = customer, always checked first). Proven empirically: a hand-built,
fully-attested, zero-leak 3-AS path returned "Invalid" before this fix.
verifyDownstream needed a full rewrite, not just an argument swap -- a
downstream path can legitimately contain both an up-ramp AND a down-ramp
(e.g. origin -> providers -> peering point -> validator's providers ->
validator), and the old K/L/uMin/vMax computation didn't correctly
implement the draft's max_up_ramp/min_up_ramp/max_down_ramp/min_down_ramp
four-way computation. Rewrote it from the draft's exact halt conditions,
verified against a worked example fetched from the draft itself (an N=4
path with a single unattested "kink" correctly resolves Valid) plus 3
hand-built scenarios (pure up-ramp, mixed up+down clean, and a definite
leak with failures on both ends -- Invalid).
Same bug existed independently in src/aspa/validator.ts (the MCP-server-
side validator, different codebase, same conceptual error) -- validateUpstream
was already correct there, but validateDownstream naively reversed the path
and reapplied upstream logic, which cannot represent a legitimate down-ramp.
Rewrote it with the same four-ramp algorithm, cross-validated against the
same test scenarios through the compiled output.
Also in the same /api/aspa/verify handler: aspaStore.set(providerAsn, new
Set()) for detected-but-unattested providers made hopCheck report
"NotProviderPlus" (implying a real ASPA object that denies the hop) instead
of "NoAttestation" (we don't know) -- removed; hopCheck's own `!providers`
branch already handles the unset case correctly. Also removed a fallback
that fabricated an ASPA declaration from heuristically-detected BGP
neighbours when aspa_object_exists is false, which contradicted that exact
field in the same response.
ROOT CAUSE of ~9 broken checks: duplicate function declaration
--------------------------------------------------------------
Two `async function fetchRipeStatCached` declarations existed ~150 lines
apart (the original real RIPE-Stat-fetch+cache+throttle implementation,
and a newer local-DB-routing wrapper added during the Postgres refactor).
In JS, the second declaration silently wins for every call site in the
file. The wrapper only recognized 5 URL patterns (announced-prefixes,
asn-neighbours, as-overview, visibility, prefix-size-distribution) and
returned null unconditionally for everything else -- silently breaking
blocklist (Spamhaus), abuse-contact-finder, bgp-updates, routing-status,
looking-glass, whois, reverse-dns-consistency, maxmind-geo-lite-pfx, and
ixs lookups. Renamed the original to fetchRipeStatCachedFromApi and made
the wrapper fall through to it instead of returning null. Verified via an
isolated routing test (blocklist/abuse-contact-finder URLs now reach the
real implementation; the 5 known patterns still route to local DB).
Silent-failure / fake-success patterns fixed
---------------------------------------------
- local-db-client.js: 5 getRipeStat* functions returned status:'ok' with
empty data on Postgres error (fabricated success) -- now status:'error'.
server.js's /api/lookup now tracks which sources degraded, surfaces
meta.degraded_sources, and caches a degraded result for 90s instead of
the full 5min so a DB hiccup doesn't get repeated to every visitor.
- validateRPKIWithCache: DB errors and genuine "no covering ROA" both
produced status:"not_found" -- split into "not_found" (real) vs
"unavailable" (DB error). Updated all 5 call sites that compute RPKI
coverage percentages to exclude "unavailable" from the denominator (a DB
hiccup must not lower a network's displayed RPKI/ASPA score), and fixed
a pre-existing separate typo in the PDF report generator that checked
for 'not-found' (hyphen) when the actual value is 'not_found' (underscore).
- crossCheckRpki: an empty sample or a failed RIPE-validator lookup both
counted as a fabricated 100%/"agreement" instead of being excluded --
now returns agreement_pct:null when nothing was actually compared, and
the caller no longer averages null into overall_confidence. Also
documented (not silently left) that bgp.he.net fetching is hardcoded
off, so the "2-source" prefix/neighbour cross-checks never actually run
-- dataQuality.cross_checks now reports sources:1 honestly instead of
claiming a cross-check that never happened.
- lookupAspaFromRpki: added feedLoaded so a Cloudflare-RPKI-feed fetch
failure (rpkiAspaLastFetch never set) is distinguishable from "this ASN
genuinely has no ASPA object" -- surfaced as aspa_feed_healthy on both
ASPA endpoints.
- Bogon/IRR/Spamhaus-blocklist/reverse-DNS/BGP-visibility checks: fetch
failure -> empty result -> "pass" (or, for abuse-contact/rdns, a
misleading "fail") -- now report "info" (excluded from the weighted
health score, matching the existing checkManrsMembership pattern) when
the underlying data source didn't actually respond.
- Hijack monitoring: checkHijacksForAsn returned [] on DB error,
indistinguishable from a genuine zero-prefix result. On a subscription's
first monitoring cycle this permanently persisted an empty baseline,
silently disabling leak detection forever while the UI kept showing it
as active. Now returns null on failure; runHijackCheck skips the cycle
entirely (retries next time) instead of locking in a bad baseline. Fixed
2 other call sites that would otherwise crash or persist null onto disk.
- WHOIS cache: a transient failure across all 5 RIR sources (RIPE + 4
RDAP endpoints) was cached as "not found in any RIR database" for 24h,
identical to a genuinely non-existent ASN. Added a 10min TTL for that
specific case instead.
- /api/relationships: a neighbourData fetch failure produced "0
upstreams/downstreams/peers", cached unconditionally for 10min. Applied
the same 90s-on-suspicious-zero guard the codebase already uses for
/api/validate (commit 4cf1673) but never applied here.
Verification
------------
node --check on both .js files, tsc --noEmit clean on every touched
TS module (remaining errors are 100% pre-existing, in the unrelated
mcp-server subsystem), npm run build succeeds, isolated empirical tests
for both the ASPA algorithm (3 hand-built scenarios with known-correct
answers, cross-checked against draft text fetched live) and the
fetchRipeStatCached routing fix, and a full local boot test reaching the
exact same pre-existing sandbox-only crash point (missing PEERINGDB_API_KEY,
unrelated to this commit) as a baseline boot before any of today's changes.
Not deployed to Erik as part of this commit -- server.js and
public/index.html there are untouched.
The 2026-07-14 backend refactor (PR #1) moved 13 features' route logic
out of server.js into src/features/*/routes.ts as Fastify plugins, and
left "// Migrated to src/features/X/" comments behind -- but never
actually built or started anything that served those plugins. Found a
complete, unused Fastify app bootstrap already sitting at
src/api/server.ts (added in an earlier commit, 5554c1a, alongside the
BGP hijack/PDF-export/ASPA-adoption work) that imports and registers
all 16 route modules, including 3 (pdf-export, aspa-adoption,
hijack-alerts) with proper Postgres-backed implementations, tests, and
PDF templates -- more capable than the puppeteer-based inline version
kept from the production snapshot. Also confirmed there is no code
anywhere that calls initializeDatabase() or startApiServer(): this
Fastify server had never actually been run, not even once.
What this commit does:
- Fixes 6 real TypeScript compile errors blocking `tsc` from building
the affected modules cleanly (all pre-existing, none introduced by
this branch):
- src/routes/hijack-alerts.ts: route generic was missing `Body` in
its type param, so it didn't match the handler's own declared type
- src/features/aspa-adoption/scheduler.ts: node-cron v4's
ScheduledTask dropped `.destroy()` (relevant now that this branch
already bumped node-cron 3->4 for the uuid CVE fix) -- `.stop()`
alone is sufficient
- src/features/{bgp-communities,rpki-history}/routes.ts:
`response.json()` typed as `{}` under this @types/node version,
cast to `any` to match this file's existing loose-typing style
- src/features/pdf-export/cache-manager.ts: `NodeJS.Timer` ->
`NodeJS.Timeout` (what setInterval/clearInterval actually use)
- src/features/pdf-export/renderer.ts: this uses Playwright, not
Puppeteer -- `timeout` isn't a page.pdf() option in Playwright,
moved to page.setDefaultTimeout() before the call
- Adds src/api/index.ts as the actual entry point (there wasn't one).
Calls initializeDatabase() before dynamically importing ./server.js,
because src/routes/hijack-alerts.ts calls getDatabase() at module
load time -- a static top-level import of ./server would have
crashed on startup before initializeDatabase() ever ran. Verified
this boots cleanly and serves real responses (changelog-data,
ix-matrix, rib/prefix graceful-503, bgp-communities with a live
RIPE Stat call) in local testing.
- Wires server.js to reverse-proxy the 11 genuinely-orphaned paths
(submarine-cables, global-infra, communities, irr-audit,
asset-expand, rpki-history, aspath, looking-glass, ix-matrix,
changelog-data, rib/*, prefix-changes) to this new internal server
via a plain http.request() proxy -- chosen over exposing a second
Cloudflare Tunnel ingress rule so this stays a same-origin,
internal-only change with no DNS/tunnel config to touch. Verified
the proxy mechanism itself against a live instance of the new server.
Deliberately did NOT proxy /api/webhooks, /api/hijacks, or
/api/hijack-subscribe -- server.js already serves those paths
inline (file-backed, live, working), and src/routes/hijack-alerts.ts
registers the same path names against an empty Postgres table.
Proxying would have silently shadowed working data with nothing.
- Default port 3102, not 3100: checked Erik and found 3100 already
bound by an unrelated docker-proxy container. 3102 is free and
reads as "the second peercortex port" next to the existing 3101.
- Adds a `peercortex-api` PM2 app to ecosystem.config.js on Erik
(backed up first via rollback-standard.sh) -- config only, NOT
started. Nothing is deployed to Erik as part of this commit: no
dist/ upload, no `npm install` for fastify/pg on Erik, no `pm2
start`. server.js and public/index.html on Erik are untouched.
Merges the production-only changes (Izzy PDF export via puppeteer,
Adoption Tracker overlay, audit scripts, deploy/utility scripts) that
had been living as uncommitted edits directly on Erik since before the
2026-07-14 backend refactor, on top of current main.
4 real conflicts, resolved by keeping whichever side is actually
functional rather than picking a side mechanically:
- package.json / package-lock.json: trivial union, kept both the
refactor's pg/playwright deps and the snapshot's puppeteer dep;
lockfile regenerated via `npm install --package-lock-only` rather
than hand-edited
- server.js top-of-file: additive, kept both the localDb require
(backend refactor) and the puppeteer lazy-loader (PDF export)
- server.js /api/health aspa_adoption block: main referenced
`aspaAdoptionHistory`, a variable that is never declared anywhere
in this file (confirmed by grep) -- a pre-existing dead reference
that would throw if this code path ever ran. Kept the snapshot's
working `aspaAdoptionDailyHistory`/`roaStore.count` version, which
matches the live /api/health output from production. Also fixed
the identical bug in the neighboring .catch() fallback block a few
lines down (same undefined variable, not part of the conflict
itself -- pre-existing on main, same fix applied for consistency).
- server.js hijack-subscribe/webhooks section (186 lines): main's
side was just a 2-line comment ("Migrated to
src/features/hijack-subscribe/"). Kept the snapshot's actual
working implementation instead, because server.js does not
require() or import anything from src/features/ or dist/ anywhere
-- confirmed by grep. The "migration" only ever happened on the
src/features/ side; server.js's own HTTP routing was never wired
up to call into it.
IMPORTANT CAVEAT, found while investigating the above and NOT fixed
here: server.js still has 13 other "// Migrated to src/features/..."
comments (bgp-communities, irr-audit, asset-expand, rpki-history,
aspath, looking-glass, ix-matrix, submarine-cables, global-infra,
hijack-alerts (Fastify), changelog, rib, prefix-changes) where the
same thing is true -- the route implementation was deleted from
server.js and never replaced with a working call into src/features/.
These weren't touched by this merge (git didn't flag them as
conflicts, because production's snapshot never touched those
sections either -- only main changed them, by deleting them). If
this server.js is ever deployed as the new production file as-is,
those 13 endpoints will silently 404 or fall through, exactly like
the hijack-subscribe one would have if I'd taken main's side. This
is a pre-existing gap in the 2026-07-14 refactor (PR #1), unrelated
to the Izzy/Adoption Tracker work, and needs a deliberate decision
(wire server.js to src/features/, or confirm those routes are meant
to live on a different process/port entirely) before this branch
should be treated as deployable.
`node --check server.js` passes. Not deployed to Erik as part of
this commit -- Erik's currently-live server.js/public/index.html
are untouched.
Working tree was 3+ months ahead of git in uncommitted local edits, sitting
on a detached HEAD at d3611a8 (2026-04-09), never reconciled with main.
Committing as-is on its own branch, without touching main or the detached
HEAD, to stop these files existing only on this one server:
- public/index.html + server.js: PDF export add-on gated to client Izzy,
full Adoption Tracker overlay (ASPA + IPv6 tabs) -- neither exists
anywhere in git history on any branch until now
- audit/: daily/rotating audit scripts + email report sender, previously
untracked
- scripts/: tunnel-cleanup.sh, refresh-peeringdb.sh, previously untracked
- deploy-from-scp.sh, webhook-subs.json, hijack-alerts.json,
aspa-adoption-history.json: previously untracked runtime/deploy state
- public/public/: duplicate mirror of the HTML variants found alongside
the real public/ dir, preserved as found
No reconciliation with main attempted here -- that needs a deliberate pass,
not a side effect of a backup commit.
- Create local-db-client.js with consolidated database client module (11 functions)
- Refactor validateRPKIWithCache() to query local rpki_roas table (<10ms vs 1-2s external)
- Update /api/health endpoint to determine health from local DB statistics
- Update /api/prefix-detail endpoint to use async validateRPKIWithCache()
- Update /api/prefix-changes endpoint with RPKI status lookup from local DB
- Create /api/bgp endpoint with local BGP routes + threat intelligence lookup
- Add bgp_routes, rpki_roas, threat_intel statistics to health response
- Zero external API calls for RPKI/BGP validation queries
Impact: Sub-100ms latency for all lookups, 0 token spend on BGP/RPKI/threat intel
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- aspa/verify: 15min result cache, looking-glass 3s timeout (was 20s default), 5→3 prefixes
- fetchJSON default timeout: 20s→8s prevents all uncached RIPE Stat calls from waiting 20s
- All cards now respond in <1s on cold call (ASPA 200ms, verify 170ms, validate 820ms, WHOIS 50ms)
- bgproutes still 4s cold (bgproutes.io API latency, cached after first call)
Adds real-time local BGP RIB data as a complement to external APIs
(RIPE Stat, bgproutes.io) which have rate limits and 15min+ delays.
- bio-rd-client.js: gRPC client for bio-routing/bio-rd RIS service
- LPM, Get, GetLonger, GetRouters, DumpRIB, ObserveRIB methods
- IPv4/IPv6 encoding as uint64 pair (bio.net format)
- Full BGP path decode: AS paths, communities, large communities
- Graceful fallback if RIS unavailable (null/empty returns)
- protos/: bio-rd proto definitions (ris, bgp, session, route, net)
- server.js: three new endpoints + WebSocket stream
- GET /api/rib/prefix — LPM + more-specifics via GetLonger
- GET /api/rib/routers — list BMP-monitored routers
- GET /api/rib/dump — full RIB dump with ASN filter + limit
- WS /ws/rib — live ObserveRIB stream (add/withdraw events)
- package.json: @grpc/grpc-js + @grpc/proto-loader dependencies
- Resilience Score (1-10): weighted 4-factor model (transit diversity 30%,
peering breadth 25%, IXP presence 20%, path redundancy 25%), hard cap at
5.0 on single transit provider. Confidence: HIGH (cross-validated data).
- Route Leak Detection: heuristic Tier-1 sandwich/downstream pattern check.
Confidence: MEDIUM — pattern-based, not real-time, false positives flagged.
- Data Provenance System: every API response field includes source, validation
method and confidence level. UI shows green/orange provenance badges.
- MCP Server: exposes PeerCortex as Claude Desktop/Code tools (lookup_asn,
compare_networks, get_health_report, search_network, get_resilience_score).
For ASNs with no PeeringDB entry and no RIPE Stat holder (e.g. reserved
or unannounced ASNs), extract name from bgp.he.net page title and
country code from the /country/XX href. Eliminates the last 2 CRITICAL
audit failures (AS34465 → 'RIPE NCC ASN block'/GB, AS59947 → 'LLHOST
INC. SRL'/RO). Audit result: 80/82 PERFECT, 0 CRITICAL. v0.6.8.
- Install better-sqlite3 for zero-latency local queries
- queryPeeringDBLocal() handles all major PDB API paths locally:
/net?asn=X, /netixlan, /netfac, /fac?id__in=, /ixfac, /ix, /ixlan
- fetchPeeringDB() now tries local SQLite first, falls back to live API
- Eliminates rate limits and reduces P99 response times dramatically
- Local DB synced daily at 03:48 via peeringdb-py cron on Erik
- Graceful fallback: if SQLite missing/corrupt, live API used transparently
- MANRS: replace broken Observatory API with public participants page scraping
(www.manrs.org/netops/participants/), 24h cache, returns pass/fail with member count
- /api/validate: add 'relationships' field (upstreams/downstreams/top_peers)
sourced from RIPE Stat asn-neighbours, no extra API calls needed
- /api/relationships?asn=X: new dedicated endpoint with resolved AS names,
full upstream/downstream/peer lists sorted by power score, 10min cache
- editorial: rebrand 'The ASN Newspaper' → 'The ASN News' across index-editorial.html
Root cause of neighbour=0 for large carriers (AS9002, AS3491, AS12956):
1. RIPE Stat asn-neighbours returns 5000+ entries for Tier-1 carriers,
exceeding the 30s timeout → fetchJSON returns null
2. null was cached in ripeStatCache for 15 minutes (the endpoint TTL)
3. All subsequent requests hit the null cache → perpetual 0 neighbours
Fixes:
- Never cache null results in ripeStatCache (only successful responses)
- Never persist null entries to disk cache
- Increase RIPE Stat timeout from 30s to 45s for prefix/neighbour queries
- Increase RIPE Stat semaphore from 10 to 15 concurrent requests
Verified: AS9002 up=146 down=2702, AS3491 up=90 down=710
- Phase 1: Parse ~400k ROAs from Cloudflare RPKI feed into local store
Eliminates ALL per-prefix RIPE Stat API calls (was 2000+ per lookup)
Binary search validation in <0.1ms instead of 1-20s HTTP roundtrip
Disk persistence (.roa-cache.json) for fast restart
- Phase 2: PeeringDB source cache (L2) for net/netixlan/netfac
6h TTL with LRU eviction (max 5000 entries per type)
Disk persistence (.pdb-source-cache.json) every 30min + SIGTERM
- Phase 3: RIPE Stat semaphore (max 10 concurrent) + response cache
Endpoint-specific TTLs (15min-24h based on change rate)
Max 2000 cached responses, disk persistence
- Phase 4: Extended /api/health with cache status, ASPA adoption metrics
Version bump to 0.6.0
Jittered refresh timers to prevent thundering herd
Graceful shutdown saves all caches
Expected: Audit accuracy 82% -> 95%+, lookup time 90s -> <8s
- index-editorial.html: floating \$_ terminal button (bottom-right)
- macOS-style title bar (traffic light dots), backdrop blur 18px
- Guided wizard: category → message → name → submit
- POST /api/feedback with ASN context auto-filled
- Safe DOM output builder (no innerHTML on user data)
- server.js: feedback API endpoints
- POST /api/feedback — stores entries to feedback.json
- GET /api/feedback?token=... — admin read (token-protected)
- OPTIONS preflight for CORS
- FEEDBACK_TOKEN + FEEDBACK_FILE constants from .env
- Host routing: shell.peercortex.org → shell.html
- public/shell.html: full-screen admin terminal
- login command → token auth via API
- list / list [category] — tabular overview
- show <n> — full entry detail
- stats — bar chart by category + top ASNs
- export — JSON file download
- refresh, logout, clear, help
- Upgrade from Leaflet to MapLibre GL JS 4.7.1 with OpenFreeMap dark base
- Add submarine cable layer (TeleGeography via /api/submarine-cables proxy, 24h cache)
- Add global datacenter layer (PeeringDB all facilities via /api/global-infra proxy)
- Layer toggles: ASN PoPs | Submarine Cables | Global Datacenters
- Dark-themed popup styling matching PeerCortex UI
- Server-side caching for both new data sources (24h TTL)
Root cause of 2.7GB RAM usage and 20+ OOM restart loops:
- server loaded all 825k ROAs from Cloudflare RPKI feed into a JS Map
- Every 10min refresh caused double-memory spike (old + new data) -> OOM kill
Solution:
- Remove rpkiRoaIndex Map, addRoaToIndex(), validateRPKILocal(), ipv4ToInt()
- fetchRpkiAspaFeed() now only loads ASPA objects (~1484, negligible RAM)
- Add validateRPKIWithCache(): calls RIPE Stat API per-prefix with a
5000-entry LRU cache (6h TTL) — same API already used by fetchRPKIPerPrefix()
- Update all 4 call sites: sync .map() -> await Promise.all()
Result: 2.7GB -> ~96MB RAM, no more OOM restarts
new URL() throws ERR_INVALID_URL on malformed inputs like XSS probe
requests (e.g. //brusEYkk%22%3E%3Cscript%3E...). Uncaught exception
caused memory leak and process restarts. Return HTTP 400 instead.
server.js: fetchPeeringDBWithRetry now does 3 attempts with exponential
backoff (2s, 5s) instead of 1 retry at 1.5s. Under audit load (9+
concurrent PDB requests), the longer delays let rate limits clear.
audit.py: stagger ASN submissions by 2s so PeerCortex's internal PDB
requests don't all fire simultaneously. Nightly audit takes ~8min
instead of 5min — acceptable for a midnight cron job.
- Add fetchPeeringDBWithRetry: 1 retry with 1.5s delay on null response
- Add fetchJSONWithRetry: 1 retry for RIPE Stat prefixes + neighbours
- Log HTTP 429 from PeeringDB instead of silently swallowing it
- Add &limit=1000 to netixlan/netfac queries (prevents truncation at 250)
- Fall back to asn= / local_asn= queries when PeeringDB net lookup fails
(previously: netId=null → IX=0, fac=0 for ~22 ASNs)
bgp.he.net scraper:
- Fixed prefix regex: "Prefixes Originated (v4): 147" format
- Fixed peer regex: "BGP Peers Observed (all): 274" format
- Added prefixes_all field
- AS6830: v4=147, v6=9, peers=274 (was all unavailable)
- Prefix cross-check now works: RIPE 151 vs HE 156 = 97% agreement
Peering Recommendations:
- Now filters out already-established peering sessions
- 3 categories: New Opportunities, Already Peering, No Shared IXP
- Uses BGP neighbour data to detect existing sessions
- Shows "Already peering with all top networks" when applicable
Dashboard: Added "Score Breakdown — Why X/100?" section showing:
- Per-check weight, earned points, and reason
- Total calculation with formula explanation
- Data source attribution
- "info" status excluded from scoring (e.g. MANRS API auth)
Security: try-catch around new URL() parser — malformed URLs from
scanner bots (XSS attempts) now return 400 instead of crashing server.
Was causing repeated crashes from automated vulnerability scanners.
- Route Server: threshold lowered from 20 to 10 IX for "bilateral policy" pass.
3-9 IX without RS = "info" (not warning). <3 IX = warning.
AS212635: 19 IX → pass (was warning)
- rDNS: sample size increased from 5 to min(20, total_prefixes)
Better coverage for large networks (AS13335: was 5/5621 = 0.09%)
- IX Route Server: always use asn= query (more reliable than net_id when PDB rate-limits)
AS212635: 0 → 19 IX connections correctly detected
AS212635 score: 98 → 100/100
- Geolocation: global networks (5+ facility countries) now get pass
even when MaxMind has no data (was warning)
- Route Server: uses ASN fallback when PeeringDB net_id unavailable
(was showing "0 IX connections" due to rate limiting)
- IX geocode fallback: CITY_COORDS map + IX_CITY_MAP for 70+ cities
AS49544 (i3D.net/Ubisoft): 100 IX connections correctly detected,
bilateral peering policy recognized, 27-country global presence pass
renderNetworkMap() was missing its closing } after the setTimeout(50)
callback. This caused a SyntaxError that prevented the entire script
from parsing — doLookup was undefined, Lookup button did nothing.
Also added deploy.sh backup script on Erik (auto-backup before restart,
keeps last 20 versions of server.js + index.html).
IXPs without PeeringDB facility coordinates now get geocoded via:
1. City name extraction from IX name (e.g. "France-IX Paris" → Paris)
2. Hard-coded IX ID → city map for 15 well-known IXPs (SwissIX→Zurich etc.)
3. 70+ major networking cities with lat/lon coordinates
AS8283 Coloclue: 9 → 12 IX locations (5 cities: AMS, FRA, Paris, Zurich, Meppel)
AS49544 i3D.net: 100 connections → 20 locations (16 cities worldwide)
- Leaflet map: double requestAnimationFrame after display:none removal
ensures container has real dimensions before L.map() init
- PeeringDB org cache: 24h disk cache (.pdb-org-cache.json) prevents
hammering PeeringDB API on server restarts (was causing 175 restarts)
- Check HTTP status before JSON.parse on PDB responses
- Leaflet.js (CDN) with CartoDB Dark Matter tiles matching Tokyo Night theme
- Cyan markers: facility/datacenter locations with name + city popup
- Orange markers: IX presence with IX name + speed popup
- Purple connecting lines between facilities in the same country
- Coordinates from PeeringDB facility API (batch lookup, chunked)
- IX locations via ixfac association + facility geocoding
- Auto-fit bounds, graceful degradation if no coordinates
- Collapsible card, XSS-safe popups via DOM API
- RPKI cross-check: Cloudflare RPKI feed + RIPE NCC Validator API (5 sample prefixes)
- Prefix cross-check: RIPE Stat vs bgp.he.net count comparison
- Neighbour cross-check: RIPE Stat vs bgp.he.net peer data
- Data Quality badge in dashboard (High/Medium/Low confidence)
- Hover tooltip: "Data Quality Report" with per-source agreement breakdown
- Added BETA tag to site header and version string (v0.5.0-beta)
- All UI text in English
RPKI Validation:
- Validate ALL prefixes (not sample of 10) using local Cloudflare RPKI feed
- Covers all 5 RIRs globally (RIPE, APNIC, ARIN, LACNIC, AFRINIC)
- Indexed ROA lookup (O(bucket) not O(824K)) for instant validation
- AS4739 now correctly shows 446/446 prefixes checked
ASPA Provider Detection:
- Only RIPE Stat "left" neighbours (verified upstreams) used as providers
- AS-path analysis used for frequency confirmation only, not as provider source
- Fixes false provider detection that included peers alongside upstreams
Multi-RIR Support:
- WHOIS/IRR queries all 5 RIR databases via RDAP in parallel
- RPSL validation checks RIPE + APNIC/ARIN/LACNIC/AFRINIC
- AS4739 (APNIC) now correctly found via rdap.apnic.net
Geolocation:
- Anycast/CDN networks (5+ facility countries or Content/NSP type) not flagged
- Only small networks with geo anomalies get warnings
Route Server Scoring:
- Networks with 20+ IX connections and no RS scored as "pass" (bilateral policy)
- Only small networks without RS get warnings
Error Handling:
- ASPA endpoints gracefully handle timeouts (show fallback instead of HTML parse error)
- Frontend checks Content-Type before JSON.parse
Reported by Philip Smith, Richard Steenbergen, Jared Mauch, Chris Malayter
- Compare: all API calls in single parallel batch (was sequential)
- Compare: RPKI sample reduced to 3+3 prefixes with 5s timeout cap
- Compare: response caching (5min TTL)
- Compare: AS name resolution parallel with 3s timeout
- Result: Compare from timeout (>20s) to ~5s first call, <1s cached
- Add response caching (5min TTL for lookups, 10min for ASPA)
- Add 8s timeout to all external API fetches
- RPKI validation: sample max 10 prefixes (5 v4 + 5 v6) instead of 50
- Run all PeeringDB + RIPE Stat calls in single parallel batch
- Resolve AS names in parallel with 3s timeout cap
- Add deploy/ directory with production server.js + index.html dashboard
- Landing page: Tokyo Night dark theme, interactive ASN search
- 15 API endpoints: lookup, aspa, aspa/verify, bgproutes, validate,
compare, peers/find, prefix/detail, ix/detail, topology, whois, health
- Features: RPKI per-prefix, RIPE Atlas probes, Network Health Report,
ASPA RFC verification engine, Provider Relationship Graph
