_default_gateway() took whichever 0.0.0.0 line route print printed first,
not the one Windows actually uses (lowest metric). With a VPN adapter
installed (Radmin VPN, Tailscale, ...) its default-ish route can print
before the real one. Verified live: was reporting Radmin VPN's 26.0.0.1
while Ethernet (the interface actually carrying traffic, confirmed via
primary_interface_ip()) has gateway 192.168.3.1; now reports that correctly.
Parsing extracted into pure _parse_windows_default_gateway(), tested against
a captured multi-adapter route print sample.
path_findings() flagged ICMP rate limiting as real loss whenever two
consecutive traceroute hops both went silent, but real transit paths
routinely have long runs of silent hops (10 in a row, confirmed on a live
--full run) while the destination itself answers cleanly. Only flag loss
that persists all the way to the last hop in the trace; a run that clears
before the end is now ignored regardless of how many hops it spans.
Every run used to write all three files (en.md, ru.md, json) unconditionally.
Default is now English Markdown only, sourced from output.formats in
config.yaml; --format/--ru/--json pick exactly what a run writes, and any
explicit --format replaces the default rather than adding to it (all/none
supported). write_report() moved from a fixed 3-positional-arg signature to
a {format: text} mapping so writes are conditional instead of always-three.
The en/ru Markdown cross-link header is now only set when both languages are
actually being written.
diagnose() now computes both filenames up front so each markdown
render can link to its sibling, calls render_markdown twice (en/ru),
and passes both strings to write_report. run() prints all three
report paths.
Thread a lang parameter through render_markdown and every section
helper so the same report dict can render an English or Russian
report; inline _t() calls carry the strings, findings fall back from
_ru fields to their English siblings. write_report now emits a third
.ru.md file alongside .json and .md, and render_markdown can stamp a
sibling cross-link line right after the H1.
readme's sample console output showed a multi-line summary table
(connection/egress/vpn/latency) the tool has never printed; the real
stdout is three lines (banner, verdict, file paths). also documented:
the tcptrace/ndt7 extras install command, bare-asn --target syntax,
ndt7's interactive consent prompt, tcp-trace's cascade fallback, and
that --watch writes one artifact per session rather than per tick.
architecture's storage section had the peeringdb cache path wrong
(.cache/peeringdb/*.json vs the real .cache/pdb-net-*.json) and never
mentioned the watch_*.json artifact from task 39. the file-size
exceptions note only covered exporter.py; interpret.py, cli.py,
models.py, bgp.py, ip_geo.py, netinfo.py, speed.py, reputation.py and
probes/traceroute.py all cleared ~200 lines too and are now listed
with the reason each stayed one file. test count updated from ~120
(written before a single module existed) to the real ~385.
cf-trace has no way to describe an arbitrary target — it always
echoes the ip of whoever is making the http request. gather_identity
included it in the merge candidates unconditionally, so 'netcheck
--target 8.8.8.8' spliced this machine's own connecting ip onto
8.8.8.8's asn/city/org fields from the other providers, producing a
report that named an ip that was neither the target nor honestly
labeled as the local egress. exclude cf-trace from the merge whenever
an explicit target ip was requested; it's still fetched and returned
separately for the connection section's own colo/warp fields.
unavailable() only ever read module.errors for the placeholder detail
text, so a deliberately skipped section (speed in --quick or target
mode, which reports its reason as a warning, not an error) always
fell through to the generic 'no data was collected for this section'
line even though the real reason ('speedtest skipped in target mode')
was sitting right there in the json. spec says a skipped speedtest
must say why, not just that it's missing.
'--target AS<n>' still describes this machine's own egress (an asn
target isn't something ip_geo can look up directly), same as auto
mode, but the ipv4/ipv6 forcing added for the egress_v4 mislabel fix
only checked target_kind is None. widen it to also cover 'asn' so
target-mode runs get the same protocol-pinned identity lookup as
auto mode instead of falling back to the unpinned shared client.
target mode's filename fell back to the local machine's egress asn
unconditionally, so 'netcheck --target AS15169' wrote report_<local-asn>_*
instead of report_AS15169_*. meta.target already carries the right
subject when one was given; prefer it and fall back to the egress asn
only in auto mode.
a hop with no icmp reply has ip=None; the sustained-loss finding
formatted it straight into the report text as the literal string
'(None)'. seen live in a --quick smoke test report.
the shared http client has no address family pinned, so on a dual-stack
host the 'egress_v4' gather could connect over ipv6 (os/happy-eyeballs
preference) and hand back an ipv6 literal labeled as egress_v4, with a
mismatched ip_version pulled from a different provider's own record.
mirror the existing egress_v6 forcing so each slot can only resolve
its own protocol. caught live during the --quick smoke test: the
report was analyzing an unrelated ipv6 asn instead of the real isp.
time.time() - path.stat().st_mtime went negative under load when NTFS
stamped a write's mtime slightly ahead of the wall clock read a moment
later, making a ttl_hours=0 cache lookup serve stale data instead of
refetching. surfaced as a flaky failure in test_cached_json_refetches_once_the_entry_expires
during the full suite run before task 40's smoke test.
subprocess_seconds was being applied per hop instead of as a total trace
budget, so a path with several non-responding hops could block for up to
max_hops * subprocess_seconds. The blocking call also ran on a
ThreadPoolExecutor worker via asyncio.to_thread, which concurrent.futures
joins at process exit - so an orphaned hop stuck past its timeout kept the
whole CLI alive long after diagnose() had already written its report.
Divide the budget across hops (capped at 4s per hop) with an early exit
once the total deadline passes, and dispatch the call on a raw daemon
thread instead so it can never hold the process open even in the worst
case.
